MySQL5.7 binlog_group_commit_sync_delay对并发复制性能的影响

最新推荐文章于 2023-10-07 17:26:03 发布
原创 最新推荐文章于 2023-10-07 17:26:03 发布 · 1.8k 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#mysql #性能

本文探讨了MySQL5.7中binlog_group_commit_sync_delay参数如何影响并发复制性能。在升级至5.7后，尽管引入了逻辑时钟并行复制，但在默认设置下性能提升不明显。通过在40核服务器上进行测试，配置了大于数据大小的buffer_pool_size，使用SAS口SSD，并设置slave_parallel_type为LOGICAL_CLOCK和slave_parallel_workers为10。调整binlog_group_commit_sync_delay参数后，观察到主库语句响应时间、备库TPS和延迟追回效率的变化，以评估其对系统性能的实际影响。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

序言

MySQL5.7引入了基于逻辑时钟的并行复制的概念，让保守延迟困扰的我看到了一丝曙光。开心的将典型的库（6500/s TPS）升级到5.7之后，发现在默认的参数下提升并不明显。受Percona的关于并行复制这篇文章的启发，开始对参数binlog_group_commit_sync_delay调整对实际环境影响的验证。

环境

40核
buffer_pool_size >>data_size
数据目录使用SAS口的SSD
主库6500/s的insert、update、delete
slave_parallel_type=LOGICAL_CLOCK
备库slave_parallel_workers=10

测试用例

调整binlog_group_commit_sync_delay
观察主库语句响应时间、备库TPS和延迟追回效率 三个指标

测试结果

主库RT分布0102050
0.000126.58%0.01%0.01%0.01%
0.00173.41%99.63%99.62%99.46%
0.010.01%0.35%0.36%0.50%
0.10.01%0.00%0.01%0.03%
10.00%0.00%0.00%0.00%
Slave TPS7778110061038710814
Catch/10s12.67s16.08s14.64s13.12s
MySQL binlog group commit--sync stage
帅的数说
09-17 1669
说明： 1、如果sync_binlog等于1，那么need_LOCK_log为TRUE，然后将thd放到队列后，就不会释放该锁，等待sync_binlog_file调用结束后即文件sync后才解锁。这样在flush阶段sigal_update唤醒binlog dump线程后，dump线程会在此时才能获取到LOCK_log锁，即binlog 持久化到磁盘后，才会将binlog发送到slave。
mysql多线程复制binlog_MySQL并发复制系列一：binlog组提交 (转载)
weixin_39783512的博客
01-19 281
http://blog.csdn.net/woqutechteam/article/details/51178803MySQL Binary log在MySQL 5.1版本后推出主要用于主备复制的搭建，我们回顾下MySQL 在开启/关闭 Binary Log功能时是如何工作的 。MySQL没有开启Binary log的情况下：InnoDB存储引擎通过redo和undo日志可以safe crash...
binlog_group_commit_sync_delay 参数对并发的影响
weixin_34068198的博客
09-06 1016
一、现象 某天，开发人员找到了我，说是某条 UPDATE 语句执行需要 零点几秒，这个速度他们不能接受。不管怎样，首先看一下 SQL 是怎样的： update t set name='a' where id = 1 数据量 100万，id 是 主键 二、问题排查 2.1 首先排除下执行计划问题 理论上来说走的是主键扫描。那么，首先怀疑一下是不是执行计划出错，走了全表扫。...
Mysql主从复制之binlog_group_commit_sync_delay
liys0811的博客
10-07 581
slave并发复制就是MTS（multi thread slave）的初衷就是为了解决主库过于繁忙造成从库延时较大，不是为了解决表没有主键且全表更新或则全表删除引发的主从延时，感觉这个主从复制并发意义不是很大。的事务才能并发复制，组提交（group commit）是mysql处理日志的一种优化方式，主要为了解决写日志时频繁刷磁盘的问题。2binlog_group_commit_sync_no_delay_count 参数，表示累积多少次以后才调用 fsync。简而言之就是，只有同一。
binlog_group_commit_sync_delay设置导致的问题
Zhaojianxin_jerry的博客
06-12 456
于是我觉得时间耗在了写入binlog上（我验证过关闭binlog后写入很快），问题应该出在binlog刷盘上，于是我查看关于日志刷盘相关的参数，最后发现是这个参数设置导致的。于是我关闭该参数（binlog_group_commit_sync_delay = 0）后问题解决，其实直接关闭这个参数会影响innodb高并发的.公司和第三方合作的项目，在连调的时候发现超时了（超过1s就超时），查看业务日志发现是写库导致的超时。后来我发现只要是写入数据的操作都会超过1s。
mysql group commit_MySQL 5.6性能提升的武器：Binlog Group Commit
weixin_33374400的博客
02-01 233
在MySQL发布第一个5.6的GA版本时，我们对5.5.28 VS 5.6.10 做了个简单的sysbench性能对比测试(见之前的博客)，测试是基于我们自己的标准配置(innodb_flush_log_at_trx_commit=1 & sync_binlog=1)。从测试结果来看，5.6的性能提升非常明显，但是我们当时并没有进行深入研究，定位到实际带来性能提升的最大原因。后来有次读到一...
这套方法论，彻底终结MySQL同步延迟问题！
bobo now~
11-13 669
这套方法论，彻底终结MySQL同步延迟问题！
一篇文带你彻底解决mysql的主从复制延迟问题
Emmliy的博客
07-14 778
前言 ​ 在之前我们已经讲解了一主一从，双主双从的mysql集群搭建，在单机应用的时候看起来没有问题，但是在企业的生产环境中，在很多情况下都会有复制延迟的问题。所以我来了！！！ ​ 主从复制的原理我们在此处就不再赘述了，之前已经讲过了，这是一个老生常谈的问题，原理性质的也几乎在面试中问烂了，这些原理性质的东西并不是很难，但是你需要注意了，主从复制的延迟问题会成为一个难点，能非常全面的考验同学们的技术实力。 1、如何查看同步延迟状态？ ​ 在从服务器上通过 show slave status 查看具体的参数
mysql5.7 创建简单的复制关系
u010648194的博客
03-26 1365
准备工作： 一台主机安装了两台mysql实例， 3307端口用-S /tmp/mysql.sock1连接，3308端口用-S /tmp/mysql.sock2连接。 3307为主机，3308为复制机。 一、主机上备份数据库 mysqldump --single-transaction --master-data=1 -A -S /tmp/mysql.sock1 > fullbackup.sql 二、在从机上面恢复数据 mysql -S /tmp/mysql.sock2 -u.
MySQL Binlog 组提交实现
Huangjiazhen711的博客
09-25 662
因此，判断 sync_counter + 1 >= get_sync_period()，表示当前的 leader 可以 sync 了，那么该线程继续等一会儿，等待更多的线程进入 sync queue 在一起提交，具体等多久，由 opt_binlog_group_commit_sync_no_delay_count 和 opt_binlog_group_commit_sync_delay 决定。后来组提交和流水线提交的引入，不仅减少了 IO 次数，还提高了事务执行的并发度，减小了加锁的粒度。
MySQL 5.7新特性：并行复制原理（MTS）
热门推荐
总有些事，值得你去努力
08-27 1万+
众所周知，MySQL的复制延迟是一直被诟病的问题之一，在MySQL 5.7版本已经支持“真正”的并行复制功能，官方称为为enhanced multi-threaded slave（简称MTS），因此复制延迟问题已经得到了极大的改进。总之，MySQL 5.7版本后，复制延迟问题永不存在。 一、MySQL 5.6并行复制架构 从MySQL 5.6.3版本开始就支持所谓的并行复制了，但是其并行只是基...
关于MySQL主从复制的数据同步延迟问题
YYniannian的博客
07-31 235
SBM（Seconds Behind Master）在进行计算的时候就是按照这样的方式，每个事务的 binlog 中都有一个时间字段，用于记录主库写入的时间，从库取出当前正在执行的事务的时间字段的值，计算它与当前系统时间的差值，得到SBM。......
MySQL5.7新特性之多线程复制
雪辉博客
08-26 783
文章目录MySQL5.7新特性之多线程复制一、背景1.1传统主从复制存在的问题1.2降低复制延迟的方法二、MySQL5.6的多线程复制2.1MySQL5.6多线程复制的实现2.2MySQL5.6的多线程复制的缺点三、MySQL5.7的多线程复制3.1MySQL的组提交3.2MySQL5.7多线程复制的实现四、MySQL事务提交方式及多线程复制分发4.1MySQL5.7中事务提交方式4.2多线程复制...
mysql 复制 binlog_MySQL并发复制系列一：binlog组提交
weixin_42503036的博客
01-19 227
MySQL二阶段提交流程：StorageEngine(InnoDB) transaction prepare阶段：即sql语句已经成功执行并生成redo和undo的内存日志Binarylog日志提提交write()将binary log内存日志数据写入文件系统缓存fsync()将binary log 文件系统缓存日志数据永久写入磁盘StorageEngine(InnoDB)内部提交commit阶段...
这套方法论，彻底终结MySQL同步延迟问题
weixin_33906657的博客
05-04 154
作者介绍 张秀云，网名飞鸿无痕，现任职于腾讯，负责腾讯金融数据库的运维和优化工作。2007年开始从事运维方面的工作，经历过网络管理员、Linux运维工程师、DBA、分布式存储运维等多个IT职位。对Linux运维、MySQL数据库、分布式存储有丰富的经验。简书地址： https://www.jianshu.com/u/9346dc2e9d3e 作为一名DBA，我们在工作中会经常遇到一些M...
binlog组提交
qiuyepiaoling的专栏
12-24 803
原文:https://www.cnblogs.com/0591jb/p/13918052.html 通过sync_binlog=1控制事件持久化到磁盘，每次事务提交时进行fsync操作，将消耗大量的磁盘IOPS，如何最大化的提高性能，降低fsync对事务高并发的影响呢？ 一. 二阶段提交 binlog是MySQL服务层产生的日志，每个线程有独立的缓存，在事务提交时才写入磁盘(fsync行为依赖sync_binlog设置)，无法进行回滚，是逻辑的日志，记录行的改变或SQL语句。 redo日志(WAL)
mysql sync_binlog与组提交的关系
敖尔其楞的专栏
05-13 1380
组提交参数：binlog_group_commit_sync_delay Controls how many microseconds the binary log commit waits before synchronizing the binary log file to disk. By default binlog_group_commit_sync_delay is set to 0, meaning that there is no delay. S binlog_group_commit_s
MySQL并发复制系列一：binlog组提交
woqutechteam的博客
04-18 5048
并发复制（Parallel Replication） 系列 一 : Binary Log Group Commit 作者：沃趣科技MySQL数据库工程师  麻鹏飞 MySQL  Binary log在MySQL 5.1版本后推出主要用于主备复制的搭建，我们回顾下MySQL 在开启/关闭 Binary Log功能时是如何工作的 。 MySQL没有开启Binary log的情况下
mysql5.7.2参数解释_mysql5.7新增参数配置解释
weixin_39960920的博客
01-27 247
1：binlog_group_commit_sync_delay全局动态变量，单位微妙，默认0，范围：0～1000000(1秒)。表示binlog提交后等待延迟多少时间再同步到磁盘，默认0，不延迟。设置延迟可以让多个事务在用一时刻提交，提高binlog组提交的并发数和效率，提高slave的吞吐量。2：binlog_group_commit_sync_no_delay_count全局动态变量，单位个...
mysql 5.7报错 binlog_expire_logs_seconds
最新发布
06-07
<think>我们注意到用户的问题是关于MySQL5.7中`binlog_expire_logs_seconds`报错的解决方案。然而，根据引用[2]和引用[3]的内容，我们可以发现：引用[2]显示在MySQL8.0中，`binlog_expire_logs_seconds`是一个可用的参数，而引用[3]则说明在MySQL5.7中设置binlog过期时间使用的是`expire_logs_days`参数。因此，我们需要明确：在MySQL5.7版本中，实际上并没有`binlog_expire_logs_seconds`这个参数。这个参数是在MySQL8.0.1版本中引入的（根据官方文档）。所以，如果在MySQL5.7中尝试设置`binlog_expire_logs_seconds`，会导致错误。用户可能在MySQL5.7的配置文件或命令行中使用了`binlog_expire_logs_seconds`，因此会出现报错。解决方案：1.确认MySQL版本：首先，用户需要确认自己使用的确实是MySQL5.7版本。可以通过以下命令查看版本：```sqlSELECTVERSION();```2.替换参数：如果版本确实是5.7，那么应该使用`expire_logs_days`参数来设置binlog的过期时间，而不是`binlog_expire_logs_seconds`。例如，在配置文件中（如my.cnf）：```ini[mysqld]expire_logs_days=7#设置binlog过期时间为7天```3.动态设置（可选）：如果不想重启MySQL，也可以动态设置：```sqlSETGLOBALexpire_logs_days=7;```4.注意：这个设置需要MySQL有足够的权限（SUPER权限）。5.确保参数生效：设置后，可以检查一下：```sqlSHOWVARIABLESLIKE'expire_logs_days';```6.关于引用[4]中提到的问题：在MySQL5.7中，备份时加全局锁（FLUSHTABLESWITHREADLOCK）并不会影响binlog的自动删除。但是，引用[4]中提到的问题（bug）是在MySQL8.0中出现的，所以对于5.7用户来说，可以不用担心。7.清理现有的binlog：如果之前因为参数设置错误导致binlog没有自动清理，可以手动清理过期的binlog（注意：确保这些binlog已经不再需要，比如没有延迟的从库需要）：```sqlPURGEBINARYLOGSBEFORENOW()-INTERVAL7DAY;--删除7天前的binlog```或者，也可以使用：```sqlPURGEBINARYLOGSTO'binlog.000012';--删除指定binlog文件之前的所有文件```8.监控binlog空间：为了避免磁盘空间被占满，可以设置监控，定期检查binlog文件的大小。总结：在MySQL5.7中，使用`expire_logs_days`参数来设置binlog过期时间，不要使用`binlog_expire_logs_seconds`，因为后者在5.7中不存在。生成的相关问题：1.MySQL5.7中如何正确配置binlog过期时间？2.MySQL5.7中如何手动清理binlog文件？3.MySQL5.7备份时加全局锁会影响binlog删除吗？</think> ### 解决方案：MySQL 5.7 中 `binlog_expire_logs_seconds` 报错处理 根据您提供的引用信息和MySQL 5.7版本特性，该问题的核心原因是：**MySQL 5.7不支持 `binlog_expire_logs_seconds` 参数**（这是MySQL 8.0引入的特性）。以下是逐步解决方案： #### 1️⃣ 确认MySQL版本（关键步骤） ```sql SELECT VERSION(); ``` ➤ 如果返回结果类似 `5.7.x`，请使用以下解决方案（引用[3]） #### 2️⃣ 替代方案（使用 `expire_logs_days`） 在MySQL 5.7中必须使用 `expire_logs_days` 参数控制binlog过期： ```sql -- 动态设置（立即生效，重启失效） SET GLOBAL expire_logs_days = 7; -- 设置7天过期 ``` #### 3️⃣ 持久化配置（编辑 my.cnf） ```ini [mysqld] expire_logs_days = 7 # 日志保留7天 log_bin = mysql-bin # 开启binlog（如果未启用） binlog-format = ROW # 推荐使用ROW格式（引用[3]） server-id = 1 # 必填项（引用[3][5]） ``` #### 4️⃣ 手动清理binlog（立即释放空间） ```sql -- 删除3天前的binlog PURGE BINARY LOGS BEFORE NOW() - INTERVAL 3 DAY; -- 删除指定文件前的所有binlog PURGE BINARY LOGS TO 'mysql-bin.000123'; ``` 📌 需要 `SUPER` 权限（引用[1]） #### 5️⃣ 监控binlog状态 ```sql SHOW BINARY LOGS; -- 查看所有binlog文件 SHOW VARIABLES LIKE 'expire%'; -- 确认参数设置 SELECT @@GLOBAL.expire_logs_days; ``` ### ⚠️ 重要注意事项 1. **版本不兼容**： `binlog_expire_logs_seconds` 仅适用于 **MySQL 8.0+** （引用[2]） 2. **备份工具冲突**： 使用xtrabackup等工具备份时，需确保备份完成后旧binlog能正常清理（引用[4]） 3. **磁盘空间监控**： 定期检查binlog存储位置（默认 `/var/lib/mysql`）的磁盘空间 ### 🔍 技术原理 - MySQL 5.7 通过 `expire_logs_days` 控制binlog过期 - 参数生效需满足： ``` binlog生成时间 < (当前时间 - expire_logs_days) ``` - binlog达到 `max_binlog_size` 时会自动轮转（引用[4]） ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值