【 TiDB 使用环境】生产环境
【 TiDB 版本】v6.1.0
【复现路径】现场断电，TiKV server启动失败，报错raftlog可能丢失。
【遇到的问题：问题现象及影响】TiKV启动失败，是否有可能强行跳过错误的raftlog而重启TiKV呢？尝试调整过recover-mode为tolerate-any-corruption，启动仍然报raft丢数据的错误。之前测试过，一旦丢失raftlog超过一定的量，这个配置就失效。但从理论上讲，一台节点的raftlog丢失不会影响到集群整体数据的完整性，如果因为这个而重建TikV节点有点小题大做了。
【附件：截图/日志/监控】
经历过一样的问题，我在一番折腾之后，选择了重建集群，但方案确实不美
目前好像不支持手动模式，即使不重建这个节点，也需要做一些有损恢复，操作比较麻烦，可能重建更简单… 
嗐，属实有点头疼
那请问一下老哥，如果把tikv调整配置bytes-per-sync=0，raft日志直接落盘，这样在断电的时候是不是就好恢复了
可以参考下：
bytes-per-sync 是 TiKV 中 RocksDB 的一个参数，用于控制 RocksDB 在写入数据时进行 fsync 的频率。具体来说，当 RocksDB 写入的数据大小达到 bytes-per-sync 时，就会进行一次 fsync 操作，将数据刷入磁盘。这个参数的默认值是 0，表示不限制写入数据大小，每次写入都会进行 fsync 操作。如果将其设置为一个较大的值，可以减少 fsync 操作的次数，提高写入性能，但是可能会增加数据丢失的风险。如果将其设置为 0，可以保证数据不会丢失，但是写入性能会受到一定影响。
wal-bytes-per-sync 和 bytes-per-sync 都是 TiKV 中 RocksDB 的参数，用于控制 RocksDB 在写入数据时进行 fsync 的频率。它们的作用类似，但是作用的对象不同。
具体来说，bytes-per-sync 控制的是写入 SST 文件时进行 fsync 的频率，而 wal-bytes-per-sync 控制的是写入 WAL 文件时进行 fsync 的频率。WAL 文件是 RocksDB 中的 Write-Ahead Log，用于记录数据的变更操作，保证数据的一致性和持久性。因此，对于 WAL 文件的写入，需要更加频繁地进行 fsync 操作，以保证数据不会丢失。
这两个参数的默认值分别为 "1MB" 和 "512KB"，可以根据实际情况进行调整。如果将这两个参数都设置为 0，表示每次写入都会进行 fsync 操作，可以保证数据的一致性和持久性，但是会影响写入性能。
https://docs.pingcap.com/zh/tidb/stable/tikv-configuration-file
1 个赞