升级本地bitshares节点到6.0.1

最近bitshares网络激活了代号湄公河的6.0版本,新增了好多激动人心的特性比如P2P质押借贷、无抵押借贷(闪电贷)等,想起我还在本地运行着一个bitshares节点呢,打算拿来学习一下BTS6.0。

image.png

结果打开我的本地节点一看,咦,竟然卡住了好久,仔细想想也不意外,6.0版本是协议升级,也就是我们在HIVE上常说的硬分叉(Hard Fork),新版本被激活,而我的本地节点是5.0.1版本,当然要卡住啦,所以要将其升级到6.0.1才能继续愉快地玩耍。

根据节点运行的方式,升级有好多方法,比如说使用Docker、或者直接使用编译好的二进制文件,不过我还是喜欢从源码编译这种方式(好吧,其实是我不知道如何使用其它方式)。

编译的方式很简单啦,按如下步骤操作即可:

git clone https://github.com/bitshares/bitshares-core.git
cd bitshares-core
git checkout <LATEST_RELEASE_TAG>
git submodule update --init --recursive
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
make witness_node cli_wallet

上述指令中,需要将<LATEST_RELEASE_TAG>替换成最新发布版本号,撰写本文时,最新版本号是6.0.1

按上述指令,会在相应路径中生成如下两个目标文件:

build/programs/witness_node/witness_node
build/programs/cli_wallet/cli_wallet

进入相应目录中,然后使用如下指令查看一下版本信息:

./witness_node --version

返回信息如下:

Reveal spoiler

image.png
这说明我编译的没啥问题。

然后使用scp指令将上述两个文件复制到本地机器对应账户的bin目录中,替换掉原有的程序。在scp之前,可以先用tar指令将程序打包压缩一下,这样传输会比较快,且节省网络带宽。

关掉之前运行的(卡住状态的)witness_node,再重新执行witness_node指令,就会发现节点自动开始replay。

我撰写本文时,进展如下:

Reveal spoiler

image.png

为了方便查看,截屏只截取部分内容,这是其中一条信息:

3420978ms th_a db_management.cpp:141 reindex ] [by size: 21.08850% 20009480004 of 94883379836] [by num: 43.47800% 28410000 of 65343387]

我发现,replay时除了有按区块数量的进度,还有一个按区块文件( blocks)体积的进度。

这个功能比较好,因为区块有大有小,甚至早期区块可能有很多不包含任何交易的空块。所以单纯按区块数估算进度是非常不准确的,按体积则相对准确多啦。

好期待hived的replay功能也加上按区块文件体积显示进度的功能,那样就能大致估算出replay完成的时间啦。

看了一下,半个小时左右,按区块文件体积replay完成了大概20%,所以全部完成大概需要2.5小时,也就是说还需要2个小时左右,两个小时后我再来瞧瞧。


接着写,原本打算两小时后瞧瞧replay进度,结果因为太晚太困,一不小心睡着了,等我醒来已经是第二天了。

登录本地机器一看,replay早已完成,哎,也不知道自己估算的时间是否准确,不过想必应该差不太多。

Reveal spoiler

image.png

下次有版本升级还是要及时升级的好,如果我在硬分叉前及时升级并replay,节点就不会卡住啦,好在我还没在上边跑什么业务,否则损失大了。

不过好在升级是顺利完成了,以后又可以愉快地玩耍了。有小伙伴一起来玩嘛?

相关链接

Sort:  

😅果然都被劝退了,这个帖子不是一般人看得懂的😂