春节运维保障期间，突发告警打破了平静——我们一套MySQL 8.0.27 InnoDB Cluster（三节点单主模式），其中一个备节点异常离线，集群状态降级为“无法容忍任何故障”。好在提前部署了MySQL Router，集群对外服务未受影响，但作为DBA，必须深挖根因,其中涉及的原理，也和大家掰开揉碎了的讲一讲，聊一聊。
本文将完整还原本次故障的排查、修复全过程，重点解答4个核心问题：
① InnoDB Cluster同步原理是什么？
② 本次节点异常的核心根因的是什么？
③ 现有处置流程是否得当？
④ 如何从根本上规避此类问题？全程贴合MySQL 8.0.27版本特性，干货满满，建议收藏备用。欢迎大家扫码关注我的微信公众号，一起探讨解决方案。
此次我们数据库的部署架构是参考官方MySQL innodb cluster架构,如图所示：
一、故障概述
春节期间，监控平台触发MySQL集群告警，提示“集群节点异常，容错能力降级”。登录集群排查后发现，三节点InnoDB Cluster（单主模式，主库123.123.123.3:263307，备库123.123.123.4:263307、123.123.123.5:263307）中，备库123.123.123.4节点状态异常，已退出集群。
因集群部署了MySQL Router中间件，实现了请求自动路由，异常节点退出后，所有读写请求自动切换到正常节点，未对业务造成影响。我们立即启动故障排查与修复，全程记录过程并复盘优化。
二、故障现象：精准捕捉集群异常信号
故障排查遵循“先看集群状态→再查系统表→最后分析日志”的顺序，快速锁定异常节点及初步诱因，具体现象如下：
集群状态异常（核心现象）
使用MySQL Shell连接主库，执行cluster.status()查询集群状态，发现关键异常信息：
MySQL 123.123.123.3:263307 ssl JS > cluster.status()
{
"clusterName": "publiccluster",
"defaultReplicaSet": {
"name": "default",
"primary": "123.123.123.3:263307",
"ssl": "REQUIRED",
"status": "OK_NO_TOLERANCE", // 无法容忍任何故障
"statusText": "Cluster is NOT tolerant to any failures. 1 member is not active.",
"topology": {
"123.123.123.3:263307": { // 主库正常
"address": "123.123.123.3:263307",
"memberRole": "PRIMARY",
"mode": "R/W",
"status": "ONLINE",
"version": "8.0.27"
},
"123.123.123.4:263307": { // 异常节点
"address": "123.123.123.4:263307",
"instanceErrors": [
"ERROR: GR Applier channel applier stopped with an error: Worker 1 failed executing transaction '14084c9e-8a0b-11ef-a209-fa163ee79d39:18899270'; Deadlock found when trying to get lock; try restarting transaction (1213)",
"ERROR: group_replication has stopped with an error."
],
"memberRole": "SECONDARY",
"memberState": "ERROR",
"status": "(MISSING)", // 节点缺失
"version": "8.0.27"
},
"123.123.123.5:263307": { // 另一个备库正常
"address": "123.123.123.5:263307",
"memberRole": "SECONDARY",
"mode": "R/O",
"status": "ONLINE",
"version": "8.0.27"
}
},
"topologyMode": "Single-Primary" // 单主模式
},
"groupInformationSourceMember": "123.123.123.3:263307"
}关键结论：集群状态降级为OK_NO_TOLERANCE，123.123.123.4节点因Group Replication（简称MGR）异常停止，处于MISSING状态，核心报错为“死锁（1213）”。
系统表验证异常
查询performance_schema.replication_group_members（MGR节点状态表），进一步确认异常：
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | acabe598-931b-14ec-804c-fa163e157f0c | 123.123.123.4 | 263307 | ERROR | | 8.0.27 | XCom |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+正常情况下，会显示3个节点，且MEMBER_STATE均为ONLINE；此处仅显示异常节点，且状态为ERROR，说明节点已退出集群。
补充：单主模式下，MySQL Router会自动屏蔽异常节点，将读写请求路由到主库和正常备库，因此业务未受影响——这也是InnoDB Cluster高可用的核心优势之一。
异常节点日志解析（根因关键线索）
登录123.123.123.4节点，查看MySQL错误日志，筛选出两个关键时间点的核心报错，还原故障全过程：
（1）2026-02-14 凌晨四点初始故障：死锁导致MGR停止、节点退出
2026-02-14T04:26:23.232175+08:00 15 [Warning] [MY-010584] [Repl] Slave SQL for channel 'group_replication_applier': Worker 2 failed executing transaction '14084c9e-8a0b-11ef-a209-fa163ee79d39:18899270'; Could not execute Write_rows event on table xxx_db.xx_part; Deadlock found when trying to get lock; try restarting transaction, Error_code: 1213
2026-02-14T04:26:23.232247+08:00 15 [ERROR] [MY-010584] [Repl] Slave SQL for channel 'group_replication_applier': worker thread retried transaction 10 time(s) in vain, giving up. Consider raising the value of the replica_transaction_retries variable.
2026-02-14T04:26:23.319239+08:00 13 [ERROR] [MY-011451] [Repl] Plugin group_replication reported: 'The applier thread execution was aborted. Unable to process more transactions, this member will now leave the group.'
2026-02-14T04:26:23.390847+08:00 11 [ERROR] [MY-011712] [Repl] Plugin group_replication reported: 'The server was automatically set into read only mode after an error was detected.'
（2）2026-02-14 八点衍生故障：克隆恢复时因super-read-only失败
2026-02-14T08:40:30.810963+08:00 27 [Note] [MY-011977] [InnoDB] Clone: Failed to DROP TABLE `mysql_innodb_cluster_metadata`.`clustersets` task: 0 code: 1290: The MySQL server is running with the --super-read-only option so it cannot execute this statement
2026-02-14T08:40:30.845978+08:00 27 [ERROR] [MY-011569] [Repl] Plugin group_replication reported: 'Internal query: CLONE INSTANCE FROM ... result in error. Error number: 1290'
2026-02-14T08:40:30.846258+08:00 26 [ERROR] [MY-013473] [Repl] Plugin group_replication reported: 'Due to a critical cloning error ... distributed recovery cannot be executed. The member will now leave the group.'
日志关键信息已标注，后续将结合这些线索，拆解故障根因。
三、根因定位：从死锁到克隆失败，拆解完整连锁反应
结合故障现象和日志分析，本次故障并非单一原因，而是“初始故障→衍生故障”的连锁反应，核心根因分两层，全程贴合MySQL 8.0.27版本特性，精准定位每一步异常的本质：
初始根因（节点退出的核心）：备库应用事务死锁，重试耗尽致MGR停止
这是本次故障的源头，核心逻辑的是：
- 死锁触发
：备库（123.123.123.4）的MGR Applier线程（负责应用主库同步的事务），在执行Write_rows事件（写入xxx_db.xx_part表）时，发生InnoDB死锁（Error 1213）。死锁的本质是：备库并行应用事务时，多个Worker线程争夺同一资源（表锁/行锁），导致互相阻塞。 - 重试耗尽
：MySQL 8.0.27默认replica_transaction_retries = 10（备库事务重试次数），该死锁事务重试10次后仍未成功，Applier线程直接停止工作。 - 节点退出
：MGR对集群一致性要求极高，一旦检测到Applier线程异常（无法继续应用事务），会判定“该节点数据可能与集群不一致”，为保护集群安全，会自动将该节点踢出集群，并设置super-read-only = ON（禁止任何写操作，防止数据错乱）。
衍生根因（克隆失败的核心）：super-read-only未关闭，阻碍Clone插件清理数据
节点退出后，尝试通过“克隆（Clone）”恢复数据并重新加入集群时，出现新的异常，原因是：
- Clone插件的前置操作
：MySQL 8.0的Clone插件（用于快速同步集群数据），在从主库克隆数据前，需要先清理目标节点（异常节点）的现有数据，包括mysql_innodb_cluster_metadata（集群元数据表）。 - super-read-only的阻碍
：异常节点因初始故障，仍处于super-read-only = ON模式（MGR自动设置），无法执行DROP TABLE等写操作，导致Clone插件清理数据失败，克隆任务报错（Error 1290），节点无法重新加入集群。
总结根因本次故障的核心是：备库应用事务死锁（初始诱因）→ 重试次数不足导致MGR停止、节点退出→ super-read-only未关闭导致克隆失败（衍生问题），本质是“参数配置不合理+故障处置不细致”导致的连锁反应。
四、处置流程校验与优化：原有做法可行，补充细节更稳妥
当时要过年了，想着快速恢复，我的处置流程（剔除异常节点→重置节点→克隆重新加入）整体合理，符合MySQL 8.0.27 InnoDB Cluster的故障处理规范，但后面思考仍然存在3个细节优化点，优化后可减少衍生问题、提升恢复效率，优化后的完整处置流程如下（保留原有核心步骤，补充注意事项）：
优化后处置流程（可直接复用）
步骤1：登录异常节点，重置MGR并关闭super-read-only（新增优化）
-- 登录异常节点（123.123.123.4:263307）
mysql -uixxx -p -P263307 -h123.123.123.4
-- 1. 停止MGR同步（原有步骤，保留）
STOP GROUP_REPLICATION;
-- 2. 重置复制配置，清理GTID和复制通道（原有步骤，保留）
RESET SLAVE ALL;
RESET MASTER;
-- 3. 新增：临时关闭super-read-only，避免克隆时无法清理数据
SET GLOBAL super_read_only = OFF;
-- 可选：确认状态，确保关闭成功
SHOW VARIABLES LIKE 'super_read_only';步骤2：从集群中强制剔除异常节点
-- 1. 使用MySQL Shell连接主库（123.123.123.3:263307）
mysqlsh --uri=ixx@123.123.123.3:263307
-- 2. 获取集群对象（原有步骤，保留）
var cluster = dba.getCluster('publiccluster');
-- 3. 强制剔除异常节点（原有步骤，保留）
-- force: true 作用：即使节点处于MISSING/ERROR状态，也能强制剔除
cluster.removeInstance('icxxx@123.123.123.4:263307',{force: true});
步骤3：通过克隆重新加入集群
-- 加入集群，指定两个关键参数（原有步骤，保留）
-- memberWeight: 节点权重（40，用于主库切换时的投票权重）
-- recoveryMethod: 恢复方式（clone，适合数据量不大、快速同步场景）
cluster.addInstance('ixxx@123.123.123.4:263307',{
memberWeight:40,
recoveryMethod:'clone'
})补充说明：克隆过程中，MySQL会自动重启异常节点，用于加载克隆的数据，若出现“超时（Timeout waiting for server to restart）”，属于正常现象，手动启动节点即可。
步骤4：处理克隆超时，完成集群恢复（原有步骤，保留）
-- 1. 手动启动异常节点的MySQL实例（操作系统层面）
systemctl start mysqld # 或对应你的启动命令
-- 2. 回到MySQL Shell（主库连接状态），重新扫描集群，完成恢复
cluster.rescan();
-- 3. 验证集群状态，确认恢复正常（原有步骤，保留）
cluster.status();
-- 正常结果：集群status为OK，3个节点均为ONLINE，GAP_STATUS为NO GAP处置流程合理性校验
合理之处：核心思路“剔除→重置→克隆→重新加入”，完全符合InnoDB Cluster故障处理逻辑，尤其适合“节点数据与集群差异过大、无法通过Binlog回放同步”的场景（本次因死锁导致事务缺失，克隆是最优选择）。
优化点（原有做法的不足）：
- 未关闭super-read-only
：导致克隆时清理数据失败，浪费恢复时间； - 未尝试轻量修复
：直接克隆属于“重度修复”，可先尝试“跳过死锁事务”的轻量方式，减少恢复时间（下文复盘会详细说）； - 未验证克隆前的节点配置
：未确认异常节点的MySQL配置（如端口、SSL）与集群一致，虽本次未出问题，但存在隐患。
五、核心解析：MySQL InnoDB Cluster（8.0.27）同步原理解析
很多DBA在处理InnoDB Cluster故障时，容易陷入“只懂操作，不懂原理”的误区，结合本次故障，用通俗的语言拆解8.0.27版本InnoDB Cluster的同步核心——Group Replication（组复制） + Clone插件，让你彻底搞懂“数据如何同步”“节点为何会退出”。如下图：
1. 核心同步组件：Group Replication（MGR）
InnoDB Cluster的高可用和数据同步，完全依赖MGR实现，单主模式下（本次集群模式），同步流程分为3步，核心遵循Paxos协议（保证集群节点数据一致性）：
- 主库事务执行与认证
：主库（123.123.123.3）执行用户事务，写入Binlog后，会将事务信息（如SQL语句、GTID）发送到MGR的“认证层”；认证层会校验该事务是否会导致集群数据不一致（如主键冲突），校验通过后，向所有备库广播该事务。 - 事务日志传输
：所有备库（包括异常节点）接收主库广播的事务日志，写入本地Relaylog（中继日志）；同时，备库会向主库反馈“日志接收成功”，确保日志传输不丢失。 - 备库事务应用
：备库的Applier线程（可多线程并行，8.0默认开启）从Relaylog中读取事务，逐一对本地数据执行相同操作，确保备库数据与主库完全一致；应用完成后，备库标记该事务“应用成功”。
关键补充：MGR要求“集群中超过半数节点正常”，否则集群无法提供写服务（本次3节点，1个异常，剩余2个正常，满足半数要求，因此主库可正常提供写服务）。
2. 数据快速恢复组件：Clone插件
当节点数据与集群差异过大（如本次异常节点缺失大量事务），仅靠Binlog回放同步效率极低，此时Clone插件就会发挥作用：
- 作用
：从集群中健康节点（Donor，本次为主库123.123.123.3），完整复制“数据文件+元数据+日志文件”到目标节点（Joiner，本次为异常节点），相当于“快速克隆一个与健康节点完全一致的副本”。 - 优势
：无需手动备份、恢复数据，MySQL自动完成，比传统“备份+恢复”效率高10倍以上，适合大数据量场景。 - 注意
：Clone插件执行前，会自动清理目标节点的现有数据，因此需要目标节点关闭super-read-only（允许写操作）。
3. 结合本次故障，理解同步异常的本质
本次故障中，备库Applier线程因死锁无法应用事务，导致“同步流程第三步中断”；MGR为保护集群一致性，直接将该节点踢出集群——本质是“同步流程中断→集群一致性受到威胁→节点被剔除”的保护机制。如下是innodb cluster官方架构图。
六、故障复盘：现有做法的改进点，下次少踩坑
本次故障恢复成功，但复盘整个流程，有4个可改进的细节，既能减少故障恢复时间，也能降低同类故障的发生概率，尤其适合春节、节假日等运维保障关键期：
改进点1：初始故障时，优先尝试“轻量修复”，而非直接克隆
原有做法直接克隆，属于“重度修复”，耗时较长；若节点仅因“死锁事务重试耗尽”退出，可先尝试“跳过死锁事务”的轻量方式，快速恢复节点，步骤如下（谨慎操作，需确认事务无影响）：
1. 登录异常节点，查看卡住的事务GTID（死锁事务）
SELECT * FROM performance_schema.replication_applier_status_by_worker;
-- 找到对应的GTID：14084c9e-8a0b-11ef-a209-fa163ee79d39:18899270
2. 临时设置跳过该GTID（仅适用于非核心事务，或主库已执行成功的事务）
SET GLOBAL group_replication_gtid_assignment_block_size = 1;
SET GTID_NEXT = '14084c9e-8a0b-11ef-a209-fa163ee79d39:18899270';
BEGIN; COMMIT; -- 空提交，跳过该事务
SET GTID_NEXT = 'AUTOMATIC'; -- 恢复自动应用事务
3. 重启MGR，尝试重新加入集群
START GROUP_REPLICATION;
4. 回到主库，查看节点是否自动重新加入
cluster.status();注意：跳过事务前，需确认该事务在主库已执行成功，且不会导致备库数据不一致（如非核心业务的临时写入）；若为核心事务，需手动补全数据后再跳过。
改进点2：处置前，先检查并关闭super-read-only
原有做法中，未关闭异常节点的super-read-only，导致克隆失败，浪费恢复时间；建议将“检查并关闭super-read-only”作为“重置节点”的必做步骤，写入运维手册，避免遗漏。
改进点3：优化参数配置，从源头减少死锁和节点退出概率
本次故障的初始诱因是“死锁重试次数不足”，可通过调整MySQL参数，从源头规避，适配8.0.27版本的参数配置如下：
1. 增加备库事务重试次数（从默认10次调整为30次），给死锁更多自动解决的时间
replica_transaction_retries = 30
2. 优化备库并行应用线程数（根据CPU核心数调整，如8核CPU设为8），减少并行应用导致的死锁
slave_parallel_workers = 8
slave_parallel_type = LOGICAL_CLOCK # 基于事务逻辑时间戳并行，减少锁冲突
3. 开启死锁日志，方便后续排查（新增）
innodb_print_all_deadlocks = ON
4. 持久化配置，重启MySQL后生效（my.cnf或my.ini中添加）改进点4：完善监控告警，提前预警异常，避免故障扩大
本次故障中，节点退出后才收到告警，未提前发现“死锁重试次数过高”的隐患；建议新增以下监控指标，接入企业微信/钉钉，实现提前预警：
- MGR节点状态
监控performance_schema.replication_group_members.MEMBER_STATE，非ONLINE状态立即告警； - Applier线程状态
监控performance_schema.replication_applier_status_by_worker，出现错误或重试次数>5次告警； - 死锁次数
监控SHOW ENGINE INNODB STATUS中的死锁计数，每小时死锁次数>3次告警； - super-read-only状态
异常节点开启super-read-only后，立即告警（提示可能影响克隆恢复）。
七、根本规避方案：从参数、监控、架构，全方位杜绝同类故障
复盘改进是为了避免再犯，结合本次故障，从“参数优化、监控完善、架构规范”三个层面，给出可落地的根本规避方案，适配MySQL 8.0.27 InnoDB Cluster：
1. 参数优化（核心，从源头规避）
除了上文提到的参数，补充2个关键参数，进一步提升集群稳定性：
1. 延长MGR节点超时时间（默认5秒，调整为15秒），避免网络抖动导致节点误退出
group_replication_member_expel_timeout = 15
2. 开启MGR自动重新加入（异常节点恢复后，自动尝试重新加入集群）
group_replication_autorejoin_tries = 3 # 最多尝试3次，每次间隔5秒2. 监控完善（提前预警，快速响应）
整合所有监控指标，形成“异常预警→故障定位→快速处置”的闭环：
- 告警优先级
节点退出（P1）> Applier线程异常（P2）> 死锁次数过高（P3）> super-read-only开启（P3）； - 告警内容
明确标注“异常节点IP+端口+核心报错+处置建议”，方便运维人员快速响应； - 定期巡检
每周检查一次集群状态、参数配置、日志，提前发现隐患（如死锁日志增多、节点权重异常）。
3. 架构与操作规范（减少人为失误和故障诱因）
- 表结构优化
对xxx_db.xx_part这类频繁写入的表，优化索引设计（避免全表扫描导致锁范围过大），减少死锁概率； - 事务规范
主库执行的事务，尽量“小而快”，避免长事务（持有锁时间过长，增加备库并行应用的死锁风险）； - 处置规范
将“异常节点处置流程”（轻量修复→重度修复）写入运维手册，明确“跳过事务”“克隆恢复”的适用场景，避免人为失误； - 冗余保障
三节点集群中，确保每个节点的配置（MySQL版本、参数、磁盘空间）一致，避免因配置差异导致的同步异常。
八、故障总结
本次MySQL 8.0.27 InnoDB Cluster故障，看似是“死锁”引发的小问题，实则暴露了“参数配置不合理、处置流程不细致、监控不完善”的短板。作为DBA，我们处理故障的核心，不仅是“快速恢复业务”，更要“深挖根因、复盘改进、建立防护”，避免同类故障重复发生。
核心启示：
InnoDB Cluster的MGR组件，是一把“双刃剑”——既保障了数据一致性，也对“事务应用异常”极为敏感，需通过参数优化，降低节点误退出概率；
故障处置需“先轻量、后重度”，优先尝试跳过事务、重启MGR等轻量操作，减少恢复时间；
节假日运维保障，重点在于“提前预警”，完善的监控体系，能让我们在故障扩大前，快速介入处置。
最后，如果你在运维MySQL InnoDB Cluster时，也遇到过MGR异常、节点退出、克隆失败等问题，欢迎在评论区留言交流，一起探讨解决方案，少踩坑、提效率！
同时也欢迎大家扫码入技术分享群，和我们一起学习进步，快快扫描如上二维码吧！
