TIKV三台服务器所在IO都非常高，特别是jbd2/vdb1-8，IO占用50%以上。
插入数据过程中，jbd2/vdb1-8IO大幅度增加。每台TIKV都是相同的比例。存在大量的raftstore-x-x写操作。
使得数据写入到TIDB特别慢。
而且也升级到了最新的内核版本:
3.10.0-1062.18.1.el7.x86_64
也没启动作用。
当我将tikv的参数sync-log改为false后，io明显降下来了。
那么，关于raftstore sync-log作用，请教两个逻辑是否正确：
false时，是不是主节点落盘了不用强制从节点同时落盘，才认为数据写入成功？true时，是不是主节点和所有备份节点必须同时落盘，才认为数据写入成功？您好，
sync-log 默认为 true，表示强制将数据刷到磁盘上；只有当数据已写入超过 50% 的副本时，应用才返回 ACK（三副本中的两副本）
如果是非金融安全级别的业务场景，建议设置成 false， 以便获得更高的性能。
一般来说，开启 sync-log 会让性能损耗 30% 左右。
以下两篇文章对 sync-log 有相关阐述：
还要个问题想知道，麻烦解答下：
如果设置sync-log=false后，数据返回成功的逻辑是什么，主节点数据落盘就返回成功还是不落盘就返回成功？
您好，
是的，当sync-log=false 数据返回成功的逻辑是主节点数据落盘就返回成功。
那我设置sync-log=false 对业务应会有什么影响吗？我们这主要是些业务订单。
您好，
其实 《tidb in action》 可以回答你这个问题，但是需要你按照业务进行评估：
通过使用 Raft 一致性算法，数据在各 TiKV 节点间复制为多副本，以确保某个节点挂掉时数据的安全性。只有当数据已写入超过 50% 的副本时，应用才返回 ACK（三副本中的两副本）。但理论上两个节点也可能同时发生故障，所以除非是对性能要求高于数据安全的场景，一般都强烈推荐开启 sync-log。一般来说，开启 sync-log 会让性能损耗 30% 左右。
可以修改 conf/tikv.yml 中 raftstore 下面的 sync-log 参数：
[raftstore]
sync-log = true
可能存在丢失数据的风险
目前我也遇到这个问题了，7个tikv节点IO 都满了（我们的SSD并非nvme的所有性能更差。）
我想问下，除了修改sync-log=false外，还有没有其他的优化措施呢？ 谢谢~
我想问下，除了修改sync-log=false外，还有没有其他的优化措施呢？ 谢谢~
+65535
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。