# MySQL 8.4 复制冲突解决指南 > **AI 响应规范 (MySQL 执行策略)**: > 1. **强制参数**: 所有 `docker exec` 命令必须包含 `-h127.0.0.1` 参数。 > 2. **双重输出**: 涉及 SQL 操作时,必须同时输出 `Docker 执行命令` 和 `纯 SQL 脚本`。 > 3. **默认连接**: 默认使用 `-uroot -pafe123456 -h127.0.0.1`。 > 4. **排障连贯性**: 诊断复制冲突时,在提供 **A. 查看复制状态概要** 后,**必须紧跟** 提供 **B. 自动提取错误详情** 脚本,以便用户直接获取修复建议。 ## 1. 复制冲突解决(主键/唯一键重复或记录缺失) ### 1.1 快速定位冲突信息 当复制中断时,**必须按顺序执行以下两步**:首先查看概要,然后提取详细错误以获取修复脚本。 **A. 查看复制状态概要:** ```bash # 方式 1: 传统状态查看 (重点关注 Last_SQL_Error) docker exec -it mysql mysql -uroot -pafe123456 -h127.0.0.1 -e "SHOW REPLICA STATUS\G" | grep -E "Replica_.*_Running|Last_SQL_Error|Retrieved_Gtid_Set|Executed_Gtid_Set" # 方式 2: 多线程环境下查看详情 (若启用并行复制,SHOW REPLICA STATUS 只能看到协调线程错误) docker exec -it mysql mysql -uroot -pafe123456 -h127.0.0.1 -e "SELECT * FROM performance_schema.replication_applier_status_by_worker WHERE LAST_ERROR_NUMBER > 0\G" ``` **B. 自动提取错误详情(支持 1062 重复键 / 1032 记录未找到):** 直接在宿主机执行以下脚本,它会自动解析错误日志并生成对应的修复方案: ```bash # 提取冲突 GTID、表、冲突值及修复建议 grep -aE "Duplicate entry|Error_code: 1032" /data/mysql/logs/mysql_error.log | perl -nle ' if (/^(\S+).*?transaction\s+[\x27"]([^\x27"]+)[\x27"].*?table\s+([^\s;]+);/) { my ($time, $gtid, $table) = ($1, $2, $3); print "\n" . "="x60; print "时间: $time"; print "GTID: $gtid"; print "表名: $table"; if (/Duplicate entry\s+[\x27"]([^\x27"]+)[\x27"]\s+for\s+key\s+[\x27"]([^\x27"]+)[\x27"]/) { print "类型: 1062 (主键/唯一键重复)"; print "冲突值: $1 (索引: $2)"; print "\n方案 A (手动修复 - 删除从库冲突行):"; print "DELETE FROM $table WHERE [主键列] = \x27$1\x27;"; print "\n方案 B (跳过事务 - 保持从库现状):"; print "STOP REPLICA; SET GTID_NEXT=\x27$gtid\x27; BEGIN; COMMIT; SET GTID_NEXT=\x27AUTOMATIC\x27; START REPLICA;"; } elsif (/Error_code: 1032|HA_ERR_KEY_NOT_FOUND/) { print "类型: 1032 (记录未找到 - 通常是 Delete/Update 目标不存在)"; print "说明: 目标行在从库已不存在,Delete 操作已实质生效。"; print "\n方案 A (直接跳过 - 安全):"; print "STOP REPLICA; SET GTID_NEXT=\x27$gtid\x27; BEGIN; COMMIT; SET GTID_NEXT=\x27AUTOMATIC\x27; START REPLICA;"; } } ' ``` ### 1.2 安全修复冲突(推荐删除冲突数据) 停止复制,临时关闭 binlog(避免删除操作同步到对端): **A. Docker 执行模式 (包含 -h127.0.0.1):** ```bash # 以实际冲突表和主键为例(示例:test_sync.t1 的 id=12) docker exec -it mysql mysql -uroot -pafe123456 -h127.0.0.1 -e " STOP REPLICA; SET sql_log_bin = OFF; DELETE FROM `test_sync`.`t1` WHERE `id` = 12; SET sql_log_bin = ON; START REPLICA; SHOW REPLICA STATUS\G; " ``` **B. 纯 SQL 模式:** ```sql STOP REPLICA; SET sql_log_bin = OFF; DELETE FROM `test_sync`.`t1` WHERE `id` = 12; SET sql_log_bin = ON; START REPLICA; SHOW REPLICA STATUS\G; ``` ### 1.3 应急跳过冲突事务(仅紧急场景) 精准跳过指定 GTID 事务(MySQL 8.0+ 推荐): **A. Docker 执行模式 (包含 -h127.0.0.1):** ```bash docker exec -it mysql mysql -uroot -pafe123456 -h127.0.0.1 -e " STOP REPLICA; SET GTID_NEXT = '760f0600-f896-11ef-b265-0242ac130002:6'; # 替换为实际冲突 GTID BEGIN; COMMIT; SET GTID_NEXT = 'AUTOMATIC'; START REPLICA; " ``` **B. 纯 SQL 模式:** ```sql STOP REPLICA; SET GTID_NEXT = '760f0600-f896-11ef-b265-0242ac130002:6'; BEGIN; COMMIT; SET GTID_NEXT = 'AUTOMATIC'; START REPLICA; ``` ## 2. 全量备份还原解决冲突(适用于严重冲突场景) 当复制冲突过多、数据不一致严重,或手动修复成本过高时,可以使用全量备份还原的方式彻底解决冲突问题。此方法通过从主库(或备份库)全量备份数据,然后在从库上完全还原,实现数据一致性。 ### 2.1 相关脚本 - **备份脚本**: [`backup-sync.sh`](./backup-sync.sh) - 在主库或备份库上执行全量备份 - **还原脚本**: [`restore-sync.sh`](./restore-sync.sh) - 在从库上执行全量还原 ### 2.2 操作流程 #### 步骤 1: 在备份机上执行备份 在需要备份的 MySQL 服务器(通常是主库或数据一致的节点)上执行备份脚本: ```bash # 备份所有数据库(默认) cd /data/backup/mysql ./backup-sync.sh # 或指定标签备份 ./backup-sync.sh -t conflict_resolve # 或备份指定数据库 ./backup-sync.sh database1 database2 ``` 备份脚本会自动: - 设置 MySQL 为只读模式 - 停止复制(如果是从库) - 记录当前 GTID 位置 - 执行全量备份并压缩为 `.7z` 文件 - 恢复 MySQL 为读写模式 备份完成后,会在 `/data/backup/mysql/` 目录下生成 `YYYYMMDDHHMMSS.7z` 或 `YYYYMMDDHHMMSS_TAG.7z` 格式的备份文件。 #### 步骤 2: 传输备份文件到还原机 使用 `scp` 将备份文件推送到需要还原的 DB 机的 `/data/backup/mysql/` 目录: ```bash # 从备份机执行(将备份文件推送到还原机) scp /data/backup/mysql/YYYYMMDDHHMMSS.7z user@restore-server:/data/backup/mysql/ # 示例 scp /data/backup/mysql/20250127120000.7z root@192.168.1.100:/data/backup/mysql/ ``` **注意**: 确保还原机的 `/data/backup/mysql/` 目录存在且有写入权限。 #### 步骤 3: 在还原机上执行还原 在需要还原的 MySQL 服务器(从库)上执行还原脚本: ```bash cd /data/backup/mysql # 还原所有数据库 ./restore-sync.sh YYYYMMDDHHMMSS.7z # 或仅还原指定数据库 ./restore-sync.sh YYYYMMDDHHMMSS.7z database1.sql ``` 还原脚本会自动: - 设置 MySQL 为只读模式 - 停止复制 - 重置二进制日志和 GTID - 导入备份数据(导入时禁用 binlog,避免循环复制) - 设置 GTID purged(从备份时的 GTID 位置) - 恢复 MySQL 为读写模式 - **自动启动复制并检查状态** #### 步骤 4: 在备份机上启动同步(重要) 还原完成后,还原脚本会自动启动复制并显示同步状态。确认看到同步成功后,**需要在备份机(主库)上执行以下操作**: **A. Docker 执行模式 (包含 -h127.0.0.1):** ```bash docker exec -it mysql mysql -uroot -pafe123456 -h127.0.0.1 -e " START REPLICA; " ``` **B. 纯 SQL 模式:** ```sql START REPLICA; ``` 等待 3 秒后,检查同步状态: **A. Docker 执行模式 (包含 -h127.0.0.1):** ```bash sleep 3 docker exec -it mysql mysql -uroot -pafe123456 -h127.0.0.1 -e "SHOW REPLICA STATUS\G" ``` **B. 纯 SQL 模式:** ```sql -- 等待 3 秒后执行 SHOW REPLICA STATUS\G; ``` 检查关键指标: - `Replica_IO_Running`: 应为 `Yes` - `Replica_SQL_Running`: 应为 `Yes` - `Last_IO_Error`: 应为空 - `Last_SQL_Error`: 应为空 - `Seconds_Behind_Source`: 延迟秒数(应逐渐减小) ### 2.3 注意事项 1. **备份时机**: 建议在业务低峰期执行备份,减少对业务的影响 2. **网络传输**: 确保备份机和还原机之间网络畅通,备份文件较大时传输可能需要较长时间 3. **磁盘空间**: 确保还原机有足够的磁盘空间存放备份文件和临时解压文件 4. **权限要求**: 脚本需要 MySQL root 权限,以及 `/data/backup/mysql/` 目录的读写权限 5. **GTID 一致性**: 还原脚本会自动处理 GTID,确保复制能够正常继续 6. **备份机同步**: 还原完成后务必在备份机(主库)上执行 `START REPLICA` 并检查状态,确保双向复制正常