为了方便，除了使用VPS运行HIVE的见证人主备节点，我在家里的电脑上也运行着一份HIVE节点程序，用于连接命令行钱包以及跑一些脚本等等。
(图源 ：pixabay)
周五下午，我突然发现的喂价（Price feed）一直没有更新，这时我在外地，尝试从外地连接家里电脑，发现无法连接，而周四的时候我还正常使用呢。
看了一下我的监控程序数据，大概从周五一早，家里的电脑就不工作了，而周五凌晨的时候，据说，沈阳这边又下大暴雨了，狂风暴雨闪电，我猜测可能是家里断电或者断网了。
为此我特意喊上物业的管家，让她趴我家窗户看一眼，看看我大电脑有没有正常运行。（如果正常运行的话，应该会看到CPU风扇巨亮无比的黄灯），结果管家回复我什么也看不到，果然大电脑断电了，哎。
不过好消息是，管家也没发现我家起火或者发洪水，也算是让我安心了一些。不过原本计划的长假只能告吹了，于是今天一早就出发，返回沈阳。
经过了N个小时的车程后（因为还要回父母家取芦丁鸡，所以折腾一大圈，路上又遭遇两场暴风雨），终于回到家中。
到家之后发现大电脑果然处理关机状态，开机登录后，发现HIVE节点以及其它一些程序果然因为突然掉电而彻底废掉。
于是乎，抓紧修复HIVE节点，这样我的一堆乱七八糟的才能回复正常工作。这时我发现，我之前研究过的block_log修复相关内容，起到了很大的作用。
原本修复被损坏的HIVE节点，我都是先将block_log切掉一部分，然后去和gtg提供的block_log文件同步，这样我就得到一份没有损坏的，相对较新的block_log。
然后在强制replay节点，经过超级漫长的等待以后，节点就修复好了。
听起来好像没啥问题对吧？然而这里边有一个重建block_log.index的漫长过程，这让原本很慢的replay过程更加耗时。
有一次我遇到节点崩溃和A神聊起这个问题，他给我大致如下方案：
通过block_log.index计算出指定的区块在block_log中的位置。
根据计算结果将block_log截短到指定区块的前一区块
同理将block_log.index截短到指定区块的前一区块。
这样做有两个显著的有点：一是完全依赖自己的数据，不用去和别人的数据同步；二是block_log和block_log.index快高完全一致，不用重建block_log.index，节省大量时间。
基于A神的方案，我做了一些学习和测试，比如使用Python获取指定区块在block_log中的位置信息以及实测block_log修复以及hive区块链Replay。
虽然当时学习和测试费了一番脑筋以及时间，但是这次真的遇到节点断电崩溃的问题，我依照以前学习的经验和结论，直接上手就开始修复，然后顺利地开始replay(无需重建block_log.index）。
这让我不禁小小地感慨一下，以前的学习没白费，汗水没白流。
(图源 ：pixabay)
不过，还是节点不出故障最好了，哎，尤其是我舒爽的长假，就这样被打断了。还有就是连续跑高速真的好累，尤其还遭遇两场大暴雨。