TiKV:4.0.8
这两个参数的作用是什么?影响是什么?
sync-log是true的情况下，wal-bytes-per-sync这个参数有用吗？
1 个赞
sync-log控制同步刷盘，如果wal-bytes-per-sync设置了512k,这是个什么单位? 每秒512k的wal? 如果写入很多的话，岂不是这个会拦住写? 具体怎么控制的速率?
1 个赞
官网文档和github的toml文件中只有一句话，不是特别理解，想省个事儿直接问一波点透
。对写入的过程中到底哪个参数能影响写入速度想了解清楚些，有相关文档就非常好了
算，很慢了。这个是 raft 的监控吗 ？
是的，昨天的监控是这样的，上午这样调了下参数
[rocksdb.defaultcf]
write-buffer-size = "512MB"
[raftstore]
apply-pool-size = 4
store-pool-size = 4
[rocksdb]
wal-bytes-per-sync = "1M"
对wal-bytes-per-sync的参数工作原理不是特别了解，就来问下。
你这里面的两个链接我看了，很清楚。不过具体的wal-bytes-per-sync的工作原理还没解答。
我的疑问是:wal-bytes-per-sync这个参数难道是为了控制磁盘IO压力而设置的吗？如果这样的话，那岂不是wal写不下去，wal写不下去的话，整个数据库的写就卡住了。还不如直接让磁盘io打到满为止。
所以这个参数如果真是为了应对一个机器上多个rocksdb的时候，各个实例平等的利用io，那这个参数是有用的。
所以对这个参数的真是作用是不是上面我理解的，希望有了解的同学给个答案
可以用 metrictool 导出一下完整的 tikv-details 监控，我们一起看一下吧
这个参数是wal的刷盘策略，wal默认有三种刷盘策略：
1）sync模式，每个写请求都会刷盘，最终调用fsync刷盘，这种模式最安全，但效率最低；
2）wal-bytes-per-sync模式，如果设置为1M，则认为是写满1M数据后就刷盘，最多丢失1MB的数据；
3）default模式，交给OS来刷盘，安全性最低，丢失数据可能最多。
至于sync-log参数，有一段解释是这样的：
TiDB is based on the Raft consensus algorithm, it needs to make sure every raft log is persisted to the majority’s disk before committing them. To make sure a log is persisted, we need two steps:
- write(log_fd, log)
- fsync(log_fd)
When sync-log=false , TiDB skips fsync , it helps performance and is safe if there is no power failure. Set it to true, your data is always intact even if there is a power failure
What is the relationship between sync-log and wal-bytes-per-sync
bytes-per-sync
这个参数，官网解释的笼统，不知确切含义
DBOptions()::bytesPerSync()
Allows OS to incrementally sync files to disk while they are being written, asynchronously, in the background.
这里的files是指什么？
所以，按照这个解释，还是说只要开了sync-log=true，另一个参数没用了对吗？那另一个参数的意义是什么？好像还是没有得到答案。等有空我翻翻代码吧。
是的，按上面的理解是这样的
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。