sync_binlog与Binlog_group_commit_sync_no_delay_count的区别

sync_binlog和Binlog_group_commit_sync_no_delay_count都是用来控制MySQL在写binlog时的刷盘策略，但两者的具体作用略有不同。sync_binlog的作用是控制MySQL写binlog时对磁盘的刷盘频率。sync_binlog的取值可以是0、1或N(N>1)，默认值为0。当sync_binlog为0时，MySQL会将binlog写入磁盘的操作交给操作系统，由操作系统在必要时将binlog刷入磁盘。这种方式性能最好，但可能会造成数据丢失。当sync_binlog为1时，MySQL会在每次提交事务时调用fsync强制将binlog写入磁盘，这种方式最安全，但性能最差。当sync_binlog为N(N>1)时，MySQL会累计N个事务才调用fsync刷盘，这种方式性能和安全性相对均衡。

Binlog_group_commit_sync_no_delay_count的作用则是控制MySQL写binlog时使用组提交的机制。当Binlog_group_commit_sync_no_delay_count为N(N>0)时，MySQL会累计N个事务后再将它们一起写入binlog文件，这可以减少磁盘IO操作，提升写入性能。但这种方式也可能会造成数据丢失，因为在组提交的过程中，如果MySQL崩溃或断电，那么还未写入磁盘的binlog信息就会丢失。

生产环境中如果对数据安全性要求很高，可以将sync_binlog设为1

KAiTO 发表于 2023-5-4 17:53
sync_binlog和Binlog_group_commit_sync_no_delay_count都是用来控制MySQL在写binlog时的刷盘策略，但两者 ...

手动点赞

KAiTO 发表于 2023-5-4 17:53
sync_binlog和Binlog_group_commit_sync_no_delay_count都是用来控制MySQL在写binlog时的刷盘策略，但两者 ...

首先感谢您的答复。另外看完您的解释我还是感觉当设置sync_binlog=N时，其作用跟Binlog_group_commit_sync_no_delay_count=N差不多啊。另外，如果sync_binlog=1，但是Binlog_group_commit_sync_no_delay_count=N，那么是不是还是会等待N个事务才会刷盘？这样的话sync_binlog=1还有作用吗？或者说这个sync_binlog的参数是否是老版本的参数，而新版本的MySQL因为都是组提交了，那么设置Binlog_group_commit_sync_no_delay_count这个参数是否更有意义？

eliu 发表于 2023-5-4 18:38
首先感谢您的答复。另外看完您的解释我还是感觉当设置sync_binlog=N时，其作用跟Binlog_group_commit_syn ...

或者说当设置sync_binlog=1时，我期望每次事务提交都会刷盘。但如果Binlog_group_commit_sync_no_delay_count=10假设，那么这时当不足10个事务的时候仍然不会刷盘，此时断电，那么就会导致已经进入queue中的所有事务的binlog丢失，假设queue中已经有5个事务，那么意味着这个5个事务的binlog都丢失了，因此跟我设置sync_binlog=1的期望是不符的。不知道是否可以这样理解？

组提交会丢数据？我理解组提交会延迟给应用返回的时间，如果在组提交期间数据库挂了，这个时候还没有给应用返回成功怎么会是丢数据呢？并且Binlog_group_commit_sync_no_delay_count这个参数需要跟另外一个参数一起使用才对。具体逻辑有没有大佬能解释下

我理解的组提交过程应该是client发起commit，server端开始吧这个事务放入一个组里面，如果组里面事务达到一定时间或者一定事务量，然后开始刷盘，刷盘成功后再给client返回。不知道理解对不对

leasion_li 发表于 2023-5-4 18:51
组提交会丢数据？我理解组提交会延迟给应用返回的时间，如果在组提交期间数据库挂了，这个时候还没有给应用 ...

确实，这时还没有返回。不过这两个参数之间是什么关系还是有点懵

KAiTO 发表于 2023-5-4 17:53
sync_binlog和Binlog_group_commit_sync_no_delay_count都是用来控制MySQL在写binlog时的刷盘策略，但两者 ...

如果已经有了组提交，sync_binlog是否设为1即可呢？
回答: 已经有了组提交，sync_binlog是可以设置为1

binlog_group_commit_sync_no_delay_count=N和sync_binlog=1/N参数区别?
回答: binlog_group_commit_sync_no_delay_count=N 一组事务产生的日志去写binlog
sync_binlog=N ； N个事务提交后去binlog,都是为了减少数据库的随机IO

Binlog_group_commit_sync_no_delay_count=N和sync_binlog =N参数的区别是啥 ，生产环境怎么设比较好呢？
回答: 生产上 如果5.7后期或者8.0的版本,磁盘没有到瓶颈,组提交可以不用设置保持默认就可以了,把writeset功能打开经量使用writeset功能
binlog_group_commit_sync_delay=0
binlog_group_commit_sync_no_delay_count=0
sync_binlog =1
binlog_transaction_dependency_tracking=WRITESET





首先感谢您的答复。另外看完您的解释我还是感觉当设置sync_binlog=N时，
其作用跟Binlog_group_commit_sync_no_delay_count=N差不多啊。
另外，如果sync_binlog=1，但是Binlog_group_commit_sync_no_delay_count=N，
那么是不是还是会等待N个事务才会刷盘？这样的话sync_binlog=1还有作用吗？
或者说这个sync_binlog的参数是否是老版本的参数，而新版本的MySQL因为都是组提交了，
那么设置Binlog_group_commit_sync_no_delay_count这个参数是否更有意义？


1. 如果 使用了组提交 sync_binlog=1，但是Binlog_group_commit_sync_no_delay_count=N，
那么是不是还是会等待N个事务才会刷盘？这样的话sync_binlog=1还有作用吗？

回答: 会等待 N个事务，有作用,sync_binlog=1,后是一组事务产生的日志进行提交一次,相当在主库上做了一个IO合并,减少和磁盘IO的交互和随机IO.


2.没有使用组提交时
回答:sync_binlog=1 ;一个事务提交一次,磁盘随机io会比较大,

leasion_li 发表于 2023-5-4 18:51
组提交会丢数据？我理解组提交会延迟给应用返回的时间，如果在组提交期间数据库挂了，这个时候还没有给应用 ...

启用组提交会丢数据？

回答: 启用组提交会不会丢数据,这个和没有组提交这个功能是一样的情况
主要看是sync_binlog参数和 innodb_flush_log_at_trx_commit是怎么样设置的
innodb事务提交WAL日志先行,都需要先记录事务对应的日志,
在innodb后台线程在异步去把脏页刷到磁盘上
sync_binlog=0/1/N ; innodb_flush_log_at_trx_commit=0/1/2
不同的配置的组合,只是把事务产生的日志提交到不同的地方， 没有组提交之
前是一个事务对应的日志提交到日志缓存上,或者磁盘上的日志文件上
，有组提交后是一组事务对应的日志,提交到日志缓存文件,或者直接到磁盘上。
比如,一个update 操作 提交了 如果不是双 1 的情况,事务提交了 日志提交后没有持久化到 磁盘文件上
而是在内存文件中,这个update操作产生的脏页还在IBP中的 flush list 中,是异步刷到磁盘上的,这个时候如果异常宕机了
不是双 1 的情况下 日志还在内存文件中 ,IBP中脏页也没有了 持久化到磁盘这个时候数据就丢了
这个情况下 ,没有组提交可能是丢一个事务，使用组提交可能的丢一组事务;