二进制启动BSC主网快照数据
大家好,我是杰哥,因为之前从0块开始同步BSC(币安智能链,下文简称BSC)节点的数据,一直没有追上最新区块,经过和别人一起讨论,最终使用BSC节点主网快照数据同步到了最新区块。那么这篇文章就和大家一起使用二进制的方式启动BSC主网快照数据,来看看这次需要多久的时间可以追上最新区块。
本篇文档开始之前,大概说明一下本次BSC同步的情况:
服务器:阿里云服务器
CPU:8核
内存:16GB
数据盘:1T 高效云盘
带宽:共享10M
centos 7.7
由于前面使用从0块开始同步的过程,大概10天过去了,BSC主链节点的状态数据依旧没有同步完成,所以本次使用BSC快照数据再次测试同步一下:
我是在2021年7月20日晚上九点下载的BSC的快照数据,当时最新的数据是2021年7月14日的快照数据,编写这篇文章时,最新的快照数据是2021年7月22日的;
我大概花费了几个小时就将快照数据下载下来了,当时解压后的数据是:401 GB 左右;
在 2021年7月22日早上9点25分时,我利用下载好的BSC快照数据启动了BSC主网节点,然后就一直默默的等待同步完成;
终于,在2021年7月23日18点23分,同步到了最新BSC主网的最新区块:9405825 块;
大概计算了一下,此次利用BSC快照数据同步主网节点数据,同步时间大约花费了:1天8小时58分钟 ;注:本次同步时间仅为个人使用的时间,同步时间还需参考当时环境。
本次同步,服务器的资源使用情况如下:
cpu:4核
内存:12 GB
带宽:2 M
磁盘:536G
接下来废话少说,马上开始实操步骤
cd /opt/docker/bsc/
nohup wget https://s3.ap-northeast-1.amazonaws.com/dex-bin.bnbstatic.com/geth-20210714.zip?AWSAccessKeyId=AKIAYINE6SBQPUZDDRRO\&Expires=1628936991\&Signature=C6kD8aUdzCmpPwQ7HHRFyn%2FXknA%3D &
unzip geth-20210714.zip\?AWSAccessKeyId\=AKIAYINE6SBQPUZDDRRO\&Expires\=1628936991\&Signature\=C6kD8aUdzCmpPwQ7HHRFyn%2FXknA\=
cd /opt/docker/bsc/server
wget https://github.com/binance-chain/bsc/releases/download/v1.1.0-beta/geth_linux
chmod 777 geth_linux
cd /opt/docker/bsc/server
wget $(curl -s https://api.github.com/repos/binance-chain/bsc/releases/latest |grep browser_ |grep mainnet |cut -d\" -f4)
unzip mainnet.zip
HTTPHost: HTTP-RPC服务连接白名单,此参数的值默认为 "localhost",仅允许本地可访问,可设置为:"0.0.0.0"
HTTPVirtualHosts:HTTP-RPC服务监听接口,此参数的值默认为 ["localhost"],可设置为:HTTPVirtualHosts = ["*"]
yum -y install screen
screen -S bsc /opt/docker/bsc/server/geth_linux --config /opt/docker/bsc/server/config.toml --datadir /opt/docker/bsc/server/node --cache 18000 --rpc.allow-unprotected-txs --txlookuplimit 0
参数说明:
--config:指定BSC节点配置文件
--datadir:指定BSC节点数据库和密钥存储库的数据目录(默认:"/root/.ethereum")
--cache:设置最大分配给内部缓存的内存,默认:1024(设置越大,每次同步的数据越多,消耗的内存也越大)
--rpc.allow-unprotected-txs:允许通过RPC提交不受保护的(非 EIP155 签名)交易
--txlookuplimit 0 : 禁用删除事务索引
cd /opt/docker/bsc/server/node/
cat bsc.log.2021-07-22_09
// 预置BSC主网节点各种配置:
t=2021-07-22T09:25:01+0800 lvl=warn msg="Sanitizing cache to Go's GC limits" provided=18000 updated=5338
......
// 初始化链配置
t=2021-07-22T09:25:02+0800 lvl=info msg="Initialised chain configuration" config="{ChainID: 56 Homestead: 0 DAO: <nil> DAOSupport: false EIP150: 0 EIP155: 0 EIP158: 0 Byzantium: 0 Constantinople: 0 Petersburg: 0 Istanbul: 0, Muir Glacier: 0, Ramanujan: 0, Niels: 0, MirrorSync: 5184000, Berlin: <nil>, YOLO v3: <nil>, Engine: parlia}"
......
// 加载最新的header文件
t=2021-07-22T09:25:02+0800 lvl=info msg="Loaded most recent local header" number=9,154,718 hash=0xea2f92e829a44069fef71d345fcacf404bb2df44dd14dea45deb0e84682fdfcd td=18,241,589 age=1w8h25m
// 加载最新的完整的区块
t=2021-07-22T09:25:02+0800 lvl=info msg="Loaded most recent local full block" number=9,154,718 hash=0xea2f92e829a44069fef71d345fcacf404bb2df44dd14dea45deb0e84682fdfcd td=18,241,589 age=1w8h25m
加载最新的fast区块
t=2021-07-22T09:25:02+0800 lvl=info msg="Loaded most recent local fast block" number=9,154,718 hash=0xea2f92e829a44069fef71d345fcacf404bb2df44dd14dea45deb0e84682fdfcd td=18,241,589 age=1w8h25m
......
// 同步模式由快速同步切换为全同步
t=2021-07-22T09:25:03+0800 lvl=warn msg="Switch sync mode from fast sync to full sync"
......
// 启动p2p网络
t=2021-07-22T09:25:03+0800 lvl=info msg="Started P2P networking" self=enode://878a50bbcf1f6fe820d53315decd1c540de1570c967125561484a2819e7a66c4f1df8157cbcf1979bb3d245aadb3073a86c1d8941793b8984ecd8015be479cdd@127.0.0.1:30311
// 区块同步开始
t=2021-07-22T09:25:13+0800 lvl=info msg="Block synchronisation started"
......
// 同步到新的链数据
t=2021-07-22T09:25:27+0800 lvl=info msg="Imported new chain segment" blocks=3 txs=793 mgas=115.754 elapsed=8.585s mgasps=13.483 number=9,154,721 hash=0xaa97db3864f0002b4bec4714884dc44dc41f9c834f03ddff2de23fde838ff3b1 age=1w8h25m dirty="7.94 MiB"
# curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' http://127.0.0.1:8545
{"jsonrpc":"2.0","id":1,"result":"0x8f8e68"}
# curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}' http://127.0.0.1:8545
{"jsonrpc":"2.0","id":1,"result":false}
注:结果为false为同步完成
以上就是本篇文档的主要内容了,在本次BSC节点同步过程中,想到以下两个问题,在这里稍做一下记录:
BSC 节点的数据分为:区块数据 和 状态数据两种。
BSC中的数据体量并不完全是区块数据量,更多的是状态数据;
完整的BSC状态:指的是所有账户和余额的当前状态,以及在 EVM (以太坊虚拟机)中部署并运行的所有智能合约的 ‘内存’;
所以一直无法同步到最新的区块指的不是无法同步到最新的区块数据,而是无法同步到最新的状态。
那么为什么快照数据节点不用同步状态数据了呢?
因为BSC默认第一次启动时,需要将状态数据同步到最新的区块,才能完成数据的同步;
而快照数据中已经包含同步到最新区块的状态数据,所以不需要再去单独同步BSC的状态数据,而是在同步区块数据时,一起就完成同步了。
以上,就是今天分享的全部内容了。
希望大家通过以上方式可以解决自己的实际需求,解决自己目前所遇到的问题。
如果在部署过程中有任何疑问,可以扫描下面的二维码,添加我的个人微信,备注:地区-职业方向-昵称,欢迎来撩,加入区块链技术交流群,与更多的区块链技术大佬学习交流。
原创不易,码字不易。 觉得这篇文章对你有点用的话,麻烦你为本文点个赞,留言或转发一下,因为这将是我输出更多优质文章的动力,感谢!
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!