EOS大事记:EOS 独立日 / 折腾:烦心事

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

image.png
(图源 :pixabay)

EOS 独立日

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

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

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

photo_2022-09-21_21-08-35.jpg

话说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都没被破坏,省却了修复这两个文件步骤(好吧,其实这两个修复起来还是挺简单的)。

WeChat Image_20220921200323.png

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

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

H2
H3
H4
3 columns
2 columns
1 column
Join the conversation now
Logo
Center