前两天发文说见证人节点的`block_log`莫名其妙地损坏，导致我又重新replay节点，而在replay之前，需要先对`block_log`进行修复。


![image.png](https://images.hive.blog/DQmNqVdGGWP9t9sYJvBfjsbbB14xhAfhr77b6F85zz1ecJc/image.png)
(图源 ：[pixabay](https://pixabay.com/photos/despaired-businessman-business-2261021/))

# 我的方法

我采取的修复方式是将`block_log`截短一小段，然后去和@gtg提供的`block_log`同步，这样就得到一个完好的`block_log`文件。

然后再去replay，不过因为`block_log`与`block_log.index`文件快高不一致，所以replay时要重新计算更新`block_log.index`文件，要耗费很长时间。

当时我在想，如果我知道`block_log`与`block_log.index`文件文件的具体格式，或许可以直接修复`block_log`，而不用去和别人同步。

# A神的方法

和A神说了这个问题后，A神马上给我一套解决方案，大致思路就是通过`block_log.index`计算出指定的区块在`block_log`中的位置。

然后根据计算结果将`block_log`截短到指定区块的前一区块，同理将`block_log.index`截短到指定区块的前一区块。

比如说通过`block_log.index`可以计算出最近的不可逆块（当然也可以根据实际情况再向前切5到10个块），然后在`block_log`以及`block_log.index`切除掉这个块对应的数据，这样就达到切除坏数据的目的了。

# 优劣对比

首先，A神的方法精准定位后仅需对`block_log`的切除一点点，相比我不知道具体数据盲切一大块要好多了。

A神的方法有个好处就是***无需依赖于别人提供的block_log来同步***。尽管@gtg提供了靠谱的block_log文件，但是能不用同步别人的总比去同步别人的要好。

另一个好处就是因为都是依据同一区块高度处理，所以***不会存在区块高度不一致的问题***，replay时省却了重新计算`block_log.index`的过程，大幅节省时间。

如果比较我和A神处理方法，那么我的方法大概是：病人手指尖有病灶，我直接把病入的手剁掉（截肢），然后移植一个新手过来，然后耗费大量的时间等病人的手长好。

而A神的方法，好比知道病人的手指间有病灶，那么通过微创手术直接切掉病灶部位，病人的手可以很快地长好恢复。

都能解决问题的情况下，截肢并移植 vs 微创手术，花销多少，孰优孰劣一目了然了吧？我不禁为我之前的处理故障时还觉得自己很厉害而感到惭愧不已。

![image.png](https://images.hive.blog/DQmbaqxiTP7xKQY89zUR4GWhr6V7UChq1v2aTRE5jvtNShV/image.png)
(图源 ：[pixabay](https://pixabay.com/photos/apple-books-still-life-fruit-food-256261/))

A神之所以如此厉害，是因为他对整个系统的代码都很熟悉而且有着深刻的理解，像我这样大把时间都用在游山玩水以及喝酒聚会上的人，几乎不用指望做到A神这种程度了。😓

其实每次和A神沟通都有很多收获，不过因为知晓他实在是太忙，不忍心打扰他，也不忍心浪费他的宝贵时间。我还是~~慢慢摸索吧~~出去喝酒吧。

什么？你不知道A神是谁？那你OUT了，A神YYDS！为了避免打扰到A神，我就不艾特他了，哈哈。

# 相关链接

* [晕，见证人节点真的炸掉了 & 在内存中replay HIVE节点](https://hive.blog/hive-105017/@oflyhigh/and-replay-hive)