hasagi

有没有pika coredump信息？sentinel内部使用了pub-sub命令，而pub-sub已知存在并发安全性问题（#965），可能导致coredump。

WAL文件本质是redo log的，一旦相关的内存信息（write buffer内容）持久化到磁盘（sst文件），那这部分log就可以安全删除了。所以和cf的write buffer size相关。

不严格的来讲，可以粗略认为db_write_buffer_size是WAL的上限，write_buffer_size为下限（在未手动设置max_wal_size和flush cf的前提下）。大多数情况下，每个cf的数据量和负载是不一样的，所以同时写满的概率极低。拿咱们的list来说，一个为meta cf，一个为data cf，显然data cf的数据量和负载更大，更容易写满（触发flush，切换WAL）。

可以先查看下相关数据结构的rocksdb日志。如果是write stall，write stop都会有提示信息。

看这像是磁盘瓶颈，带宽太低了。

可能是磁盘出现了slient error

您好，这个问题出错的直接原因是：报错的实例存在**padding items**。**padding items**是该节点以slave身份运行时，全量同步master数据产生的（从节点全量同步完成之后，会将自己本地已有binlog填充**0**，直到全同步点位为止）。下次读取数据（比如，作为master，同步数据给slave），一旦读到该同步点位之前的数据就会产生该报错。这个问题，已经通过引入snapshot point修复，但尚未提交。目前解决方式是：1）若为slave，重新强制全量同步。2）若为master，使其余slave强制全量同步。

Regarding this issue, I have submitted a fix PR https://github.com/facebook/rocksdb/pull/12490

@PFZheng hello，这个目前还有规划吗？

Neither did I.