已开启GTID的情况下的binlog复制切换到GTID复制可能会遇到的问题
今天测试在已开启GTID的情况下的binlog复制切换到GTID复制,遇到个问题,记录下来。
场景是:主库和从库分别开启GTID模式,主库创建一个库和一张表并写入数据;主库mysqldump使用了--set-gtid-purged=OFF即不记录GTID事务编号做完备,导入到从库
从库show slave status\G看到的状态应该是这样
650) this.width=650;" src="https://www.itdaan.com/go/aHR0cHM6Ly9oemtldW5nLmNvbS93cC1jb250ZW50L3VwbG9hZHMvMjAxNi8xMi9hMWMyOWZiYTZiM2M3MDE5NTQ2Mzc5NDAyMmMyYmQ5Yy5wbmc=" style="margin:0px;padding:0px;border:0px;width:auto;height:auto;" alt="a1c29fba6b3c70195463794022c2bd9c.png" referrerpolicy="no-referrer">
而主库上show master status;看到的结果是
650) this.width=650;" src="https://www.itdaan.com/go/aHR0cHM6Ly9oemtldW5nLmNvbS93cC1jb250ZW50L3VwbG9hZHMvMjAxNi8xMi8yMmJkNmE1N2RkYWMwMDQ0YzFmNGZkNGJlNWU4MjFhOS5wbmc=" style="margin:0px;padding:0px;border:0px;width:auto;height:auto;" alt="22bd6a57ddac0044c1f4fd4be5e821a9.png" referrerpolicy="no-referrer">
此时如果直接切换到GTID复制,你会发现复制分报错
650) this.width=650;" src="https://www.itdaan.com/go/aHR0cHM6Ly9oemtldW5nLmNvbS93cC1jb250ZW50L3VwbG9hZHMvMjAxNi8xMi9jZDU1MjVhNDViZThkMzRjZTY3YmY1M2QyN2ZjOWQ5NS5wbmc=" style="margin:0px;padding:0px;border:0px;width:auto;height:auto;" alt="cd5525a45be8d34ce67bf53d27fc9d95.png" referrerpolicy="no-referrer">650) this.width=650;" src="https://www.itdaan.com/go/aHR0cHM6Ly9oemtldW5nLmNvbS93cC1jb250ZW50L3VwbG9hZHMvMjAxNi8xMi85OTdiMTA3OTQ0MDg3NWEzYWNmNjFhMDdmZTJkMzY2MS5wbmc=" style="margin:0px;padding:0px;border:0px;width:auto;height:auto;" alt="997b1079440875a3acf61a07fe2d3661.png" referrerpolicy="no-referrer">
我们知道
Retrieved_Gtid_Set是指定从库接收到的GTID集合
Executed_Gtid_Set是已执行的GTID集合
对比可以发现
切换GTID复制以后,主库会把从库没有的GTID发送给从库,而从库接收到这些GTID后,按顺序执行,当执行到第一个GTID时就发生报错,原因是从库已经执行过这个GTID的SQL语句(创建表);这个问题的解决办法是从库的master信息并跳过已经执行的GTID
root@localhost [(none)]>reset master;
Query OK, 0 rows affected (0.13 sec)
root@localhost [(none)]>set global gtid_purged='d26fd29a-b7d4-11e6-b38e-00155d7b0100:1-14';
Query OK, 0 rows affected (0.00 sec)
root@localhost [(none)]>start slave;
最后主从复制恢复,同时可以看到复制状态
650) this.width=650;" src="https://www.itdaan.com/go/aHR0cHM6Ly9oemtldW5nLmNvbS93cC1jb250ZW50L3VwbG9hZHMvMjAxNi8xMi8zNzYwYjc2YzA1MzYzZmViZjg2ZmExYTIzYjQ1ZWVhMC5wbmc=" style="margin:0px;padding:0px;border:0px;width:auto;height:auto;" alt="3760b76c05363febf86fa1a23b45eea0.png" referrerpolicy="no-referrer">
总结一下,在已开启GTID的情况下的binlog复制切换到GTID复制的步骤:
主库执行show master status并记录Executed_Gtid_Set的开始位置
650) this.width=650;" src="https://www.itdaan.com/go/aHR0cHM6Ly9oemtldW5nLmNvbS93cC1jb250ZW50L3VwbG9hZHMvMjAxNi8xMi9mNGFhYjU4YWViMDA0OTcxM2Y2YmMzODUzMWViOGFmOC5wbmc=" style="margin:0px;padding:0px;border:0px;width:auto;height:auto;" alt="f4aab58aeb0049713f6bc38531eb8af8.png" referrerpolicy="no-referrer">
从上图可以看出我的环境的Executed_Gtid_Set集合从1开始
从库导入数执行change master to语句,设置成binlog复制模式,看下复制是否成功,如果成功,把复制停掉,执行reset master后再执行show slave status\G, 可以看到当前已接收到的GTID集合,记录下集群的结束位置是15
650) this.width=650;" src="https://www.itdaan.com/go/aHR0cHM6Ly9oemtldW5nLmNvbS93cC1jb250ZW50L3VwbG9hZHMvMjAxNi8xMi9kZWQ5MTAzNmI4YjY4NGQ4MGY5MmIxNTg4MjYyOTBkYS5wbmc=" style="margin:0px;padding:0px;border:0px;width:auto;height:auto;" alt="ded91036b8b684d80f92b158826290da.png" referrerpolicy="no-referrer">
从库执行set global gtid_purged='d26fd29a-b7d4-11e6-b38e-00155d7b0100:1-15';
再执行show slave status\G可以看到
650) this.width=650;" src="https://www.itdaan.com/go/aHR0cHM6Ly9oemtldW5nLmNvbS93cC1jb250ZW50L3VwbG9hZHMvMjAxNi8xMi82MTRjMDg0NzU2MzBmYmExZGU0ZmFjNDVmNTMyNWY5My5wbmc=" style="margin:0px;padding:0px;border:0px;width:auto;height:auto;" alt="614c08475630fba1de4fac45f5325f93.png" referrerpolicy="no-referrer">
可以看出主从库Executed_Gtid_Set是一样的
问题?
如果主库在初始化完成后马上做完备,这种情况下会有这个问题吗?
更多相关文章
- 非GTID模式MySQL主从同步配置
- mysql主从同步报slave_sql_running:no的解决方案
- linux6.4搭建mysql主从复制
- MySQL高性能主从架构的复制原理及配置详解
- Amoeba实现Mysql主从复制读写分离
- MySQL 主从同步Out of Memory 错误分析
- 使用 Xtrabackup 在线对MySQL做主从复制【转】
- mysql主从同步(4)-Slave延迟状态监控
- mysql主从复制配置操作以及主主配置宕机切换演练