如何安全去掉 rocksdb 的 wal 以提升 PikiwiDB 性能

[KKorpse]

核心对话

denghao
我发现社区版的pika是同步binlog 但是可以关wal，这么说如果把binlog offset存一下 进程崩了是不是可以用binlog来恢复memtable的那一部分数据。我感觉解法还是关wal可能靠谱点。

Korpse
正好看过有篇论文讲的是怎么安全去掉 MyRocks 中的 wal，只保留 binlog，论文链接，中文讲解
大致来说就是每次 memtable 刷盘的时候，插入一对 kv 用作标记，标记里面存了 binlog 的 offset。恢复的时候就能知道需要从 binlog 的哪个位置开始重放了（后续称这个标记为 flag）

其实不需要知道 memtable 刷盘的时机，只需要每隔一段时间插入这样一对 flag 标记，恢复时取最后落盘的那个 flag 中的 offset 作为 binlog 恢复的初始位置就行。
然后涉及到多个 cf 的时候会有一些其它的细节要注意，比如每个 cf 的 flag 是独立的。

cheniujh
解决的问题是：当崩溃了，binlog应该从哪里开始读是嘛？

Korpse
对的，如果不记录这个标记，只能把binlog全部重放一次

完整记录

[AlexStocks]

from https://mp.weixin.qq.com/s/dV3A1_OFDXkMpDr-Vs71DQ

[cheniujh]

梳理了一下

记录里提到的方式有2种：
1 在memtable刷盘的时候记录binlog offset（比如利用RocksDB提供的EventListener），在利用binlog做恢复的时候是用这个offset记录来确保能精确地重放binlog（没有binlog被漏掉或操作已经落盘却重放）
这个方案，下一步要解决的问题： memtable刷盘的时候怎么知道这个memtable最后一次操作对应了哪条binlog？ 要记录的是最新的，落盘了的那个binlog

2 在RocksDB里定时插入一对kv，记录当前binlog最新的offset，当崩溃以后，查RocksDB来得到redo开始的binlog offset
这个方案中，从RocksDB查到的offset可能比最新实际落盘offset小一些，所以可能会有部分binlog被多次重放（其对应的操作实际上已经落盘），它并没有提供一个精确地redo起始位置，而是给个往前一些，又相对接近的起始位置。
如果要用这个方案，需要将Pika的binlog全部改造成幂等的

背景：Pika的binlog不具备幂等性，同一条binlog如果被重放/消费多次，可能影响数据库正确性，比如rpop list_xxx这种，不同于set k1 v1。后者执行多次数据依旧正确，但前者如果执行多次，数据就出错了

其他可能：
能不能不开binlog，崩溃恢复交给RocksDB，并且以WAL来做主从同步？
（不过乍一想也要一些问题需要解决）

[cheniujh]

更正：这里有些地方提到了"落盘了的binlog"，意思是 "这条binlog所对应的操作/更改，已经落盘，而不是说binlog本身落盘"

[gukj-spel]

原论文提到了当 Memory Buffer flush 的时候才刷入这个 FLush Flag。

[KKorpse]

是的，讨论的时候有的细节忘记了。