mysql-gtid-跳过事务

问题

2017-01-24 09:20:36 44646 [ERROR] Slave SQL: Could not execute Write_rows event on table test.test_table;
Duplicate entry '81354' for key 'PRIMARY', Error_code: 1062;
handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysql-bin.000006, end_log_pos 801050669, Error_code: 1062

插入重复的key,导致插入失败,由于线上是使用双主同步的方式,不能简单的删除掉这条记录,再开始同步,这样做到最后,这个删除操作还会被同步执行,这条记录就真的被删除了

  1. 使用mysqlbinlog命令,查看mysql-bin.000006中end_log_pos=801050669,相应事务的gtid
    mysqlbinlog mysql-bin.000006 --base64-output=decode-rows -v | grep 801050669 -A10B5
    
    # at 801049266
    #170124  8:28:21 server id 224  end_log_pos 801049314 CRC32 0x0bf0f80d  GTID [commit=yes]
    SET @@SESSION.GTID_NEXT= 'cdc2c1ce-dfbc-11e6-85d0-e41d2d5336a4:1943572'/*!*/;
    # at 801049314
    #170124  8:28:21 server id 224  end_log_pos 801049394 CRC32 0xa764097f  Query   thread_id=1013  exec_time=0     error_code=0
    SET TIMESTAMP=1485217701/*!*/;
    BEGIN
    /*!*/;
    # at 801049394
    # at 801050168
    #170124  8:28:21 server id 224  end_log_pos 801050295 CRC32 0x6364d6b6  Table_map: `test`.`test_table` mapped to number 258
    # at 801050295
    #170124  8:28:21 server id 224  end_log_pos 801050669 CRC32 0x897bf9ab  Write_rows: table id 258 flags: STMT_END_F
    
    
  2. 登录备库
    --由于gtid是连续的,所以只能通过注入空事务的方式跳过出错的事务
    stop slave;
    set gtid_next='cdc2c1ce-dfbc-11e6-85d0-e41d2d5336a4:1943572';
    begin;commit;
    set gtid_next='automatic';
    start slave;
    

转载于:https://my.oschina.net/zjoschina/blog/830250

<think>首先,用户的问题是:Docker部署MySQL主从复制失败。主库的Executed_Gtid_Set是6c813542-5229-11f0-824f-02420a000157:1-11,File是mysql-bin.000003。从库的Executed_Gtid_Set是6c8134e5-5229-11f0-bda0-02420a000158:1-5,Relay_Log_File是slave-relay-bin.000001。如何处理这个问题。我需要参考提供的引用内容来解决这个问题。引用包括配置MySQL主从复制的步骤、错误处理和GTID相关的信息。关键点:-引用[1]:展示了配置从库的命令,包括SOURCE_HOST,SOURCE_USER,SOURCE_PASSWORD,SOURCE_LOG_FILE,SOURCE_LOG_POS。-引用[2]:从库的my.cnf配置,包括server-id,log-bin,binlog_format等。-引用[3]:配置从库的基本步骤,包括设置server-id和重启服务。-引用[4]:处理GTID相关错误,特别是当数据不同步时,涉及Retrieved_Gtid_Set和Executed_Gtid_Set。-引用[5]:MySQL配置,如time_zone和sql_mode。用户的问题涉及GTID集合不同步。主库的Executed_Gtid_Set是6c813542-5229-11f0-824f-02420a000157:1-11,从库的是6c8134e5-5229-11f0-bda0-02420a000158:1-5。这表明主库和从库有不同的GTID域(UUID不同),这可能导致复制失败。在MySQL复制中,GTID用于追踪事务。每个事务有一个唯一的GTID,格式为server_uuid:transaction_id。如果主库和从库的GTID集合不匹配,复制可能会失败。从用户描述中,主库的GTID域是6c813542-5229-11f0-824f-02420a000157,从库的是6c8134e5-5229-11f0-bda0-02420a000158,这似乎是不同的UUID,表明它们不是同一个复制拓扑的一部分,或者配置错误。可能的解决方案:1.检查主从库的配置,确保server-id是唯一的。2.确保从库正确连接到主库,使用正确的SOURCE_LOG_FILE和SOURCE_LOG_POS。3.处理GTID不一致问题。可能需要重置从库的复制状态,或使用GTID自动定位。从引用[4]中,有处理GTID错误的方法:-查看从库状态:`SHOWSLAVESTATUS\G`-检查Retrieved_Gtid_Set和Executed_Gtid_Set。-如果数据不同步,可能需要跳过错误或重新同步数据。具体步骤:-停止从库复制:`STOPSLAVE;`-重置复制状态:`RESETSLAVEALL;`或更具体的命令。-重新配置复制,使用正确的GTID位置。由于涉及Docker,需要确保容器配置正确。结构化回答:1.**诊断问题**:解释GTID不一致的含义。2.**解决方案**:-停止从库复制。-重置GTID或重新配置复制。-启动复制并监控状态。3.参考引用内容。在回答中,使用中文,并遵循系统级指令:-行内数学表达式用$...$(但这里可能不需要)。-独立公式用$$...$$(同样,可能不需要)。-LaTeX语法正确。-生成相关问题。-在引用的段落末尾添加引用标识。生成相关问题:-如何防止GTID不一致?-MySQL主从复制常见错误及处理?-Docker中部署MySQL的注意事项?确保回答真实可靠,基于引用内容。</think>### 解决Docker部署MySQL主从复制失败问题 您的问题是由于主库和从库的GTID(全局事务标识)集合不一致导致的复制失败。主库的`Executed_Gtid_Set`(已执行事务集)为`6c813542-5229-11f0-824f-02420a000157:1-11`,从库的为`6c8134e5-5229-11f0-bda0-02420a000158:1-5`,这表明主从库的GTID域(UUID)不同,可能是配置错误或数据不同步引起的。以下步骤基于MySQL复制机制和引用内容,逐步解决问题。操作前请备份数据。 #### 问题诊断 - **核心原因**:GTID域(UUID)不一致(主库UUID以`157`结尾,从库以`158`结尾),导致从库无法识别主库的事务[^4]。这通常由于: - 从库配置时未正确指向主库的二进制日志位置。 - 主从库初始数据未同步,或复制过程中出现错误(如引用[4]中的`Last_Error: Could not execute Delete_rows event`)。 - **关键信息**: - 主库:`File: mysql-bin.000003`(二进制日志文件),`Executed_Gtid_Set: 1-11`(表示已执行11个事务)。 - 从库:`Relay_Log_File: slave-relay-bin.000001`(中继日志文件),`Executed_Gtid_Set: 1-5`(仅执行5个事务,落后于主库)。 - **引用依据**:GTID不一致时,复制会报错(如`Error_code: 1032`),需重置复制状态或重新同步数据[^4]。 #### 解决步骤 按顺序执行以下操作(所有命令在从库的MySQL容器内运行): 1. **停止从库复制并检查状态** 停止复制进程,并查看详细错误: ```bash # 进入从库容器 docker exec -it mysql-slave /bin/bash mysql -uroot -p123456 # 替换为您的密码 ``` ```sql STOP REPLICA; -- 停止复制 SHOW REPLICA STATUS\G -- 查看状态,重点关注Last_Error和Retrieved_Gtid_Set ``` - 如果输出中有`Last_Error`(如引用[4]中的`Can't find record`),记录错误位置(如`end_log_pos 4966`)。 - 比较`Retrieved_Gtid_Set`(从主库获取的事务)和`Executed_Gtid_Set`(从库执行的事务),确认落后的事务范围[^4]。 2. **重置从库复制状态** 清除当前复制配置和GTID信息,强制重新同步: ```sql RESET REPLICA ALL; -- 清除所有复制配置 SET GLOBAL gtid_purged = '6c813542-5229-11f0-824f-02420a000157:1-11'; -- 手动设置从库的GTID集与主库一致 ``` - **说明**:`gtid_purged` 设置从库的起始GTID,使其匹配主库的`Executed_Gtid_Set`(这里是`1-11`),避免UUID冲突[^4]。 3. **重新配置复制通道** 使用主库的最新二进制日志位置重新配置: ```sql CHANGE REPLICATION SOURCE TO SOURCE_HOST='192.168.98.140', -- 替换为主库IP SOURCE_USER='backups', -- 替换为复制用户 SOURCE_PASSWORD='123456', -- 替换为密码 SOURCE_LOG_FILE='mysql-bin.000003', -- 主库的File值 SOURCE_LOG_POS=4, -- 起始位置,通常设为4(文件开头),或根据SHOW MASTER STATUS获取精确值 SOURCE_AUTO_POSITION=1; -- 启用GTID自动定位 ``` - **关键点**: - `SOURCE_LOG_FILE` 和 `SOURCE_LOG_POS` 必须与主库一致(主库查询:`SHOW MASTER STATUS;` 获取最新File和Position)[^1]。 - `SOURCE_AUTO_POSITION=1` 优先使用GTID,避免位置偏移错误[^2]。 4. **启动复制并验证** 启动复制并监控状态: ```sql START REPLICA; SHOW REPLICA STATUS\G -- 检查IO/SQL线程状态 ``` - **期望输出**: - `Replica_IO_Running: Yes`(I/O线程正常)。 - `Replica_SQL_Running: Yes`(SQL线程正常)。 - `Retrieved_Gtid_Set` 和 `Executed_Gtid_Set` 应与主库一致(如`1-11`)[^1]。 5. **故障回退(可选)** 若仍失败,检查配置文件: - **主从库的`my.cnf`**:确保`server-id`唯一(主库如`server-id=100`,从库如`server-id=101`),并启用GTID: ```ini [mysqld] server-id=101 -- 必须唯一 gtid_mode=ON enforce_gtid_consistency=ON binlog_format=ROW -- 推荐ROW格式减少错误[^2] ``` 修改后重启容器:`docker restart mysql-slave`[^2][^5]。 #### 预防措施 - **初始化同步**:部署主从前,使用`mysqldump`备份主库数据并导入从库,确保数据一致。 - **监控**:定期运行`SHOW REPLICA STATUS\G`,检查`Seconds_Behind_Master`(延迟秒数)。 - **Docker特定**:确保容器网络互通(使用同一Docker网络),并映射配置文件(如`docker run -v /path/my.cnf:/etc/mysql/my.cnf`)[^3][^5]。 通过以上步骤,复制应恢复正常。如遇特定错误(如`Error_code: 1032`),可能需要手动跳过事务或修复数据[^4]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值