为什么太坊这种几千亿市值的项目，居然连断电保护都做不好？

[dw2693734d]

家里的电脑突然断电，然后重启 Geth 全节点，然后数据就丢了

[ryants]

@dw2693734d 那就损坏到 blk 数据了，这种情况我没遇到过，建议重新起一个跑，可以把同目录 ancient 文件夹拷贝到新的目标的文件夹，应该会少同步一些。

[dw2693734d]

@ryants 好的，谢谢，原来还可以复制 ancient 数据

[Aumujun]

单节点程序没办法在断电时完美保障数据吧

[leavic]

几千亿市值是给写客户端的程序员了吗？

[zmy2000]

每日一笑

[meeop]

这是你的问题,是你挂了,又不是以太坊挂了

这倒是说明以太坊很稳定,你看你挂了并不影响以太坊网络,说明其非常健壮

[dw2693734d]

@meeop 是的，我没有说是以太坊的问题，我说的是 geth 的问题，可能表达欠妥，不好意思

[greensea]

恭喜楼主入坑，我之前做区块链项目，也是自己跑全节点，结果各种坑层出不穷，都是客户端的锅。
你以后还会遇到更多的问题，如果已经上线的话，请做好服务中断的准备。
当时我们用了两台服务器互作热备，也出现过双机失效的情况，最大的原因是这东西数据一坏，就有可能要重头开始同步，没一两周跑不完。
如果数据库是因为断电坏了那还说得过去，可这东西自己跑着跑着自己就崩溃了，然后数据库就挂了，我真是不知道说什么好。
geth 和 parity 都有问题，楼主也别想通过更换客户端解决。
最后建议就是，直接用现成的 RPC 服务，不要自己搭全节点，如果非要自己搭全节点，搞四台服务器，跑不同版本的客户端，每小时停一个节点做个磁盘快照，这可能就样比较稳妥了吧

[DiffView]

geth 问题多的一批，你做啥要自己搞 full node ？

[hadesjaky0607]

@greensea 可以自己写脚本对区块数据进行备份， 直接替换，省的每次都 reindex

[greensea]

@hadesjaky0607 有考虑过，但是上 TB 的数据备份起来也挺花时间的，在这期间数据库一改，全部完蛋，所以只能停了节点再备份。
然而，就算是停了节点再备份，等备份完毕之后，这节点又要花时间去赶进度，这又多了额外的调度逻辑，越来越复杂了。
结果最后就是停节点然后做快照是最合适的。

[74123gzy]

你不就是那几千万分之一么，你自己没做好断电保护