MySQL5.7复制配置不规范修改导致的坑(一)-创新互联
沃趣科技 罗小波
1、复现与简单分析
2、重新复现、详细分析与验证
2.1. 重新复现与详细分析
2.1.1. stop slave
2.1.2. change master to master_auto_position=0
2.1.3. start slave
2.2. 解决方法验证
3、总结
今天咱们同事说碰到一个古怪的问题,说MySQL 5.7.18上,主从复制结构中,从库在使用change master语句切换master_auto_position=1为0时,SQL线程报错了([ERROR] Slave SQL for channel '': Error '@@SESSION.GTID_NEXT cannot be set to ANONYMOUS when @@GLOBAL.GTID_MODE = ON.' on query. Default database: 'sbtest'. Query: 'BEGIN', Error_code: 1782),然后,出于尝试修复,又改成了1,重新启动复制就恢复正常了,然后再改成0重新启动复制,这个时候发生数据丢失了,再反复切换几次之后,MySQL crash了。。,当时我听到这个问题的第一反应就是:一脸懵逼(因为1782错误通常是发生复制架构启用GTID复制之后,从库IO线程读取到主库的ANONYMOUS 事务时报错)。。然后,发了一阵呆之后,想到了一些可能导致这个问题的原因,下文我们通过"复现与简单分析"、"重新复现、详细分析与验证"、"总结"三个步骤来对这个问题的前因后果进行一次透析,大家请跟随我往下看。
先列出硬件配置、操作系统和数据库环境信息
sysbench版本:sysbench-0.5-3.el6.x86_64
* 使用sysbench造数8张500W数据的表
percona-toolkit版本:percona-toolkit-3.0.3-1.el7.x86_64
percona-xtrabackup版本:percona-xtrabackup-24-2.4.4-1.el7.x86_64
数据库版本:MySQL 5.7.18
数据库配置关键参数:
主库使用如下sysbench语句加压
1、复现与简单分析
2、重新复现、详细分析与验证
2.1. 重新复现与详细分析
2.1.1. stop slave
2.1.2. change master to master_auto_position=0
2.1.3. start slave
2.2. 解决方法验证
3、总结
今天咱们同事说碰到一个古怪的问题,说MySQL 5.7.18上,主从复制结构中,从库在使用change master语句切换master_auto_position=1为0时,SQL线程报错了([ERROR] Slave SQL for channel '': Error '@@SESSION.GTID_NEXT cannot be set to ANONYMOUS when @@GLOBAL.GTID_MODE = ON.' on query. Default database: 'sbtest'. Query: 'BEGIN', Error_code: 1782),然后,出于尝试修复,又改成了1,重新启动复制就恢复正常了,然后再改成0重新启动复制,这个时候发生数据丢失了,再反复切换几次之后,MySQL crash了。。,当时我听到这个问题的第一反应就是:一脸懵逼(因为1782错误通常是发生复制架构启用GTID复制之后,从库IO线程读取到主库的ANONYMOUS 事务时报错)。。然后,发了一阵呆之后,想到了一些可能导致这个问题的原因,下文我们通过"复现与简单分析"、"重新复现、详细分析与验证"、"总结"三个步骤来对这个问题的前因后果进行一次透析,大家请跟随我往下看。
先列出硬件配置、操作系统和数据库环境信息
环境信息
创新互联主要从事成都网站设计、网站建设、网页设计、企业做网站、公司建网站等业务。立足成都服务西峰,10年网站建设经验,价格优惠、服务专业,欢迎来电咨询建站服务:18982081108操作系统:CentOS Linux release 7.2.1511 (Core)sysbench版本:sysbench-0.5-3.el6.x86_64
* 使用sysbench造数8张500W数据的表
percona-toolkit版本:percona-toolkit-3.0.3-1.el7.x86_64
percona-xtrabackup版本:percona-xtrabackup-24-2.4.4-1.el7.x86_64
数据库版本:MySQL 5.7.18
数据库配置关键参数:
- * 主库:双一,log_slave_updates,log-bin,binlog_rows_query_log_events=ON,server-id=330614,slave_parallel_type=LOGICAL_CLOCK,enforce_gtid_consistency=ON,gtid_mode=on,innodb_buffer_pool_size=2G
- * 从库:双一,双TABLE,log_slave_updates,log-bin,binlog_rows_query_log_events=ON,server-id=330615,slave_parallel_type=LOGICAL_CLOCK,enforce_gtid_consistency=ON,gtid_mode=on,innodb_buffer_pool_size=2G,slave_parallel_workers=4
- * CPU:4 vcpus
- * 内存:8G
- * 磁盘:50G SSD
- * 网卡:Speed: 100Mb/s
- * 主库:10.10.20.14
- * 从库:10.10.20.15
1、复现与简单分析
首先,我们使用主库中造好数的备份,与从库搭建主从复制结构(sysbench造数和搭建主备复制步骤省略),从库初始搭建时使用master_auto_position=1启动复制主库使用如下sysbench语句加压
-
- sysbench --test=oltp --db-driver=mysql --mysql-table-engine=innodb --mysql-socket=/home/mysql/data/mysqldata1/sock/mysql.sock --mysql-port=3306 --mysql-db=sbtest \
- --mysql-user='qbench' --mysql-password='qbench' --test=/usr/share/doc/sysbench/tests/db/update_non_index.lua --oltp-table-size=5000000 --oltp-tables-count=4 --num-threads=8 --max-time=1800 \
- --max-requests=0 --report-interval=1 run
网站名称:MySQL5.7复制配置不规范修改导致的坑(一)-创新互联
分享URL:http://scyanting.com/article/jheeh.html - sysbench --test=oltp --db-driver=mysql --mysql-table-engine=innodb --mysql-socket=/home/mysql/data/mysqldata1/sock/mysql.sock --mysql-port=3306 --mysql-db=sbtest \