MySQL主从切换GTID不一致问题分析与解决方案

最新推荐文章于 2025-09-28 16:56:28 发布
原创 最新推荐文章于 2025-09-28 16:56:28 发布 · 966 阅读 · 14 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#mysql #数据库

目录标题

MySQL主从切换GTID不一致问题分析与解决方案

一、问题背景与现象

在MySQL数据库主从复制架构中，GTID（全局事务标识符）模式提供了一种更可靠的复制方式，能够简化主从切换流程。然而，在实际操作中，特别是在高可用切换场景下，可能会遇到新从库的GTID集合大于新主库的情况，导致主从连接建立失败。具体来说，当主从切换发生时，可能出现以下现象：

  1. 主从复制失败：新从库尝试连接新主库时，报错提示GTID不一致，如"Slave has more GTIDs than the master has"。
  2. GTID集合差异：新从库的Executed_Gtid_Set包含新主库所没有的GTID事务。
  3. 数据不一致：新从库上存在业务上认为失败的数据，而新主库却没有这些数据。

这种情况通常发生在主从切换时间点不巧的情况下，特别是当从库已经执行完前一个GTID事务，但还未完成新传输的GTID事务时，主从切换导致新从库保留了未被主库确认的事务。

二、GTID主从复制基础原理

2.1 GTID工作原理概述

GTID是MySQL 5.6版本引入的新特性，它为每个事务生成一个唯一的标识符，格式为uuid:transaction_id。在GTID模式下，主从复制不再需要传统的MASTER_LOG_FILE和MASTER_LOG_POS参数，而是通过GTID集合来追踪和同步事务。

GTID的核心优势在于：

  1. 事务唯一性：确保每个事务在整个复制拓扑中只执行一次。
  2. 自动定位：MASTER_AUTO_POSITION=1参数使从库能够自动找到正确的同步位置。
  3. 简化故障转移：主从切换时无需手动指定二进制日志位置。

2.2 两阶段提交与半同步复制机制

MySQL的复制过程涉及两阶段提交和半同步复制机制，这些机制对于理解GTID不一致问题至关重要：

  1. 两阶段提交：

    • 主库执行事务并写入二进制日志。
    • 主库将二进制日志事件发送给从库。
    • 从库接收并写入中继日志。
    • 从库执行中继日志中的事务。
    • 从库向主库发送执行确认ACK。
    • 主库收到ACK后，事务才算真正提交完成。

  2. 增强半同步复制：

    • rpl_semi_sync_master_wait_point参数：控制主库在何时等待从库的确认。5.7版本默认值为AFTER_SYNC，表示主库在将事务写入二进制日志并同步到磁盘后等待从库确认。
    • sync_binlog参数：控制二进制日志的同步频率，设置为1时确保每个事务都同步到磁盘。
    • sync_relay_log参数：控制中继日志的同步频率，设置为1时确保每个事务都同步到磁盘。

三、各版本GTID主从切换问题分析

3.1 MySQL 5.6版本问题分析

3.1.1 5.6版本GTID机制特点

MySQL 5.6版本的GTID实现存在一些局限性，这是导致主从切换问题的重要原因：

  1. 强制开启二进制日志：在MySQL 5.6中，启用GTID必须同时开启二进制日志（log_bin=ON），这是因为GTID信息保存在二进制日志中。
  2. 内存中的GTID集合：gtid_executed变量是一个内存中的GTID集合，重启后会丢失。
  3. mysql.gtid_executed表缺失：5.6版本没有mysql.gtid_executed表，GTID信息仅保存在二进制日志中。
  4. 半同步复制默认模式：5.6版本的半同步复制默认使用AFTER_COMMIT模式，即主库在事务提交后等待从库确认。
3.1.2 5.6版本主从切换问题原因

在5.6版本中，主从切换时出现GTID不一致的核心原因是：

  1. 事务确认机制问题：

    • 主库在事务提交后（AFTER_COMMIT模式）等待从库确认。
    • 如果主库在等待确认过程中发生故障，此时事务已经提交，但可能尚未同步到所有从库。
    • 切换到新主库后，新主库可能没有包含这些未同步的事务，而某些从库可能已经接收到这些事务。

  2. GTID信息丢失风险：

    • 由于5.6版本没有mysql.gtid_executed表，GTID信息完全依赖二进制日志。
    • 如果主库在写入二进制日志但未同步到磁盘时发生故障，可能导致GTID信息丢失。

  3. 手动操作影响：

    • 手动执行PURGE BINARY LOGS命令可能清除从库需要的GTID日志。
    • 从库可能曾经连接过其他主库，导致gtid_executed集合包含不相关的GTID。

3.2 MySQL 5.7版本问题分析

3.2.1 5.7版本GTID机制改进

MySQL 5.7版本对GTID机制进行了重要改进，但仍存在一些问题：

  1. mysql.gtid_executed表引入：5.7版本引入了mysql.gtid_executed表，用于持久化存储GTID信息，解决了5.6版本中GTID信息仅保存在内存中的问题。
  2. 二进制日志非强制要求：5.7版本中，即使不开启二进制日志也可以使用GTID，但为了高可用性通常仍建议开启。
  3. 增强半同步复制：5.7版本默认使用AFTER_SYNC模式的半同步复制，主库在二进制日志同步到磁盘后等待从库确认。
  4. 并行复制改进：5.7版本改进了并行复制机制，提高了复制性能，但也增加了GTID集合不连续的可能性。
3.2.2 5.7版本主从切换问题原因

尽管5.7版本有诸多改进，但主从切换时仍可能出现GTID不一致问题，主要原因包括：

  1. GTID持久化机制缺陷：

    • 虽然5.7版本引入了mysql.gtid_executed表，但该表仅在二进制日志切换时更新。
    • 如果主库在二进制日志切换前发生崩溃，可能导致最后一个二进制日志中的GTID未写入mysql.gtid_executed表。
    • 如果在崩溃恢复过程中再次发生崩溃，可能导致GTID信息丢失。

  2. 主从切换时的时间窗口：

    • 即使使用AFTER_SYNC模式的半同步复制，仍存在一个时间窗口：主库已经将二进制日志同步到磁盘，但从库尚未接收并执行这些事务。
    • 如果在此时进行主从切换，新主库可能没有包含这些事务，而某些从库可能已经接收到这些事务。

  3. 并行复制导致的不连续GTID：

    • 5.7版本的并行复制可能导致gtid_executed集合中出现空洞。
    • 这种空洞可能导致主从切换后复制无法正常进行。

3.3 MySQL 8.0版本问题分析

3.3.1 8.0版本GTID机制改进

MySQL 8.0版本进一步改进了GTID机制，降低了主从切换时出现问题的可能性：

  1. GTID持久化优化：8.0版本改进了GTID持久化机制，即使在崩溃恢复过程中也能更可靠地保存GTID信息。
  2. gtid_executed内存变量改进：8.0版本改进了内存中gtid_executed变量的管理，减少了重启后GTID信息丢失的风险。
  3. 增强的半同步复制：8.0版本进一步优化了半同步复制机制，提高了数据一致性保障。
  4. 自动GTID清理：8.0版本引入了自动清理不再需要的GTID的机制，减少了GTID集合膨胀的问题。
3.3.2 8.0版本主从切换问题原因

尽管8.0版本有诸多改进，但主从切换时仍可能出现GTID不一致问题，主要原因包括：

  1. 主从切换工具使用不当：

    • 如果使用不兼容8.0版本特性的主从切换工具，可能导致GTID不一致。
    • 某些第三方工具可能没有正确处理8.0版本的新特性，如自动GTID清理。

  2. 多主复制拓扑复杂性：

    • 在多主复制拓扑中，GTID集合的管理更为复杂，主从切换时更容易出现不一致。
    • gtid_executed集合可能包含来自多个主库的GTID，增加了冲突风险。

  3. 手动操作的影响：

    • 手动执行PURGE BINARY LOGS或RESET MASTER等命令可能导致GTID信息丢失。
    • 从库可能曾经连接过其他主库，导致gtid_executed集合包含不相关的GTID。

四、主从切换GTID不一致问题的解决方案

4.1 MySQL 5.6版本解决方案

4.1.1 配置优化建议

针对5.6版本的主从切换问题，建议采取以下配置优化措施：

  1. 半同步复制参数优化：

    • 设置rpl_semi_sync_master_wait_point=AFTER_COMMIT（5.6版本默认值，但建议显式设置）。
    • 设置sync_binlog=1，确保二进制日志每个事务都同步到磁盘。
    • 设置sync_relay_log=1，确保中继日志每个事务都同步到磁盘。

  2. GTID相关参数优化：

    • 确保gtid_mode=ON和enforce_gtid_consistency=ON参数已启用。
    • 开启二进制日志（log_bin=ON）和log_slave_updates=ON参数。

  3. 半同步复制超时设置：

    • 设置适当的rpl_semi_sync_master_timeout值，平衡数据安全性和性能。
    • 考虑设置rpl_semi_sync_master_wait_no_slave=OFF，当没有从库连接时不等待确认。
4.1.2 主从切换最佳实践

在5.6版本中，为避免主从切换时出现GTID不一致问题，建议遵循以下最佳实践：

  1. 切换前准备工作：

    • 确保所有从库与主库的GTID一致，可以通过比较show master status和show slave status的Executed_Gtid_Set值。
    • 停止主库的写入操作，确保所有事务都已同步到从库。
    • 执行FLUSH TABLES WITH READ LOCK锁定主库，防止新的写入。

  2. 切换过程：

    • 选择拥有最新GTID的从库作为新主库。
    • 使用CHANGE MASTER TO命令重新配置其他从库指向新主库。
    • 确保新主库的二进制日志包含所有必要的GTID事务。

  3. 切换后验证：

    • 检查所有从库的复制状态，确保Slave_IO_Running和Slave_SQL_Running均为Yes。
    • 比较所有节点的Executed_Gtid_Set，确保它们一致。
    • 逐步释放主库的读锁，恢复写入操作。
4.1.3 GTID不一致问题修复方法

如果在5.6版本中已经出现了GTID不一致问题，可以采取以下修复方法：

  1. 基本修复步骤：

    • 在从库上执行STOP SLAVE停止复制。
    • 使用RESET SLAVE ALL命令清除从库的复制信息。
    • 重新配置从库指向新主库，使用CHANGE MASTER TO MASTER_AUTO_POSITION=1。
    • 执行START SLAVE重新启动复制。

  2. 高级修复方法：

    • 如果从库的gtid_executed集合包含主库没有的GTID，可以使用SET GLOBAL gtid_purged命令在从库上设置已清除的GTID集合。
    • 例如：SET GLOBAL gtid_purged='0825e12e-6e3d-11ea-9c4b-9c7da30d2c06:1-96109007'。
    • 注意：使用SET GLOBAL gtid_purged后需要重启从库才能生效。

  3. 跳过特定GTID：

    • 如果某个特定的GTID导致复制失败，可以使用以下方法跳过：
      STOP SLAVE;
SET GTID_NEXT='< problematic GTID >';
BEGIN WORK;
COMMIT WORK;
SET GTID_NEXT=AUTOMATIC;
START SLAVE;
    • 这种方法会在从库上创建一个空事务，标记该GTID已执行。

4.2 MySQL 5.7版本解决方案

4.2.1 配置优化建议

针对5.7版本的主从切换问题，建议采取以下配置优化措施：

  1. 半同步复制参数优化：

    • 设置rpl_semi_sync_master_wait_point=AFTER_SYNC，这是5.7版本的默认值，但建议显式设置。
    • 设置sync_binlog=1，确保二进制日志每个事务都同步到磁盘。
    • 设置sync_relay_log=1，确保中继日志每个事务都同步到磁盘。
    • 考虑设置sync_relay_log_info=1，确保中继日志信息每个事务都同步到磁盘。

  2. GTID相关参数优化：

    • 确保gtid_mode=ON和enforce_gtid_consistency=ON参数已启用。
    • 虽然5.7版本允许不开启二进制日志，但为了高可用性建议开启log_bin=ON和log_slave_updates=ON参数。

  3. 并行复制参数优化：

    • 设置slave_parallel_workers为适当的值，提高复制性能但避免过度并行导致的问题。
    • 设置slave_parallel_type=LOGICAL_CLOCK，基于逻辑时钟的并行复制模式。
4.2.2 主从切换最佳实践

在5.7版本中，为避免主从切换时出现GTID不一致问题，建议遵循以下最佳实践：

  1. 切换前准备工作：

    • 确保所有从库与主库的GTID一致，可以通过比较show master status和show slave status的Executed_Gtid_Set值。
    • 使用FLUSH TABLES WITH READ LOCK锁定主库，防止新的写入。
    • 等待所有从库的Seconds_Behind_Master为0，确保所有事务都已同步。

  2. 切换过程：

    • 选择拥有最新GTID的从库作为新主库。
    • 使用STOP SLAVE停止所有从库的复制线程。
    • 在新主库上执行RESET MASTER，清除旧的二进制日志信息。
    • 重新配置其他从库指向新主库，使用CHANGE MASTER TO MASTER_AUTO_POSITION=1。
    • 启动所有从库的复制线程，使用START SLAVE。

  3. 切换后验证：

    • 检查所有从库的复制状态，确保Slave_IO_Running和Slave_SQL_Running均为Yes。
    • 比较所有节点的Executed_Gtid_Set，确保它们一致。
    • 逐步释放主库的读锁，恢复写入操作。
4.2.3 GTID不一致问题修复方法

如果在5.7版本中已经出现了GTID不一致问题，可以采取以下修复方法：

  1. 利用mysql.gtid_executed表：

    • 5.7版本的mysql.gtid_executed表记录了所有已执行的GTID，可以通过查询该表获取正确的GTID集合。
    • 在从库上执行以下命令可以重置GTID信息：
      STOP SLAVE;
RESET SLAVE ALL;
RESET MASTER;
    • 重新配置从库指向新主库，使用CHANGE MASTER TO MASTER_AUTO_POSITION=1。

  2. 处理连续崩溃导致的GTID丢失：

    • 如果主库在短时间内连续崩溃导致GTID丢失，可以尝试以下修复步骤：
      1. 停止主库和所有从库的复制。
      2. 找到拥有最全GTID集合的从库作为新主库。
      3. 使用RESET MASTER命令在新主库上清除旧的GTID信息。
      4. 重新配置其他从库指向新主库。
      5. 启动所有从库的复制线程。

  3. 处理并行复制导致的GTID空洞：

    • 如果gtid_executed集合中存在空洞，可以使用以下方法修复：
      STOP SLAVE;
SET GLOBAL gtid_purged=@@GLOBAL.gtid_executed;
RESET MASTER;
CHANGE MASTER TO MASTER_AUTO_POSITION=1;
START SLAVE;
    • 这种方法会将从库的GTID集合重置为当前执行的集合，并清除空洞。

4.3 MySQL 8.0版本解决方案

4.3.1 配置优化建议

针对8.0版本的主从切换问题，建议采取以下配置优化措施：

  1. 半同步复制参数优化：

    • 设置rpl_semi_sync_master_wait_point=AFTER_SYNC，这是8.0版本的默认值，但建议显式设置。
    • 设置sync_binlog=1，确保二进制日志每个事务都同步到磁盘。
    • 设置sync_relay_log=1，确保中继日志每个事务都同步到磁盘。

  2. GTID相关参数优化：

    • 确保gtid_mode=ON和enforce_gtid_consistency=ON参数已启用。
    • 设置gtid_purged_auto_expire=1，自动清理不再需要的GTID记录。
    • 设置gtid_executed_compression_period=1000，控制mysql.gtid_executed表的压缩频率。

  3. 多主复制拓扑优化：

    • 如果使用多主复制拓扑，设置enforce_gtid_consistency=ON和transaction_write_set_extraction=XXHASH64。
    • 考虑使用binlog_transaction_dependency_tracking=WRITESET来提高并行复制性能。
4.3.2 主从切换最佳实践

在8.0版本中，为避免主从切换时出现GTID不一致问题，建议遵循以下最佳实践：

  1. 切换前准备工作：

    • 使用SHOW MASTER STATUS和SHOW SLAVE STATUS命令检查所有节点的GTID集合是否一致。
    • 使用SHOW GLOBAL VARIABLES LIKE 'gtid_executed'命令验证每个节点的GTID执行情况。
    • 考虑使用mysqlcheck工具检查所有节点的数据一致性。

  2. 切换过程：

    • 选择拥有最新GTID集合的从库作为新主库。
    • 使用RESET MASTER命令在新主库上清除旧的二进制日志信息。
    • 使用CHANGE MASTER TO MASTER_AUTO_POSITION=1命令重新配置其他从库指向新主库。
    • 启动所有从库的复制线程，使用START SLAVE。

  3. 切换后验证：

    • 使用SHOW SLAVE STATUS命令检查所有从库的复制状态，确保Slave_IO_Running和Slave_SQL_Running均为Yes。
    • 比较所有节点的Executed_Gtid_Set，确保它们一致。
    • 使用mysqlbinlog工具检查二进制日志和中继日志的内容是否一致。
    • 考虑使用pt-table-checksum等工具验证数据一致性。
4.3.3 GTID不一致问题修复方法

如果在8.0版本中已经出现了GTID不一致问题，可以采取以下修复方法：

  1. 利用自动GTID清理功能：

    • 8.0版本引入了自动清理不再需要的GTID的功能，可以通过以下命令手动触发：
      PURGE BINARY LOGS BEFORE NOW();
    • 这会自动清理不再需要的GTID记录，有助于解决GTID不一致问题。

  2. 使用gtid_purged参数：

    • 如果从库的gtid_executed集合包含主库没有的GTID，可以使用以下方法修复：
      STOP SLAVE;
SET GLOBAL gtid_purged='< GTID set to purge >';
RESET MASTER;
CHANGE MASTER TO MASTER_AUTO_POSITION=1;
START SLAVE;
    • 其中< GTID set to purge >是需要清除的GTID集合。

  3. 处理多主复制拓扑中的GTID冲突：

    • 在多主复制拓扑中，GTID冲突可能更为复杂，可以尝试以下修复步骤：
      1. 停止所有主库的写入操作。
      2. 确定哪个主库拥有最新的GTID集合。
      3. 使用RESET MASTER命令在其他主库上清除旧的GTID信息。
      4. 重新配置所有从库指向新的主库。
      5. 恢复主库的写入操作。

五、不同版本解决方案对比与建议

5.1 各版本解决方案对比

下表总结了不同MySQL版本主从切换GTID不一致问题的解决方案对比：

解决方案类型MySQL 5.6版本MySQL 5.7版本MySQL 8.0版本
半同步复制模式AFTER_COMMIT（默认）AFTER_SYNC（默认）AFTER_SYNC（默认）
GTID持久化机制仅二进制日志mysql.gtid_executed表改进的mysql.gtid_executed表
GTID重置命令RESET SLAVE ALLRESET SLAVE ALL + RESET MASTERRESET SLAVE ALL + RESET MASTER
处理GTID不一致SET GLOBAL gtid_purged + 重新配置利用mysql.gtid_executed表重置自动GTID清理 + gtid_purged
并行复制支持有限改进的并行复制进一步优化的并行复制
连续崩溃处理易丢失GTID可能丢失GTID更可靠的恢复机制

5.2 不同场景下的版本选择建议

根据不同的应用场景，建议选择以下MySQL版本和配置：

  1. 高可用性要求不高的场景：

    • 可以选择5.6版本，但需要严格遵循最佳实践，确保主从切换前数据完全同步。
    • 强烈建议启用半同步复制，并设置sync_binlog=1和sync_relay_log=1。

  2. 中等可用性要求的场景：

    • 推荐使用5.7版本，利用其AFTER_SYNC模式的半同步复制和mysql.gtid_executed表。
    • 配置rpl_semi_sync_master_wait_point=AFTER_SYNC，并启用增强半同步复制。

  3. 高可用性要求的场景：

    • 推荐使用8.0版本，其改进的GTID持久化机制和更可靠的恢复能力提供了更高的数据一致性保障。
    • 结合Group Replication等高级复制功能，可以实现更可靠的高可用性。

  4. 大规模、高并发场景：

    • 推荐使用8.0版本，其优化的并行复制机制和更高效的二进制日志处理能够提供更好的性能。
    • 考虑使用多主复制拓扑，但需要谨慎管理GTID集合以避免冲突。

5.3 长期维护与监控建议

为了长期维护MySQL主从复制的稳定性，避免GTID不一致问题，建议采取以下措施：

  1. 定期监控与检查：

    • 定期检查所有节点的GTID集合是否一致，可以通过SHOW MASTER STATUS和SHOW SLAVE STATUS命令。
    • 使用pt-heartbeat等工具监控主从延迟，及时发现潜在问题。
    • 定期备份二进制日志和中继日志，以便在需要时进行恢复。

  2. 自动化运维工具：

    • 使用自动化工具如MHA（Master High Availability）或Percona XtraBackup进行主从切换和备份。
    • 考虑使用MySQL Shell或MySQL Router等官方工具管理复制拓扑。
    • 开发自定义脚本监控GTID一致性，并在发现问题时自动报警。

  3. 性能优化与调整：

    • 根据系统负载和性能需求，调整sync_binlog、sync_relay_log和sync_relay_log_info等参数。
    • 在高并发场景下，考虑使用并行复制功能提高复制性能。
    • 定期清理不再需要的二进制日志，使用PURGE BINARY LOGS命令，但需要谨慎操作以避免删除从库需要的GTID。

  4. 应急预案与演练：

    • 制定详细的主从切换应急预案，明确每个步骤和责任人。
    • 定期进行主从切换演练，确保在紧急情况下能够快速、正确地执行切换。
    • 测试不同故障场景下的数据恢复流程，确保能够有效处理GTID不一致问题。

六、总结与展望

6.1 主从切换GTID不一致问题总结

MySQL主从切换时出现GTID不一致问题的核心原因是各版本GTID机制和半同步复制模式的差异：

  1. 5.6版本：由于AFTER_COMMIT模式的半同步复制和GTID信息仅保存在二进制日志中，主从切换时容易出现事务已提交但未同步到所有从库的情况。

  2. 5.7版本：虽然引入了mysql.gtid_executed表和AFTER_SYNC模式的半同步复制，但在某些情况下（如连续崩溃）仍可能导致GTID丢失。

  3. 8.0版本：通过改进的GTID持久化机制和更可靠的恢复能力，显著降低了主从切换时出现GTID不一致的风险，但在复杂的多主复制拓扑中仍需谨慎管理。

解决这一问题的关键在于理解各版本的特性差异，采取适当的配置优化和主从切换最佳实践，并准备有效的故障修复方法。

6.2 MySQL复制技术发展趋势

随着MySQL的不断发展，复制技术也在持续演进，未来的发展趋势包括：

  1. 更高级的复制拓扑：

    • Group Replication等多主复制技术将更加成熟，提供更高的可用性和可扩展性。
    • 分布式事务支持将进一步增强，减少主从数据不一致的风险。

  2. 智能化的主从切换：

    • 自动化工具将能够更智能地检测和处理GTID不一致问题。
    • 基于AI的监控和预测系统将提前发现潜在的复制问题，避免故障发生。

  3. 数据一致性保障增强：

    • 更严格的事务一致性模型将被引入，确保主从复制的数据一致性。
    • 增强的半同步复制和同步复制选项将提供更高的数据安全性。

  4. 云原生复制解决方案：

    • 针对云环境优化的复制技术将成为主流，提供更好的弹性和可扩展性。
    • 云数据库服务将提供更简化的主从管理和故障转移机制。

6.3 最终建议

针对用户的问题，即主从切换时出现新从库GTID大于新主库GTID导致无法创建主从连接的问题，最终建议如下：

  1. 版本选择建议：

    • 如果可能，升级到8.0版本，其改进的GTID机制和恢复能力能够有效减少此类问题。
    • 如果必须使用5.6或5.7版本，确保遵循该版本的最佳实践，并实施适当的监控和备份策略。

  2. 配置优化建议：

    • 无论使用哪个版本，都应启用半同步复制，并设置sync_binlog=1和sync_relay_log=1。
    • 在5.7和8.0版本中，确保使用AFTER_SYNC模式的半同步复制。
    • 定期检查并优化GTID相关参数，确保它们适合您的应用场景。

  3. 主从切换最佳实践：

    • 主从切换前，确保所有从库与主库的数据完全同步，Seconds_Behind_Master为0。
    • 使用自动化工具执行主从切换，减少人为错误的风险。
    • 切换后，立即验证所有节点的GTID集合是否一致，并监控复制状态。

  4. 故障处理准备：

    • 提前熟悉GTID不一致问题的修复方法，包括RESET SLAVE ALL、SET GLOBAL gtid_purged等命令的使用。
    • 定期测试恢复流程，确保在出现问题时能够快速有效地进行修复。
    • 维护详细的文档和应急预案，明确每个步骤和责任人。

通过遵循这些建议，您可以显著降低MySQL主从切换时出现GTID不一致问题的风险，并在问题发生时能够迅速有效地进行处理，确保数据库的高可用性和数据一致性。

内容由 AI 生成

MySQL主从不一致问题相关处理
企业实战系列集 ●●● https://ximenjianxue.blog.youkuaiyun.com
09-26 1万+
某业务采取mysql的主从架构，但因为存储的问题，导致备库一直无法存储，数据同步一致性问题一直也未恢复，某次安全检查要求完成主备倒换演练，必须限期恢复主备，但是在恢复过程中，同步显示正常一段时间后，便会出现sql线程异常，主备数据不一致导致的同步错误情况。主数据库上面设置的max_allowed_packet比从数据库大，当一个大的sql语句，能在主数据库上面执行完毕，从数据库上面设置过小，无法执行，导致的主从不一致。根据上面的NR行数，查看附近的行，定位数据不一致的地方，后续手动补全。
MySQL主从复制【延时同步（GTID复制基础上）】
JohnnyG2000的博客
05-11 818
MySQL主从复制【延时同步】（GTID复制基础上）1、延时同步2、延时同步产生原因3、延时同步配置4、示例1）环境准备2）故障恢复思路:3）主库配置4）从库配置5）主库数据操作 & 从库观察6）恢复①查看relay-log的截取起点和终点②导出恢复库（GTID）③将导出的数据库传到两外两台服务器上④在各库分别进行进行恢复⑤重新建立主从连接a. slave1 重新与 master 建立主从连接b. slave2 重新与 master 建立主从连接⑥解决GTID误操作错误（本作者前一篇优快云博客有具
MySQL主从数据不一致，怎么办？
Daniel的博客
11-15 5737
先给大家说个身边的故事。小伙伴二狗最近面宇宙厂，前面被问MySQL索引、锁、主从复制原理时答的都很开心。当面试官问到：“你们遇到主从不一致的问题怎么解决呢？你有什么更好的方案吗？”二狗懵了。不就是读写时候走主，纯读走从吗。。难道还有什么别的办法？面试官：emmm……有。那我们换个问题，主从复制的方式有几种，你能讲讲吗？二狗：…… 问到盲点了面试官：答不上来没关系，您的情况我基本了解了。感谢您参加...
mysql5.7切换导致gtid不一致
formydream的博客
03-26 1340
今天在公司的工程环境中做了个案例，手动切换关闭主库的mysql服务，从库上升为主库之后，发现主库处于read_only状态，通过高可用的组件观察了剩余主从库的alive以及delay的状态发现均正常。由于处于公司的内网环境中，所以就没有保存图片，就通过文字的方式记录下今天这个案例。环境：mysql5.7.18 一主两从 做了高可用操作步骤：通过高可用组件发现三台mysql的主从关系，alive，d...
主从切换是怎么保证数据一致的？从库为什么会延迟
心比天高，仗剑走天涯，保持热爱，奔赴向梦想！
08-19 254
主库出问题，一般需要切换从库为主库。那么对于正在同步的数据，如何保证一致性呢？ 备库有时候延迟好几个小时的原因有哪些？解决方案是什么？
主从GTID不一致处理方法
DBA之路的博客
04-15 1394
原因： 我在从库上删除了一个测试库，因此从库的GTID比主库多 解决 ：在从库上创建库 ，然后在主库上删除。再在主库上跳过这两个GTID 从库 从库多出了两个GTID的事务： d3c6f103-803c-11ec-b805-08c0eb350a8a:1-2 在主库上跳过两个GTID set session gtid_next='d3c6f103-803c-11ec-b805-08c0eb350a8a:1' begin;commit; set session gti
MySQL 从库 GTID 大于主库
喝醉酒的小白
09-28 745
从库 GTID 大于主库”表示从库上存在主库没有的 GTID（通常是某个 server_uuid 对应的一段/多段事务编号）。复制 SQL 线程会检测到这种“超前”并暂停（避免把主库不存在的事务继续应用），导致复制无法继续。
【数据库高可用】基于MHA的MySQL主库故障自动转移系统设计：GTID模式下主从复制与VIP漂移实现
最新发布
11-12
内容涵盖环境规划、MySQL主从复制部署、MHA节点安装与配置、SSH免密登录设置、主从权限配置、故障自动与手动切换、在线切换操作、GTID复制模式下的数据一致性处理，以及通过VIP实现主库漂移的高可用机制。...
MySQL MHA 单主架构 主从切换 高可用
低温热源的博客
06-27 1123
MHA由两部分组成:MHAManager (管理节点)和MHA Node (数据库节点),MHA Manager 可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台 slave 节点上。MHA Node 运行在每台 MySQL 服务器上，MHAManager 会定时探测集群中的master 节点，当master 出现故障时，它可以自动将最新数据的slave 提升为新的master，然后将所有其他的slave 重新指向新的master。整个故障转移过程对应用程序完全透明。
京东二面：MySQL 主从延迟，读写分离 7 种解决方案
m0_74931226的博客
11-22 323
之间的数据同步问题，从库查询哪条记录，我们只要保证之前对应的写binglog已经同步完数据即可，可以不用管主从库的所有的事务binlog 是否同步。这个问题跟 MQ消息队列 既要求高吞吐量又要保证顺序是一样的，从全局来看确实无解，但是缩小范围就容易多了，我们可以保证一个分区内的消息有序。要求不是很高，比如：大V有千万粉丝，发布一条微博，粉丝晚几秒钟收到这条信息，并不会有特别大的影响。无论采用上面哪一种方案，如果主库的写操作频繁不断，那么从库的值永远跟不上主库的值，那么读流量永远是打在了主库上。
一文解决MySQL主从导致数据不一致问题
m0_49151953的博客
04-12 4148
但是，由于网络延迟、主从复制配置不当等原因，可能会导致数据不一致的问题，这是一个需要高度重视的问题。通过设置正确的时区、选择正确的二进制日志格式、使用GTID、定期检查主从同步状态和使用第三方工具等手段，可以有效地解决数据不一致的问题。2.选择正确的二进制日志格式：在MySQL 5.6版本以后，推荐使用“ROW”格式的二进制日志格式，因为它可以记录每一行数据的变化情况，从而避免了数据不一致的问题。1.网络延迟：主从复制需要通过网络进行数据同步，如果网络延迟过高，就会导致数据同步不及时，从而导致数据不一致。
mysql主从GTID不一致问题gtid_executed，gtid_purged ,Retrieved_Gtid_Set,Executed_Gtid_Set（I）
码农崛起
08-08 6097
slave会扫描最后一个relay log文件，Retrieved_Gtid_Set显示的是当前扫描所得的GTID；io线程会通过扫描所得的最后一个GTID+1（如果Retrieved_Gtid_Set>=Executed_Gtid_Set）为依据来拉取，如果Retrieved_Gtid_Set。
MySQL 主从GTID不一致导致主从切换报错
sinat_36757755的博客
04-12 2750
主从切换之后，新从库同步复制新主库产生报错1236，从库请求的gtid不在主库现有的binlog日志里。
数据库主从数据不一致解决方案
霓虹深处
10-25 1336
Master： 查看下进程是否Sleep太多 show processlist; 查看master状态： show master status; slave 查看状态： show slave status\G Slave_IO_Running: Yes Slave_SQL_Running: No 可见slave不同步。解决方法： 方法一：忽略错误后，继续同步...
mysql主从切换gtid不一致_解决mysql使用GTID主从复制错误问题
weixin_39520595的博客
02-02 1415
解决mysql使用GTID主从复制错误问题做MySQL主从的话肯定会遇到很多同步上的问题, 大多数都是由于机器宕机,重启,或者是主键冲突等引起的从服务器停止工作, 这里专门收集类似问题并提供整理解决方案,仅供参考!1、主从网络中断，或主服务器重启，或从服务器重启，从会根据配置文件中的时间(默认1分钟)去自动重连主服务器，直到网络和服务均可正常连接，连接正常后可自动继续同步之前文件，不需要任何人工干...
基于GTID Replication主从数据不一致操作
weixin_33825683的博客
07-18 179
基本的M-S结构   现在master与slave主机数据一致：   mysql&gt; select * from t1; +------+ | id   | +------+ |    1 | |    2 | |    4 | +------+ 3 rows in set (0.00 sec)   我们来模拟故障现象： 在master上，通过设置sql_log_...
mysql主从gtid不一致_基于GTID Replication主从数据不一致操作
weixin_31674039的博客
01-25 670
基本的M-S结构现在master与slave主机数据一致：mysql> select * from t1;+------+| id |+------+| 1 || 2 || 4 |+------+3 rows in set (0.00 sec)我们来模拟故障现象：在master上，通过设置sql_log_bin来控制命令是否写入二进制日志中，运行命令：set sql_l...
！！！Linux下基于GTID的Mysql主从复制时，数据不一致的处理办法（mysql版本：mysql-5.7.24）——SQL线程异常
qq_42303254的博客
03-12 532
续我的上篇博文：https://mp.youkuaiyun.com/postedit/87896993 1.在主库和从库上准备数据 从库上操作： [root@server2 mysql]# mysql -pXinjiaojiao+623 mysql> use westos; mysql> update usertb set password='456' where userna...
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值