在之前的帖子中和大家一起学习了[如何使用Python获取指定区块在block_log中的位置信息](https://hive.blog/hive-105017/@oflyhigh/python-blocklog)，今天我们来实际测试一下利用上述信息修复被损坏的block_log，并测试不同情况的replay(重播）。


![image.png](https://images.hive.blog/DQmREjMm9FVCwaPRAZjXQMw2WwjeHu9xSG2LUuHvEqJ66W6/image.png)
(图源 ：[pixabay](https://pixabay.com/vectors/website-development-setting-tool-6700615/))


为了进行测试，我们首先关闭hived，并复制`block_log`以及`block_log.index`到新用户目录下，这样就算不小心搞坏，也不会影响我hived的正常运行。

尽管是在本地操作，但是因为`block_log`已经达到了500G以上，所以耗费了大概一个小时左右的时间，还真的需要点耐心呢。

复制后，两个文件长度信息如下：
>`-rw-rw-r-- 1 test1234 test1234 536100860926 Feb  5 14:55 block_log`
`-rw-rw-r-- 1 test1234 test1234    492444336 Feb  5 14:55 block_log.index`

# 测试直接启动hived

我们尝试直接启动hived，发现hived是无法正常启动的，因为缺少`shared_memory.bin`数据。
>![image.png](https://images.hive.blog/DQmUQQhwmD4vYCmC7BWni33sSoqHZ7zidvPLqT4zZY4c4t7/image.png)

其中最有价值的提示信息：
>`check_data_consisten ] Replaying is not finished. Synchronization is not allowed. { "block_log-head": 61555542, "state-head": 0 }`

我们也可以根据`block_log.index`长度计算出当前区块号：
>![image.png](https://images.hive.blog/DQmcHhtnvrt55eZyAsrTykSiQxC8YCyrpwW1ELJKdCgxBcU/image.png)

# 测试replay (重播)

因为`block_log`以及`block_log.index`当前都是完好的，并且区块高度相同。当前情况下我们是可以通过`--replay-blockchain`来对区块链进行replay操作，重建***state database***。

指令如下：
>`hived_v1.25.0  --replay-blockchain`

执行后正常开始replay：
>![image.png](https://images.hive.blog/DQmfFGdxFo3CL7CHpHwaGPew2uaFhgC4xySEKsGFUd3jMVA/image.png)


# 测试block_log损毁情况

首先人为模拟破坏block_log，删除其尾部的六个字节：
>`truncate -s 536100860920 block_log`

然后重新执行repaly操作：
>`hived_v1.25.0  --replay-blockchain`

我们会发现这个replay操作是无法进行的
>![image.png](https://images.hive.blog/DQmXkdSCHnXVUoo3UtHZxm2yD4kmtrSFztV9Mu9nDpxvv67/image.png)


这和我们日常遇到的大多数block_log损毁一样，当尾部被破坏时（应该是写入没写完整时hived被强制停掉等情况所导致），无法进行replay操作。


# 测试区块高度不一致的情况

### 测试block_pos < index_pos
通过之前文章中提供的脚本，我们计算出最后一块的位置：536100838940，然后将其截掉：
>`truncate -s 536100838940 block_log`

（通过最后一块的位置，以及block_log未损坏时的长度，可以计算出最后一块在block_log中的存储长度）。

经过这个操作之后，我们可以认为`block_log`以及`block_log.index`都是完好的，只是`block_log.index`比`block_log`块高高了一块。

我们再来试试replay，（***在进行操作之前，首先备份一下block_log.index***）。
>`hived_v1.25.0  --replay-blockchain`

以下为执行结果，注意其中的`block_pos < index_pos`，然后从头开始漫长的`Reconstructing Block Log Index using memory-mapped IO`:
>![image.png](https://images.hive.blog/DQmPyPy9JyiovZaSYs1oHpbXCmKuPXbVkUDWVXCr56xiFFc/image.png)

### 测试block_pos > index_pos
将block_log.index截掉16个字节后再次尝试replay：

>`hived_v1.25.0  --replay-blockchain`

以下为测试结果，注意其中的`Index is incomplete`，又是漫长的从头开始`Reconstructing Block Log Index using memory-mapped IO`:
>![image.png](https://images.hive.blog/DQmSEdDDz5PXJ5bNeE1sXahuztzrMfrVFsU7wcmeLV2cAvu/image.png)

### 测试没有`block_log.index`
彻底删除block_log.index后，再次尝试replay：
>`hived_v1.25.0  --replay-blockchain`

以下为测试结果，注意其中的`Index is empty`，之后又是漫长的`Reconstructing Block Log Index using memory-mapped IO`:
![image.png](https://images.hive.blog/DQmSMe7xa7vQk9C8oaofNJ3tqMhytDWkdYhjC34fRqYsXr2/image.png)

也就是说区块高度不一致，或者`block_log.index`不存在的情况都要进行`Reconstructing Block Log Index using memory-mapped IO`。

如果`block_log.index`不存在彻底不存在，其实重建index是没问题的，而高度不一致的情况重建index会白白浪费大量的时间。所以高度不一致的情况，应该首先考虑修复，然后再replay。

# 修复&replay

修复`block_log`以及`block_log.index`其实很简单，就是通过`block_log.index`最后一块，计算出最后一块在`block_log`中的位置，并且截短`block_log`以及`block_log.index`对应内容。

如果一块不行，就多截短几块，对于`block_log.index`而言，截掉对应块数*8个字节就好。

修复`block_log`并使`block_log.index`与其块高一致，就可以尝试replay了：
>`hived_v1.25.0  --replay-blockchain`

这时我们会看到replay正常进行，没有进行重建index，无疑节省了大量时间：
>![image.png](https://images.hive.blog/DQmdmtyn5qg9nWR4tRo22FSuvz9zhKXQM6P2D6eZGxk7XRC/image.png)

# 结论

我们可以通过计算`block_log.index`中后边某块在`block_log`中的位置并配合`truncate `工具来修复`block_log`；同时可以使用`truncate `移除指定块数*8字节来使`block_log`与`block_log.index`块高相同。

这样就实现了彻底修复的目的，而不必因为块高不同导致强行重建index（`Reconstructing Block Log Index using memory-mapped IO`），进而节省了大量的时间。

![image.png](https://images.hive.blog/DQmbcxzunFVtBndBApPwRv25TrjrJ3Ab34P24iHw22yb4fV/image.png)
(图源 ：[pixabay](https://pixabay.com/illustrations/lightbulb-bulb-light-idea-energy-1875247/))

好了，今天就学习到这里了。

# 相关链接

* [每天进步一点点：使用Python获取指定区块在block_log中的位置信息](https://hive.blog/hive-105017/@oflyhigh/python-blocklog)