geth 同步区块一直落后的解决方案

57 阅读 0 评论 38 点赞

我是靠谱客的博主花痴保温杯，最近开发中收集的这篇文章主要介绍geth 同步区块一直落后的解决方案，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

核心思路 : 从原有的(或者从别人那里) 拷贝数据到自己的电脑上;

geth 版本: Geth/v1.8.18-stable/linux-amd64/go1.11.2

最近新开了一台服务器来同步以太坊的区块, 但是在 geth 的控制台调用 eth.syncing 发现 currentBlock 一直低于highestBlock,

苦于百度上, Google 上和 github 上都没有确实际的解决方案…

网上有人说是磁盘的问题, 但是我的是 Google Cloud 的 SSD 云盘啊!

所以我想到了一个非常苦逼的办法: 从别人的机器上服务制区块链数据到我的服务器上,
嗯… 我之前已经有一台服务器在日本, 区块已经同步好了, 所以我准备将数据从日本拷贝到Google Cloud 上来.

服务器 A: 已经同步好区块的服务器
服务器 B: 同步有问题的服务器
当前区块数据大小: 180G 左右
备注: 我下面写的命令中的路径你要注意修改一下

关闭 A服务器上的 geth
我启动geth 的方式是用 nohup 启动在后台的, 我查找到 geth pid 之后直接 kill 掉(不要加 -9 选项),
然后查看 nohup 文件的内容, 等待 geth 完全退出. 下面是我执行的命令过程

ps -axu | grep geth # 查看geth 的 pid
kill ${pid} # 给 geth 发出 停止信号
#.... 等待关闭完成(大约 20 秒)
tail -n 10 nohup.out # 查看是否输出 已经关闭了数据库(这个文件是我的nohup 输出文件)
ps -axu | grep geth # 确保没有geth 正在运行

拷贝数据到新的服务器
无非就是用 scp 将数据拷贝到另一台电脑嘛~

export target=username@0.0.0.0:~/ethdata/data/
nohup scp ~/eth/data ${target} & 
#... 睡一觉吧, 拷贝很久呢

在 B 服务器上同步 A 服务器的数据
等了好久, 终于拷贝完成了, 不要忘了把 A 服务的geth 重新启动起来(我花费的传输时间, 区块落后了1000 块).
接下来在服务器 B 上启动 geth,
启动数据文件夹指向复制过来的文件夹, 同步节点指向服务器 A.
不过记得修改 nodekey, 否则无法同步

./geth --data-dir =/tmp/eth/ # 生成 新的 nodekey
#将原有的nodkey 改名
mv ~/ethdata/data/geth/nodekey ~/ethdata/data/geth/nodekey2
# 复制新生成的nodekey 到数据目录
cp /tmp/eth/geth/nodekey ~/ethdata/data/geth/nodekey
rm -rf /tmp/eth/ # ...
# 启动
./geth --data-dir=/home/xxx/ethdata/data/ .... #

启动会花费一些时间…
然后进入geth 控制台, 将A 服务器的节点添加进去

./geth attach http://xxx.xxx.xxx.xxx # 连接到
admin.addPeer("xxxx"); # 添加服务器A geht 的节点

我的 A 服务器同步特别快, 我B 服务器还没启动起来就追上了最新块,
B 服务器上的geth 启动执行 eth.blockNumber 的结果是和服务器 A 传输之前是一致的,
接下来就等服务器 B 同步 A 服务器的数据了.

嗯… 20 分钟就同步完了.
好了, 现在我两台服务器的 blockNumber 都和 etherscan.io 一致了!

关于如何查看服务器A 的节点.
进入服务器 A , 查看日志文件(我的是nohup.out 文件)

head -n 20 nohup.out

找到 Started P2P networking 相关日志, 大致类似于下面这样

INFO [11-29|07:56:16.208] Started P2P networking  self="enode://xxxxx@0.0.0.0:30303?discport=0"

# enode://xxxxx@0.0.0.0:30303?discport=0 就是了
# admin.addPeer("enode://xxxxx@0.0.0.0:30303?discport=0");