维护日志：遭遇cnode 分叉，修复处理

前文再续，书接上回 听从了大佬建议。以为自己只是遇上了意外重启，草率地在 db 目录下加了 clean 标记。
之后又过了两天，发现节点又卡在 starting 状态

检查日志，看到持续报在 slot 57200220 上对 tx MEMPOOL一直报错无法处理。提示与其他节点断开重置。 (Connection reset by peer)) "(recv errored)

没空究其原因，也许遭遇了其他分叉节点的数据污染，当务之急是修正数据启动节点，因为还有不到12个小时就到 leadlog 预告的出块时间。
而该死地这个问题发生在 core node 上

首先停掉节点

systemctl stop cnode

然后清除掉 免自检标记

cd $CNODE_HOME/db
rm -f clean

删除部分错误的区块记录

进入目录 immutable， 看到文件是按照数字编号和时间创建的
结合之前日志判断大约是哪个时间开始的数据异常，删除异常时间之前的数据
我这里同步到 02659, 但从重启和报错的时间看决定删除4月份3天的数据也就是从 02612 开始

cd $CNODE_HOME/db/immutable
rm -f 0261*
rm -f 0262*
rm -f 0263*
rm -f 0264*
rm -f 0265*
rm -f ../ledger/*

亡羊补牢锁定 topology 文件，避免再次被分叉节点污染。

之前比较偷懒在做完一系列的实验性质配置后，让 topologyUpdater 服务一直运行着，觉得这样也挺好的能连上更多的外部节点让自己的tx 扩散得更快。经过这次发现确实不妥，还是得老老实实改回只链接自己的 relay。 即使出问题了，也有 relay在最前线顶住第一波。

第一步编辑 tp配置文件，删除剩下自己的relay,路径在 $CNODE_HOME/files/topology.json , 过程略

第二步 停掉 topologyUpdater 相关的服务

systemctl | grep cnode

可以看到 cnode-tu- 开头的就是相关的服务都关掉

systemctl disable cnode-tu-fetch.service
systemctl disable cnode-tu-push.service

关闭的时候会提示这两个service 还绑定了各自的 timer 定时会触发启动，相同操作也关掉，过程略。

systemctl disable cnode-tu-fetch.timer
systemctl disable cnode-tu-push.timer

重启节点

systemctl restart node

重启后老老实实等漫长的验证和重新同步，节点恢复正常。因为这次只和relay通信，而我本地还有两个节点是在内网的所以同步的速度还算可以。

验证的时间太长了，眼见7个小时还没完成一半，于是启动应急方案，把core临时迁移到同网下另一台relay，把relay升格成 core。
换句话说要进行一次 core node 的迁移，下一篇详述

-待续-