ETH1.0节点维护记录
1. ETH1.0 节点维护记录
1月24日，在测试服务器外环境上部署geth，当时发现其经过一段时间同步后会异常的持续进入trie node同步阶段，但并不影响同步和接口调用，因此未深究；
2月6日，在主服务器上通过Docker部署geth，在下一阶段前一切正常；
3月1日，服务器OOM，重启后为geth加上内存限制，至此开始出现各种问题：
geth开始频繁出现内存溢出问题，内存占用超过限制被Docker关停，最开始每次启动后能存活1-2天，后来一次启动只能存活数小时；
geth的同步暂停在了2月8号，如果进行重启，则同步会回滚到2月7号，然后在同步到2月8号后依然暂停；
geth异常的始终处在数据库压缩过程里：
3月7日，尝试设置缓存大小和垃圾回收机制去改善内存溢出问题，但没有效果；
3月8日，发现 docker pull 下来的 latest 的镜像是开发版而不是稳定版的，再换成稳定版之后，内存溢出的问题不再出现了，但是同步暂停和始终进行数据库压缩的问题依然没有解决；
3月9日，通过设置 nocompaction 标志去禁用数据库压缩，但没有效果；
3月16日，查询文档和issue，发现更换版本、程序突然停止都曾有人出现过数据库压缩问题，结合geth日志中的：
提出了始终进行数据库压缩的猜想：在上次服务器OOM时，数据库损坏了，虽然geth尝试进行了修复，但没有修复好。
同时发现 fast 节点在同步到接近 chain tip 的时候就会自动切换成full模式：
结合issue中有人把数据存到HDD里跟我碰到了同样的问题，提出了同步暂停的猜想：HDD带不起来full模式下的计算（这个在issue中有提到），所以它一直没法往前同步；
3月17日，开了一个新的节点用于验证猜想，新节点同步速度约为 1.6天/min ；
3月19日，新节点同步到2021年底，此时返回当前同步状态的RPC接口出现故障；
3月23日，对新节点进行重启后恢复正常，以高速同步到了3月20号（这印证了旧数据库确实是损坏了），随后同步速度大幅下降到了 0.2h/min ，这部分印证了上述的同步暂停的猜想；
3月24日，观察到新节点虽同步速度较慢，但一直在工作未出异常，于是将已经同步到3月20日的区块数据进行备份，并将旧节点和损坏的旧数据库删除；
3月25日，新节点同步到了3月24日后，RPC接口再次出现故障（这时我认为返回当前同步状态是geth最基础的接口，它挂了估计其他的也都挂了，后来证实我是错的），重启后同步到了当时的 4h 前，然后再次故障；
3月27日，加上了一旦监控到故障就自动进行重启的功能，一次启动可以存活约一个半小时，可以同步大半天的区块数据，同步的进度是能够赶得上出块的速度的，但这样取数据的接口会受到影响；并进一步发现它在同步到逼近当前时间时必定会发生故障：
3月28日，将节点分为A、B两个节点进行实验，A、B共用同一套，原先的新节点作为节点B，暂停运行；并尝试使用nodiscover标志去暂停同步，发现加入标志后节点不会进行同步，同时无法返回当前同步状态，但取数据的接口仍然可用，但无法同步的问题需要解决（当时设想的是通过加锁的方式，在无人取数据的时候让他同步）；
3月29日，暂停了A节点，启动节点B，果然发现即使不加入nodiscover取数据的接口仍可用，这样nodiscover标志就没有存在的意义了，所以就删掉了节点A，将正常的节点B移至节点A；
4月4日，抛弃了geth原生提供的RPC接口，使用自建的
get_block_timestamp接口，向上枚举块高，一旦节点无法返回对应块的信息，就证明该块还未同步到；迂回的获取了节点的同步状态，意外的发现他一直都在后台默默同步，也一直保持了接近实时的数据：
2022年5月11日，前几天服务器硬盘满了，节点宕机，本以为有3月份的备份，问题不大，但是将备份的数据库覆盖到当前数据库之后，节点一直处于
Generating state snapshot状态，无法使用接口。因此可得出，备份数据库无意义，只好从头开始同步。2022年5月14日，发现仅仅清空数据文件夹也不行，必须将容器删掉重新创建。
2. ETH1.0总结
该过程中我最大的错误就是过于信任了节点提供的关于自身状态的接口，而没有通过其他接口对实际情况进行测试；
千万不能让geth被暴力退出，否则极大概率会造成数据库损坏；为应对此情况，可定时备份一下区块数据，考虑到同步速度，每3个月左右备份一次即可；
2022年5月11日更新
备份并不能让节点恢复状态，备份无意义。
在启动参数中
--nocompaction标志来防止数据库压缩，用空间换取同步效率。