[MySQL FAQ]系列 — 5.6版本GTID复制异常处理一例-mysql教程-PHP中文网

首页

数据库

mysql教程

[MySQL FAQ]系列 — 5.6版本GTID复制异常处理一例

WBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWB

Jun 07, 2016 pm 04:42 PM

gtidmysql一处理复制异常系列

昨天处理了一个MySQL 5.6版本下开启GTID模式复制异常案例，MASTER上的任何操作都无法在SLAVE上应用，SLAVE的RELAY LOG里有记录，但SLAVE的BINLOG却找不到蛛丝马迹。由于开启了GTID，所以排查起来也简单，只需要在SLAVE上把RELAY LOG和BINLOG分别解析成文本文件，再直接搜索MASTER的UUID，就能找到SLAVE上是否应用了MASTER复制过来的事务。排查过程中，曾经一度怀疑是因为设置了BINLOG-DO或者IGNORE规则，或者设置了REPLICATION-DO或IGNORE规则，甚至是GTID的严重BUG，但都没发现端倪。直到从 SHOW SLAVE STATUS 里发现下面这个信息：

[yejr@imysql.com]> show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event ... Master_Log_File: mysql-bin.000001 Read_Master_Log_Pos: 2539 Relay_Log_File: mysql-relay-bin.000003 Relay_Log_Pos: 1996 Relay_Master_Log_File: mysql-bin.000001 Slave_IO_Running: Yes Slave_SQL_Running: Yes # 两个线程工作正常 Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: #没设置任何规则 Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 2539 # 无论binlog file 还是 pos，都和MASTER保持一致，也就是说BINLOG的接收和RELAYR LOG的APPLY都很正常，有条不紊工作着 Relay_Log_Space: 2778 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 ... Seconds_Behind_Master: 0 Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: # 没设置忽略某些 server-id 上的BINLOG Master_Server_Id: 123315 Master_UUID: 35cc99c6-0297-11e4-9916-782bcb2c9453 Master_Info_File: /data/db11_3316/master.info SQL_Delay: 0 # 没有设置复制延迟策略 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it Master_Retry_Count: 4294967295 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: 35cc99c6-0297-11e4-9916-782bcb2c9453:1-451 Executed_Gtid_Set: 35cc99c6-0297-11e4-9916-782bcb2c9453:1-2455:792490-4517929 Auto_Position: 1

从上面的日志发现什么了没？尤其是这两行：

Retrieved_Gtid_Set: 35cc99c6-0297-11e4-9916-782bcb2c9453:1-451 Executed_Gtid_Set: 35cc99c6-0297-11e4-9916-782bcb2c9453:1-2455:792490-4517929 Auto_Position: 1

这下有点明白了吧，意思是：

1、SLAVE从MASTER上复制了GTID范围是：1-451； 2、SLAVE上执行GTID的范围分为两段，一段是：1-2455，另一段是：792490-4517929；

尼玛，，不应该是连续的嘛，怎么会这么奇葩⊙﹏⊙b，这可如何是好呀，好捉急~~~ 莫急，且容我们慢慢分析为啥GTID从MASTER到SLAVE之后发生了断点，产生了间隙。

正常滴，在MySQL 5.6启用GTID后，部署REPLICATION复制时，可以设定MASTER_AUTO_POSITION = 1，让 SLAVE 根据 GTID 自动选择适当的事务点进行复制，DBA基本上无需关注和担心主从不一致的问题，还是很让DBA省心的。在启用MASTER_AUTO_POSITION = 1 的情况下，正常是不会发生 GTID 中间有个空隙，产生断点的问题发生。除非是下面这种情况：

1、人工暂停SLAVE进程； 2、MASTER上继续写入数据； 3、MASTER上刷新LOG； 4、MASTER上删除旧BINLOG，只保留最新的BINLOG； 5、SLAVE上启动MASTER，这时候会报错，像下面这样： Last_IO_Errno: 1236 Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'

针对这种问题的处理方法可以这么做：

1、关闭MASTER_AUTO_POSITION，即设置 MASTER_AUTO_POSITION = 0； 2、手工CHANGE BINLOG FILE & POS；

这种情况下，不能再次设置MASTER_AUTO_POSITION = 1，否则还会再次报错。还有一种情况会发生 GTID 间隙断点问题，例如这样：

1、正常配置 REPLICATION 复制，但是设置 MASTER_AUTO_POSITION = 0，也就是人工指定 BINLOG FILE & POS的传统方法； 2、在复制过程中，暂时关闭 SLAVE 进程； 3、手工修改 BINLOG FILE & POS 信息，指向新的 BINLOG FILE & POS 点； 4、启动SLAVE，这时候就会发现 GTID 断点的现象重现了；

在主从高可用模式下，可能主从间会发生切换，然后再次切换回来，这时候也可能发生上述的断点问题。因此我们建议采用双主来部署高可用切换，基本上可以实现任意来回切换，无需手工指定新的 BINLOG FIEE & POS 信息。

还有最后一种情况，就是在 MASTER 上执行了 RESET MASTER，导致 MASTER 上的 BINLOG FILE & POS 全部重置，SLAVE 上读取到的信息自然也就不一致了。

好了，说了那么多，我们最后来说下如何应对处理 GTID 断点的问题。

方法一：手工修改 BINLOG FILE & POS

1、关闭SLAVE； 2、手工CHANGE BINLOG FILE & POS，指向MASTER上最新产生的BINLOG FILE & POS，并且设置 MASTER_AUTO_POSITION = 0； 3、启动SLAVE;

方法二：手工修改 GTID_PURGED 值

1、关闭 SLAVE； 2、在 SLAVE 上执行 RESET MASTER，重设 SLAVE 上的 BINLOG FILE & POS； 3、在 SLAVE 上执行 SET @@GLOBAL.GTID_PURGED = '35cc99c6-0297-11e4-9916-782bcb2c9453:1-2455'; 4、启动 SLAVE；

这种做法比较费解一点，意思是，我们告诉SLAVE要主动抛弃掉 MASTER 上传输过来的某些区间的事务。在这个例子中，我们抛弃了 1-2455 这个区间，也就是在 GTID 从 2466 开始，又会继续应用 RELAY LOG 了，相比我们最开始的那个信息：

Retrieved_Gtid_Set: 35cc99c6-0297-11e4-9916-782bcb2c9453:1-451 Executed_Gtid_Set: 35cc99c6-0297-11e4-9916-782bcb2c9453:1-2455:792490-4517929

我们强制 SLAVE 只忽略 1-2455 这个区间，从 2466 开始继续复制，消除了本来也会被忽略的区间：792490-4517929，确保新产生的事务都会被继续应用。这个做法可以参考MySQL手册：。

声明

本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系admin@php.cn

MySQL与Sqlite有何不同？Apr 24, 2025 am 12:12 AM

MySQL和SQLite的主要区别在于设计理念和使用场景：1.MySQL适用于大型应用和企业级解决方案，支持高性能和高并发；2.SQLite适合移动应用和桌面软件，轻量级且易于嵌入。

MySQL中的索引是什么？它们如何提高性能？Apr 24, 2025 am 12:09 AM

MySQL中的索引是数据库表中一列或多列的有序结构，用于加速数据检索。1）索引通过减少扫描数据量提升查询速度。2）B-Tree索引利用平衡树结构，适合范围查询和排序。3）创建索引使用CREATEINDEX语句，如CREATEINDEXidx_customer_idONorders(customer_id)。4）复合索引可优化多列查询，如CREATEINDEXidx_customer_orderONorders(customer_id,order_date)。5）使用EXPLAIN分析查询计划，避

说明如何使用MySQL中的交易来确保数据一致性。Apr 24, 2025 am 12:09 AM

在MySQL中使用事务可以确保数据一致性。1)通过STARTTRANSACTION开始事务，执行SQL操作后用COMMIT提交或ROLLBACK回滚。2)使用SAVEPOINT可以设置保存点，允许部分回滚。3)性能优化建议包括缩短事务时间、避免大规模查询和合理使用隔离级别。

在哪些情况下，您可以选择PostgreSQL而不是MySQL？Apr 24, 2025 am 12:07 AM

选择PostgreSQL而非MySQL的场景包括：1)需要复杂查询和高级SQL功能，2)要求严格的数据完整性和ACID遵从性，3)需要高级空间功能，4)处理大数据集时需要高性能。PostgreSQL在这些方面表现出色，适合需要复杂数据处理和高数据完整性的项目。

如何保护MySQL数据库？Apr 24, 2025 am 12:04 AM

MySQL数据库的安全可以通过以下措施实现：1.用户权限管理：通过CREATEUSER和GRANT命令严格控制访问权限。2.加密传输：配置SSL/TLS确保数据传输安全。3.数据库备份和恢复：使用mysqldump或mysqlpump定期备份数据。4.高级安全策略：使用防火墙限制访问，并启用审计日志记录操作。5.性能优化与最佳实践：通过索引和查询优化以及定期维护兼顾安全和性能。

您可以使用哪些工具来监视MySQL性能？Apr 23, 2025 am 12:21 AM

如何有效监控MySQL性能？使用mysqladmin、SHOWGLOBALSTATUS、PerconaMonitoringandManagement(PMM)和MySQLEnterpriseMonitor等工具。1.使用mysqladmin查看连接数。2.用SHOWGLOBALSTATUS查看查询数。3.PMM提供详细性能数据和图形化界面。4.MySQLEnterpriseMonitor提供丰富的监控功能和报警机制。

MySQL与SQL Server有何不同？Apr 23, 2025 am 12:20 AM

MySQL和SQLServer的区别在于：1)MySQL是开源的，适用于Web和嵌入式系统，2)SQLServer是微软的商业产品，适用于企业级应用。两者在存储引擎、性能优化和应用场景上有显着差异，选择时需考虑项目规模和未来扩展性。

在哪些情况下，您可以选择SQL Server而不是MySQL？Apr 23, 2025 am 12:20 AM

在需要高可用性、高级安全性和良好集成性的企业级应用场景下，应选择SQLServer而不是MySQL。1)SQLServer提供企业级功能，如高可用性和高级安全性。2)它与微软生态系统如VisualStudio和PowerBI紧密集成。3)SQLServer在性能优化方面表现出色，支持内存优化表和列存储索引。

See all articles