昨晚在尝试在备机上replay STEEM，等了好久也不见响应，想想可能是反应迟钝，按着以往的经验，4-6个小时肯定会replay完成，于是就放到一旁忙其它事情去了。
(图源 ：pixabay)
结果消停了三两个小时，还没等我去看replay是否完成呢，我用于监控另外一个程序的报警器就开始嗷嗷报警了。
登录主机，看了一眼，并没有搞明白发生了什么事情，然后打算看一样另外那个程序的配置文件，发现打开文件时出现如下提示：
"E297: Write error in swap file"
啥？明明就是打开个小文件，咋还用到swap file了，百度一下，说这种出现这类错误有可能是硬盘满了，然后看了一下，果然硬盘占用已经达到100%。
想想我就操作STEEM了，过去一看，果然罪魁祸首在这呢：
可是这个问题咋引起的呢？难道是因为Soft fork 0.22.2？我换用0.22.1 replay 问题依旧，block_log.index，不讲道理地迅速增长。
为此我又尝试了清除block_log.index & shared_memory.bin， 也尝试重启VPS，问题依旧，这就让我有些抓狂了。
于是在群里向@ety001 以及 @abit请教，均判断可能是block_log 文件损坏，@ety001 还提供了 @someguy123 提供的一个block_log下载链接。
: ${BC_RSYNC="rsync://files.privex.io/steem/block_log"}
确定了问题所在，剩余的事情就简单了，我用truncate把文件尾剪裁掉一部分
truncate -s 245G block_log
(咳咳，手抖，裁多了，裁了约10G，其实裁掉1-2G就够用了。（让文件比rsync://files.privex.io/steem/block_log block_log这个小即可）
用rsync同步一下文件：
rsync -av --progress --append rsync://files.privex.io/steem/block_log block_log
之所以没用--append-verify而使用--append，因为我觉得我网络挺好的，不用校验。
弄完之后，再replay，终于出现熟悉的画面：
早晨起床看，已经恢复了正常：
这个折腾劲啊，不过总算折腾好了，让我热泪满眶，下次再也不敢瞎折腾了。
相关链接
https://steemit.com/~witnesses type in
oflyhigh and click VOTE
Vote @oflyhigh via Steemconnect
Thank you!
This page is synchronized from the post: ‘再也不敢瞎折腾啦：replay STEEM遇到怪问题’
