news 2026/7/11 13:32:43

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

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
MySQL：Last_IO_Errno:“0“, Last_IO_Error:““, Last_SQL_Errno:“1950“

目录标题

  • 一、现象（你给出的日志）
  • 二、原因与原理（要点）
  • 三、诊断步骤（先看清当前状况，**只读操作**优先）
  • 四、可选的、安全的解决方案（按风险从低到高）
    • 方法 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有时能“解决”、以及标准、安全的处理方法。

二、原因与原理（要点）

  1. GTID 的语义
    GTID（格式类似source_id-server_id-transaction_id）用于标识每一笔事务。副本在应用事务时，会检查 GTID 的顺序性，确保不会出现“回退/重复/乱序”应用事务。

  2. 错误的含义
    错误信息说明：副本上已经存在同一 source（1109121115-1109810028）下的更大的事务序号61917163，而 Master 现在要发送的 GTID 为61915841（比已存在的要小）。在gtid_strict_mode或 GTID 模式下，这是不允许的 —— 因为这表示要在已执行更高序号的基础上再执行一个“更旧”的序号，可能导致不一致或重复。

  3. 典型触发场景（常见几类原因）

    • 你把某个备库或其他服务器上的事务导入到当前 replica，导致 replica 的Executed_Gtid_Set包含了 Master 没有的、但序号更高的 GTID。
    • 以前在 replica 上意外做了写操作（非只读），产生了 GTID，或用不一致的备份恢复（比如恢复了来自不同时间点/不同主机的 binlog），导致 GTID 集不连续。
    • 多源/切换主库操作中，master/backup 的 GTID 集不同步。
    • server_uuid冲突或错误的备份恢复方法（没有正确处理 gtid_purged / gtid_executed）也能引发类似问题。

  4. 为什么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 自动定位）
步骤大致：

  1. 在 Master 上做一致性备份（推荐使用 XtraBackup 或 LVM snapshot），或 mysqldump（对生产建议使用物理备份）。备份时记录 master 的 GTID 状态（SHOW MASTER STATUS/GTID_EXECUTED）。
  2. 在 replica 上停止 slave 并清理旧的 relay log：
STOP SLAVE;RESET SLAVEALL;-- MySQL 5.7+, 注意这会删除复制配置信息
  1. 恢复备份到 replica（确保数据目录为空或按备份指示恢复）。
  2. 在 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随意跳过。错误处理需要非常谨慎。

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

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

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

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

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

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

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

六、避免复发的操作与良好实践

  • 生产从库设置read_only=ON、super_read_only=ON（防止误写）。
  • 备份/恢复时明确记录并处理 GTID（使用支持 GTID 的物理备份工具）。
  • 在做主从切换或打补丁前，先导出/记录当前 GTID 集。
  • 确保每台 MySQL 的server_uuid唯一且正确。
  • 在变更复制拓扑时，优先在测试环境演练 GTID 解析、恢复流程。

如果你愿意，我现在可以基于你当前实例的真实输出给出针对性的修复步骤（例如，假如你打算重建从库，我会给出完整命令序列和注意事项）。请直接把以下输出贴上来（不需要任何额外说明，我会直接给具体步骤）：

  • Master：SHOW MASTER STATUS\G的完整输出
  • Replica：SHOW SLAVE STATUS\G的完整输出（特别关注Executed_Gtid_Set和Last_SQL_Error）
  • SELECT @@server_uuid;在主、备两边的结果
  • SHOW GLOBAL VARIABLES LIKE 'gtid_mode';在主、备两边的结果

总之：错误来源于 GTID 的“顺序/集合”不一致，最安全的修复是用一致性备份重新初始化副本。FLUSH LOGS有时带来巧合性的“对齐效果”，但并非通用或可靠的根治方法。需要我帮你根据真实状态出具体逐步命令吗？

版权声明: 本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：809451989@qq.com进行投诉反馈，一经查实，立即删除！
网站建设 2026/7/10 21:18:53

5分钟快速上手：BDD100K数据集完整下载与训练指南

5分钟快速上手：BDD100K数据集完整下载与训练指南 【免费下载链接】BDD100K数据集下载仓库 BDD100K数据集下载仓库本仓库提供BDD100K数据集的下载资源，包含所有的训练集和测试集，以及darknet文件，可以直接用于训练 项目地址: htt…

作者头像 李华
网站建设 2026/7/11 6:59:58

终极指南：让Blender一键导入真实世界3D建筑模型

你是否曾经为创建逼真的城市场景而烦恼？现在，通过MapsModelsImporter这个神奇的Blender插件，你可以在几分钟内将Google地图中的真实建筑转换为可编辑的3D模型！ 【免费下载链接】MapsModelsImporter A Blender add-on to import mo…

作者头像 李华
网站建设 2026/7/10 10:29:18

1629个精选阅读书源，为阅读3.0带来全新体验

1629个精选阅读书源，为阅读3.0带来全新体验 【免费下载链接】最新1629个精品书源.json阅读3.0 最新1629个精品书源.json阅读3.0 项目地址: https://gitcode.com/open-source-toolkit/d4322 还在为找不到优质书源而烦恼吗？现在，我们为您…

作者头像 李华
网站建设 2026/7/9 14:05:06

GLM-4.5：3550亿参数开源模型如何重新定义智能体开发范式

GLM-4.5：3550亿参数开源模型如何重新定义智能体开发范式 【免费下载链接】GLM-4.5 GLM-4.5拥有3550亿总参数和320亿活跃参数，而GLM-4.5-Air采用更紧凑的设计，总参数为1060亿，活跃参数为120亿。GLM-4.5模型统一了推理、编程和智能体…

作者头像 李华
网站建设 2026/7/10 11:02:17

Wan2.2-T2V-A14B能否理解‘情绪’类抽象描述？实验来了

Wan2.2-T2V-A14B能否理解“情绪”？一场关于AI情感表达的深度实验 在广告创意会议上，一位导演指着屏幕说：“我想要一个镜头——孩子跑向远方，母亲站在原地，风轻轻吹起她的发丝，那种说不出的不舍。” 传统流程…

作者头像 李华
网站建设 2026/7/11 4:14:27

【每日一题】PCIe协议经常谈到的Memory-Mapped I/O究竟是啥？

昨天有观众看过《一文讲懂主机启动时是如何给每个PCIe外设分配BDF的》发邮件来询问，主机在启动过程中是BIOS给PCIe设备分配MMIO，自己研发的GPU芯片现在会出现MMIO资源分配不足这么一个问题。想问下MMIO的主要功能和工作机制，如何理解MMIO在PC…

作者头像 李华