先说昨晚EOS上发生的大事，之后再说自己榆木脑袋+手欠导致的烦心事，一件一件来讲。

(图源 ：pixabay)

EOS 独立日

北京时间， 2022年9月21日21时，EOS主网成功完成了向 Antelope Leap 3.1的共识升级。

这次升级，也标志着原本由B1把控的代码库彻底由社区共同维护的代码库，实现了投票将B1票权作废后在代码库上彻底摆脱了B1的把控和影响。

所以，EOS社区的很多人，都把这次共识升级的日子，称为——EOS独立日。

话说EOS共识升级之前，我混到EOS共识升级的在线会议中，感受了一把紧张又兴奋的气氛。不过对我而言，除了发现男的都很帅，妹子们都很漂亮外，几乎啥也听不懂。哈哈哈。

反正可以看懂的就是，在北京时间21点整，BP们执行了共识升级的多签提案，然后顺利地通过了，共识升级成功！

曾经加在EOS之上的枷锁已经打开，那么EOS会再次腾飞嘛？让我们拭目以待吧。

失误导致HIVE节点损坏

再说昨晚发生的一件悲催的事情，昨天物业通知第二天电业局检修停电，为了避免出现突然断电导致我本地hive节点数据被破坏，昨晚我决定自己主动关掉节点，然后关机等断电。

关机之后我才想起来，我hive节点的shared_memory.bin是放在内存中的，这意味着我关机之后，这部分数据也会丢失。

虽然知道发生这种情况的几率应该是100%，但是还是不死心开机看了一眼，果然HIVE节点无法启动了，其中关键的提示信息如下：

check_data_consisten ] Replaying is not finished. Synchronization is not allowed. { "block_log-head": 68099251, "state-head": 0 }

正确的做法关掉节点后，将shared_memory.bin从内存拷贝到文件目录下，然后再关机。等需要重新启动HIVE节点时，再将shared_memory.bin拷贝到内存之中。

哎，这个悲催劲，这脑袋秀逗了，才会犯这样低级的错误，哎，只好继续重新replay了，好在我主动关闭的节点，block_log以及block_log.index都没被破坏，省却了修复这两个文件步骤（好吧，其实这两个修复起来还是挺简单的）。

另外，关于如何修复HIVE节点，我又冒出了个新想法，就是从第三方下载shared_memory.bin，然后根据shared_memory.bin中读出的state-head来截处理block_log以及block_log.index，不过我不知道shared_memory.bin如何去读，以后空闲时研究一下吧。

哎，折腾吧，人生的意义不就是折腾嘛？有句话咋说来着：不为无益之事，何以遣有涯之生？