cnode: relay节点经常掉线 resync 问题的解决 part.1
其中一个relay节点，配置最低的一台。最近两个月不时掉线。掉线之后cnode进城自动重启后会清空 $CNODE/db/immutable/ 目录把整个区块链进行重新同步。
在同步过程耗费巨量时间之后可能在中途再度发生写入错误或者分叉，导致出错。周而复始又清空重新同步导致节点一直无法完成启动。而且持续大量写入SSD, 对硬件寿命和稳定性都造成严重的影响。
*先说结论，问题是否得到彻底解决未知，仍在观察中。具体操作直接跳到最后一段。
以下是这两个月来采取过的几个措施，收效一般。
1. 从其他运行正常的cardano 节点备份区块库恢复到出问题的节点。
为此还专门出了一个视频 https://www.youtube.com/watch?v=fBwATNkLHiM 说明如何备份 $CNODE/db/immutable/
区块备份网盘： https://www.123pan.com/1993768
为了加速恢复还备份导出了 db 目录下的 ledger 和 volatile , 使之进度与正常节点最接近。
并在恢复后 在 $CNODE/db/ 目录下新建一个 空文件 clean，令节点启动引导的时候跳过校验。
touch clean
然后发现即使数据被完整备份恢复，依然有可能启动失败。
2. 怀疑硬件故障，更换SSD
由于持续的出险类似故障，做进一步的检查。发现解压打包的区块链数据的时候，随机出现解压出错提示。对打包文件和解压后的文件分别进行校验。也发现文件随机出现不一致的情况。
怀疑是库存的SSD盘（SATA 镁光 M600, 500G）有问题，检查 smart 发现 #05 有1处标记坏块。 这台节点机器不支持 nvme SSD 只有SATA接口和msata。早前糟糕的使用体验使我不想使用msata。于是下血本新购买一块三星870，重新部署了包括操作系统在内的整个节点环境。
艹，发现问题还是重现！
无论是sftp传输 打包的 区块库，还是对区块库包进行解压操作，都可能出现随机的文件损坏。
文件校验检查操作：
1) 对文件进行 md5sum
cd $CNODE/db/
md5sum immutable/* > imall.07.md5
2) 与正常节点上的文件同样方法产生的校验数据 imall.raw.md5 进行对比
diff imall.07.md5 imall.raw.md5
找出受损的文件进行局部替换直到所有备份还原文件一致。
此时怀疑是三种可能。
- 因为性能不足，导致文件处理的时候积热高温产生错误；
- sata数据线故障或内存缺少ECC 导致的随机数据错误；
- cnode 在引导阶段会进行的陷阱自检，对不可靠的数据或部署环境或硬件进行测试，不通过启动失败数据自毁。
3. 死马当活马医，受目录结构和数据性质启发，锁定区块库
既然顾名思义 immutable 是一些静态的区块历史数据，为了避免无限重复劳动不停的对这些文件进行恢复操作。决定对这些静态数据进行锁定。包括连 cntools 管理工具都禁止它删除和改动这些区块数据，只允许读取。
- 前提还是要恢复数据，而且按上文的校验方法做一次手动的校验，保证数据是正确和完整的。
- 对数据进行锁定(解锁最后最新的一个区块数据，因为这个数据还未完整仍在写入)
cd $CNODE/db/immutable
chattr +i *
chattr -i 04211.*
一切检查妥当之后，再次启动节点 systemctl start cnode ， 这次启动成功了。
但...是否已经被彻底解决，还需要观察。
