当前位置：首页 > news >正文

MySQL：Last_IO_Errno:“0“, Last_IO_Error:““, Last_SQL_Errno:“1950“

news 2026/6/13 6:55:04

目录标题

一、现象（你给出的日志）
二、原因与原理（要点）
三、诊断步骤（先看清当前状况，**只读操作**优先）
四、可选的、安全的解决方案（按风险从低到高）
- 方法 A — 最安全（推荐）
- 方法 B — 如果你确实能确认某些 GTID 是“可以丢弃/跳过”的（高风险，不推荐在生产随意使用）
- 方法 C — 针对多源 / 切换主引起的冲突
五、具体建议（步骤化、可执行）
六、避免复发的操作与良好实践

一、现象（你给出的日志）

Replica 报错（Slave_SQL_Running = No），错误信息（Last_SQL_Error）：

An attempt was made to binlog GTID 1109121115-1109810028-61915841 which would create an out-of-order sequence number with existing GTID 1109121115-1109810028-61917163, and gtid strict mode is enabled

你说“在主库锁了FLUSH LOGS，再重做备库就可以了”。下面解释为什么发生、为什么FLUSH LOGS有时能“解决”、以及标准、安全的处理方法。

二、原因与原理（要点）

GTID 的语义
GTID（格式类似source_id-server_id-transaction_id）用于标识每一笔事务。副本在应用事务时，会检查 GTID 的顺序性，确保不会出现“回退/重复/乱序”应用事务。
错误的含义
错误信息说明：副本上已经存在同一 source（1109121115-1109810028）下的更大的事务序号61917163，而 Master 现在要发送的 GTID 为61915841（比已存在的要小）。在gtid_strict_mode或 GTID 模式下，这是不允许的 —— 因为这表示要在已执行更高序号的基础上再执行一个“更旧”的序号，可能导致不一致或重复。
典型触发场景（常见几类原因）
- 你把某个备库或其他服务器上的事务导入到当前 replica，导致 replica 的Executed_Gtid_Set包含了 Master 没有的、但序号更高的 GTID。
- 以前在 replica 上意外做了写操作（非只读），产生了 GTID，或用不一致的备份恢复（比如恢复了来自不同时间点/不同主机的 binlog），导致 GTID 集不连续。
- 多源/切换主库操作中，master/backup 的 GTID 集不同步。
- server_uuid冲突或错误的备份恢复方法（没有正确处理 gtid_purged / gtid_executed）也能引发类似问题。
为什么FLUSH LOGS有时“能解决”
FLUSH LOGS会切换/生成新的二进制日志文件（rotate binary log）。在某些临时场景，这样做的副作用会让你用新的起点重新建立复制（比如你随后从新的 binlog 文件起点重新建立复制或用新的备份做同步），从而避开发送那个“旧的” GTID。但这只是在某些特定流程下碰巧对齐了 GTID 集 —— 本质上不是根本修复。如果副本的Executed_Gtid_Set已包含比 master 当前发出的序号更高的 GTID，单纯 rotate binlog 并不会修改已经存在于副本上的 GTID 集；通常是你在重建备库时以某种方式对齐了起点，所以看起来“可行”。

三、诊断步骤（先看清当前状况，只读操作优先）

在 master / replica 上执行下面命令，记录输出以便判断差异：

在 Master 上：

SHOWGLOBALVARIABLESLIKE'gtid_mode';SHOWGLOBALVARIABLESLIKE'enforce_gtid_consistency';SHOWMASTERSTATUS\GSHOWBINARYLOGS;SELECT@@server_uuid;

在 Replica 上（报错的那个）：

SHOWSLAVESTATUS\G-- 注意 Last_IO_Error / Last_SQL_Error / Executed_Gtid_Set / Retrieved_Gtid_SetSELECT@@server_uuid;SHOWGLOBALVARIABLESLIKE'gtid_mode';

重点看：

Executed_Gtid_Set（副本已经执行的 GTID 集）
Retrieved_Gtid_Set（副本已接收但未执行的 GTID）
Master 的SHOW MASTER STATUS返回的File、Position和GTID相关信息
server_uuid是否有冲突

四、可选的、安全的解决方案（按风险从低到高）

方法 A — 最安全（推荐）

彻底重新同步副本（从 master 做一次一致性备份，然后恢复到副本，启用 GTID 自动定位）
步骤大致：

在 Master 上做一致性备份（推荐使用 XtraBackup 或 LVM snapshot），或 mysqldump（对生产建议使用物理备份）。备份时记录 master 的 GTID 状态（SHOW MASTER STATUS/GTID_EXECUTED）。
在 replica 上停止 slave 并清理旧的 relay log：

STOP SLAVE;RESET SLAVEALL;-- MySQL 5.7+, 注意这会删除复制配置信息

恢复备份到 replica（确保数据目录为空或按备份指示恢复）。
在 replica 上设置复制：

CHANGE MASTERTOMASTER_HOST='master_host',MASTER_USER='repl',MASTER_PASSWORD='...',MASTER_AUTO_POSITION=1;STARTSLAVE;

这保证 master 和 replica 的 GTID 集一致，消除 out-of-order。

优点：安全、长远；缺点：需要数据传输/恢复时间。

方法 B — 如果你确实能确认某些 GTID 是“可以丢弃/跳过”的（高风险，不推荐在生产随意使用）

注意：GTID 模式下不能像传统非-GTID那样用SQL_SLAVE_SKIP_COUNTER随意跳过。错误处理需要非常谨慎。

如果 replica 是空的新服务器，或者你确认要“重置”它的已执行 GTID（非常危险，会影响数据一致性），可以在停止服务器、清空数据目录后，用：

SETGLOBALgtid_purged='已知安全的GTID_SET';

但gtid_purged只能在datadir为空时设置。通常只有在新建实例或完全重新初始化时使用。

对于已有数据并想“修复”局部冲突，没有通用的安全 SQL 指令。通常需要重建从库或人工对比并补数据。

方法 C — 针对多源 / 切换主引起的冲突

如果你做过主库切换、或者启用了多源复制，确保在切换时使用CHANGE MASTER TO ... MASTER_AUTO_POSITION=1并且处理好gtid_purged/gtid_executed。否则建议按方法 A 重建一遍。

五、具体建议（步骤化、可执行）

先诊断，不要盲目执行修改。把SHOW SLAVE STATUS\G输出贴出来（或核对以下关键字段）：Executed_Gtid_Set,Retrieved_Gtid_Set,Master_Log_File,Relay_Master_Log_File,Last_SQL_Error。
如果数据量允许，选择重新做一次从库初始化（方法 A）：这是最稳妥的。
如果必须临时恢复业务且你确认这笔冲突事务是“历史/可舍弃”的（非常少见），可以考虑在测试环境演练“重建从库”或使用gtid_purged在空数据目录上设置（极其谨慎）。
检查并修正运维流程，避免将备份恢复到副本后不正确处理 GTID 的情况；确保 replica 保持只读（read_only=ON、super_read_only=ON）以防意外写入。
检查server_uuid：SELECT @@server_uuid;确保每台实例唯一，避免 UUID 冲突导致的 GTID 问题。
如需快速恢复测试可行性，可把你 Master/Replica 的SHOW MASTER STATUS和SHOW SLAVE STATUS\G输出贴上来，我可以基于真实输出给出更精确的命令和步骤。