（转）以太坊数据同步常见问题集锦
常见问题列表
区块差几十块始终同步不完，怎么办？
这是大家同步数据遇到的第一个难题。当大家兴致匆匆的启动程序，看着区块离最新的区块越来越近，难免兴奋起来。但当差十几块或几十块的时候，却是漫长的等待，于是忍不住要问，出什么问题了吗？
针对此问题怎么解决，方案有两个：一，等。程序是在正常运行，需要的就是耐心等待；二、升级硬件配置，重新再来一次。
问题原因：显示同步剩下几十块，那只是同步了区块的头部信息，剩下漫长的等待才是在同步真正的区块结构体。此时如果查看区块的数据情况，并没有发生明显的增加。
在此过程中需慎重重启，因为一旦重启将会重新同步结构。
区块同步一直停留在99%，怎么办？
此问题同上面的《区块差几十块始终同步不完，怎么办》，原因也一样，只是展示的形势不同而已。
怎么查看同步情况
进入console，使用web3j命令来查询区块同步情况：
eth_syncing如果结构返回false，说明没有在同步数据。如果结果返回类似下面的内容则证明正在同步：
{
currentBlock: 290584, // 同步到的区块高度
highestBlock: 891836, // 所链接的节点的最高高度 knownStates: 465886,
pulledStates: 361434,
startingBlock: 0
}耐心等待knownStates的值同步到最大，此值不断在变化，目前已经上亿。
为什么查询区块高度为0
区块未同步完成常见的表现之一就是查看区块高度显示高度为0，比如执行一下命令：
> eth.blockNumber
此命令往往用来验证是否同步完成，是否同步到的高度和区块链上的高度一致。
为什么查询账户余额为零
为什么在区块链浏览器上查询到地址有余额，但通过本地节点查询到的余额为0或者不对。
此问题也是因为区块链未同步完成导致的。比如你转账一笔资金到一个地址，当前节点未同步到这笔交易，那么这个账户的余额便不包含此笔交易，
查询余额命令：
eth.getBalance("0x8b275d360a5d435e9dfcf27d610362ee2fdf460c")同步完数据大概多少
经常被问到如此问题，得到的答案也不一样，这跟每个节点采用的同步方式有关也跟同步时是否重启过节点和重启节点的时机有关。目前默认模式同步完成大概150G左右。
用什么同步模式比较好
答案是一般用户采用默认同步模式即可。慎重使用full模式，同步数据量较大，同步数据时间长，占用空间大。默认模式是采用快速同步，但当这过程中进行了重启，节点检测到已经有数据存在，则不会再使用快速同步模式，采用正常同步模式。这也是为什么上面一个问题大家同步的数据不一定相同的原因所在。
怎么能更快的同步
首先，确保网络带宽足够，硬盘最起码为高速硬盘，固态硬盘更好。其次，确保你的节点链接到足够的活跃节点，才能保证数据源头的畅通。最后，启动参数中设置缓存大小，有一定的效果。
缓存参数设置：
--cache value 最小16M，默认128，可根据内存情况适当扩大。什么样的配置才能正常同步
目前来看，2核4G带宽2M硬盘500G的配置已经有些吃不消，还需要适量增加swap来缓解内存的压力，确保以太坊节点不因OOM而被kill掉。
如果采用的是云服务器，可以购买100M按流量付费进行同步，同步完成之后再调整过去。
异常日志
如果查看日志发现节点频繁打印如下日志：
WARN [03-17|16:16:34] Synchronisation failed, retrying err="block download canceled (requested)"
WARN [03-17|16:19:04] Synchronisation failed, dropping peer peer=97685428ba8e71a0 err=timeout
WARN [03-17|16:22:59] Synchronisation failed, dropping peer peer=142bb4c4f4670f42 err=timeout
WARN [03-17|16:24:04] Synchronisation failed, dropping peer peer=5eb409e398c68508 err=timeout
WARN [03-17|16:25:13] Synchronisation failed, dropping peer peer=ccc9241c5adf919e err=timeout
WARN [03-17|16:27:10] Synchronisation failed, dropping peer peer=eff1874302a0e666 err=timeout
WARN [03-17|16:32:52] Synchronisation failed, retrying err="block download canceled (requested)"可考虑重启节点或手动添加peers。建议在网上寻找可用节点进行添加，比如星火的节点，或已经同步完成的数据节点。
如果添加查看节点或添加节点
执行以下命令查看节点：
> net.peerCount
添加节点执行以下命令：
>admin.addPeer("enode://0d1b9eed7afe2d5878d5d8a4c2066b600a3bcac2e5730586421af224e93a58cd03cac75bf0b2a62fd8049cd3692a085758cc1e407c8b2c94bb069814a5e8d0f0@209.9.106.245:30303")
true常用以太坊浏览器
https://block.bitbank.com/eth/
同步多久可以完成
目前来看，配置较高的用户基本上24小时左右即可同步完成，配置较低的几天或几周都很正常。
正常同步的日志是什么样子
正常同步数据的过程中日志格式如下：
INFO [03-17|17:02:57] Imported new chain segment blocks=1 txs=380 mgas=7.980 elapsed=45.080s mgasps=0.177 number=5235156 hash=7c7414…b84924
INFO [03-17|17:03:42] Imported new chain segment blocks=1 txs=379 mgas=7.978 elapsed=45.242s mgasps=0.176 number=5235157 hash=eb9541…39b945
INFO [03-17|17:04:32] Imported new chain segment blocks=1 txs=367 mgas=7.964 elapsed=50.074s mgasps=0.159 number=5235158 hash=be6c65…f10378
INFO [03-17|17:05:02] Imported new chain segment blocks=1 txs=150 mgas=4.285 elapsed=29.106s mgasps=0.147 number=5235159 hash=e3c5e2…c67c5c而非正常同步日志除了异常信息外，还有正在同步数据结构体的日志如下：
INFO [06-18|10:10:34] Imported new state entries count=384 elapsed=131.007ms processed=17120103 pending=23855
INFO [06-18|10:10:35] Imported new state entries count=384 elapsed=116.006ms processed=17120487 pending=23978
INFO [06-18|10:10:36] Imported new state entries count=384 elapsed=134.007ms processed=17120871 pending=24186
INFO [06-18|10:10:38] Imported new state entries count=384 elapsed=305.017ms 转自：https://blog.csdn.net/wo541075754/article/details/79593953
同步命令：
nohup geth --syncmode "fast" --port "30303" --cache=4096 --datadir /opt/ethbase --rpc --rpcapi db,eth,net,web3,personal,admin,miner --rpcport 8545 --rpcaddr 0.0.0.0 --rpccorsdomain "*" --maxpeers 40 --maxpendpeers 40 > output.log 2>&1 &
