MGR多主模式下事务冲突：写入失败及死锁问题排查解析

mysql MGR多主模式下，业务的写入突然大面积失败，应用连接池被打满，监控面板上闪过一片死锁告警。第一次经历这种故障的DBA，第一反应大概率是“集群坏了，数据会不会丢”。但排查一圈下来你会发现，这很可能不是节点宕机，而是MGR多主模式自身的冲突保护机制在正常工作，只是业务模型和它不匹配。

这篇内容来自某次真实运维复盘，场景是某模拟项目X使用MySQL 8.0.32搭建的三节点MGR多主集群，某个时间点业务侧开始持续报数据更新失败的故障。我会把现象、排查路径、根因定位、恢复过程和后续改造完整还原出来，重点讲清楚MGR多主模式下事务冲突到底是怎么发生的，为什么好好的update会被回滚，以及以后再遇到同类问题你该从哪里下手。适合正在运维MGR多主集群的DBA，以及后端开发里负责写数据层的同学参考。

1. MGR多主模式：先搞清楚这套机制怎么运作

1.1 单主与多主的本质区别

MGR是MySQL官方提供的高可用复制方案，底层基于Paxos共识协议，通过group replication插件管理成员、复制和自动故障转移。单主模式下，同一时间只有一个primary节点能接受写请求，其他成员自动变成只读，谁的primary由组内协议协商决定，客户端就算连到非primary节点，写操作也会被拒绝。

多主模式则放开了所有节点的写入权限。在配置里，group_replication_single_primary_mode设为OFF，配合group_replication_enforce_update_everywhere_checks设为ON，每个成员都能接收并执行写事务。表面看这是“多活”，但很多人会忽略一个关键点：MGR没有内置的写请求路由能力。一个事务从哪个节点进入，完全取决于应用连接的成员节点，两个不同节点完全可能同时写入同一行数据。

这个特性就埋下了冲突隐患。如果应用侧负载均衡把写流量随机分发到不同节点，而业务又恰好会更新同一批热点数据，多主模式就会频繁触发事务冲突。这和单主模式下“所有写都落在一个节点”的天然串行化完全不同，写模型的设计思路也必须跟着变。

1.2 多主模式下，一个事务从提交到复制要经过哪些关卡

在MGR多主节点上执行一个update，并不是简单地在本地完成就返回成功。事务执行分为两个阶段：本地事务引擎先完成SQL执行和加锁，然后通过Paxos协议把事务的binlog事件广播到group，由认证器（certifier）做全局冲突检测。只有认证通过，事务才会真正提交并在所有成员上最终生效。认证不通过，发起节点会直接回滚这个事务，客户端收到错误返回。

认证器判断冲突的依据是事务的读写集合（writeset）。每个事务的binlog事件里携带了完整的行级变更信息，认证器把当前事务的写集合与已认证事务的写集合做交集比对，如果发现都要修改同一行，那么后到的事务被拒绝。

这也是MGR强制要求binlog_format=ROW并且binlog_row_image=FULL的原因。只有完整的行映像才能构建准确的写集合，缺失任何一行变更信息，认证的可靠性都会打折扣。我在某个内部项目里试过把row_image改成minimal，MGR直接拒绝启动，日志明确提示配置不满足要求。

如果理解了这两个阶段，再回头看“数据不能更新”的报错，其实已经有了一半答案。剩下的一半，要看引发冲突的具体事务长什么样，以及节点间是否还有其他因素在干扰事务提交。

2. 故障现场：多主集群出现写不进、更新不了的链路

2.1 案例背景与业务形态

出问题的集群是三节点MGR，版本8.0.32，多主模式。业务侧是两个应用实例，分别配置连接到不同的MGR节点，共同维护一张热点库存表。这张库存表的主键是商品ID，扣减逻辑是典型的update stock set number = number - 1 where sku_id = ?。商品维度有热点属性，某些爆款SKU的同一行记录同时被两个应用实例高频更新。

平时的写入量并不算大，单节点每秒几百个事务，复制延迟也很低。但某个促销节点的流量上来之后，问题集中爆发了。第一波反馈是业务接口耗时飙升，紧接着应用日志开始出现异常，数据库端监控看到大量锁等待和死锁计数上涨。

2.2 客户端和应用侧看到的报错形态

业务日志里的报错主要有三类，我整理如下。

第一种是死锁错误，应用打印的堆栈信息能直接看到“Deadlock found when trying to get lock; try restarting transaction”。这种错误最容易被误判，因为从直觉上，两个节点都在执行同一个update语句，怎么会陷入物理死锁？后面细查会发现，一部分死锁是InnoDB真实的行锁死锁，另一部分则是MGR认证冲突时返回的等价错误。

第二种是锁等待超时，报错大概是“Lock wait timeout exceeded; try restarting transaction”。这类报错通常出现在某个事务持有大量行锁未释放时，另一个节点的事务被卡在行锁等待队列里，超过innodb_lock_wait_timeout后直接放弃。

第三种报错稍微隐蔽一点，客户端返回的错误消息是“The transaction was detected as a conflict and rolled back”，应用框架打印出来的SQL状态是HY000。这种报错不常见，但恰恰是最能说明MGR多主冲突的典型信号。

不管是哪种报错，业务侧的直观感受就是数据更新不了，某些接口反复超时，重试后依然失败。到了这一步，排查方向需要立刻从“应用代码是不是写错了”转向“集群的复制和认证链路是不是出问题了”。

2.3 初步排查：成员状态和复制通道先看哪里

第一件事是确认集群成员状态。执行：

SELECT * FROM performance_schema.replication_group_members\G

正常情况下所有成员的MEMBER_STATE都应该是ONLINE。这次排查发现三个节点全部ONLINE，成员没有异常退出，初步排除节点宕机。

第二步看事务冲突相关的计数器：

SELECT * FROM performance_schema.replication_group_member_stats\G

重点看两个字段：COUNT_TRANSACTIONS_ROWS_VALIDATING和COUNT_TRANSACTIONS_ROWS_IN_CONFLICT。前者代表认证阶段正在校验行数，后者代表触发冲突被拒绝的行数。平时这个集群的冲突行数基本是0，故障期间这个计数器在持续增长，这就说明MGR的认证器确实在拦截事务。

第三步去翻MySQL错误日志。多主冲突被回滚时，错误日志中会出现显眼的认证失败记录，我摘一段典型日志文本：

[ERROR] [MY-000000] Replica failed to initialize applier metadata structure from the repository [ERROR] [MY-010584] The transaction was detected as a conflict and rolled back: 44b1c7c9-...

虽然日志等级是ERROR，但它不代表数据损坏，相反它说明认证器拦截了冲突事务。看到这条日志之后，排查基本可以聚焦到“哪个事务冲突、为什么冲突”这个核心问题上。

3. 根因定位：为什么更新操作会被卡死或回滚

3.1 冲突认证回滚：多主模式下最常见的拦路虎

MGR多主模式的冲突认证是这套方案最核心、也最容易被低估的保护机制。如果完全理解了认证机制，就会发现很多“死锁”和“更新失败”本质上都是同一个原因：两个节点在同一时间区间内修改了同一行，后认证的事务被拒绝。

我画一个简化版的时序来说明过程。假设A节点和B节点同时执行这样一个SQL：

UPDATE stock SET number = number - 1 WHERE sku_id = 10086;

• 事务T1在A节点执行，获得本地行锁，执行成功。
• 事务T2在B节点执行，获得本地行锁，执行成功。
• T1先把binlog事件广播到group，认证器检查发现没有更早的冲突事务，放行。T1全局提交成功。
• T2随后广播到group，认证器发现T1已经修改了同一行，T2的写集合和T1产生交集，于是T2被拒绝并回滚。
• B节点上的客户端收到一个类似“conflict and rolled back”或死锁的错误，应用层重试后如果又分发到B节点，依然可能继续失败。

这里要特别注意：T2虽然在B节点本地执行SQL成功，但并没有真正全局提交，所谓的“本地执行成功”只是完成了SQL和锁操作。最终结果是T2在所有节点上都不存在，数据不会出现两节点各减一次的“超卖”情况。这是MGR一致性的底线。

但在业务层面，高频并发更新同一行时，这个机制就变成了一种“概率性写入失败”。促销流量把同一行更新分发到不同节点，失败率会直线上升。你看到的死锁告警，一部分是InnoDB物理死锁，另外一部分其实就是认证冲突。从客户端体验来看，两者都表现为“数据不能更新”。

3.2 隐式锁、外键锁与大事务放大了冲突面

多主冲突认证是根因，但现场还有几个因素放大了问题，排查时被逐一确认。

大事务是最明显的放大器。如果A节点有一个事务更新了几万行，事务还没提交，这些行锁在A节点上是真实持有的；同一个时间段内B节点更新了其中部分相同行，B节点的事务会在InnoDB层等待A节点释放行锁。等待时间一旦超过innodb_lock_wait_timeout，B节点就会直接报锁等待超时。这个问题的隐蔽之处在于：即使最终认证可能通过，业务也早在锁等待阶段失败了。

隐式锁是另一个容易忽略的坑。InnoDB对刚刚插入但未提交的行，默认不加显式锁，也就是所谓的隐式锁。如果另一个节点的事务要更新或删除这行数据，InnoDB需要把隐式锁转成显式锁，这个转换过程要扫描对应记录、判断锁对象是否存在。如果并发插入严重，锁转换会让处理时间暴涨。这种场景下最容易出现的报错不是死锁，而是锁等待超时和处理变慢。

外键约束在MGR多主下也容易被低估。当业务表存在父子表外键关系时，更新父表的一行，子表对应记录会被加共享锁；如果另一个节点在更新子表同一条记录，而父表行还在被持有锁，两个节点之间就可能出现互相等待。MGR认证器可以防止最终数据不一致，但InnoDB层的物理锁等待是不受认证保护的。项目里的库存表虽然没有外键，但同库的其他业务表有外键关联，所以排查时如果把思路局限在热点库存表本身，很容易漏掉真正阻塞事务的锁来源。

还有自增列的问题。多主模式要求所有节点的auto_increment配置错开，本质上是避免并发插入时生成重复主键。较老的MySQL 8.0版本曾出现过重启后自增值回退导致主键冲突的缺陷，一旦主键重复，事务同样无法提交，表现也是写入失败。这个因素在本次案例里不是主因，但排查写入类故障时值得列入清单。

3.3 流控和成员失联：另一种“不能更新”

事务冲突并非唯一会让更新失败的原因。MGR在节点落后或者认证队列积压时，还会启动流控（flow control）机制。流控的作用是让快的节点放慢节奏，等慢的节点赶上，本质上是防止复制差距无限拉大。

当某个节点因为磁盘变慢、网络抖动、大事务等原因落后过多，认证队列积压到高水位，MGR会对所有成员执行流控。此时客户端的写操作不会立刻报错，而是表现为延迟不断上升，事务提交被挂起，渐渐地业务方就会反馈“数据更新不了”。这个状态如果看成员状态，节点仍然是ONLINE，但性能指标会非常奇怪，提交延迟居高不下，复制延迟也在增长。

还有一种更极端的情况是网络分区导致quorum丢失。MGR依靠Paxos协议，必须维持多数派才能继续对外提供服务。当某个节点被隔离，剩余节点不满足多数派时，MGR会主动把全部成员切换为只读保护模式，此时任何写操作都会直接失败。有经验的DBA应该知道，MGR宁可牺牲可用性也要保证一致性，所以这种保护机制是设计预期。

本次案例中没有走到quorum丢失这一步，但压测过程中确实偶发出现过流控触发的写延迟飙升，和事务冲突叠加在一起，给问题定位增加了不少干扰。

3.4 把根因钉死的证据组合

后期复盘，我把不同症状对应的判断链路整理成了一张对照表，排查类似故障时可以直接对着查。

在这个项目里，症状是报错1213和超时混合出现，错误日志有conflict回滚记录，冲突计数器持续增长，最终把根因锁定在多节点并发认证冲突，同时大事务把锁等待问题放大。到这里，问题原因已经清楚了，接下来的动作是恢复服务和优化方案。

4. 解决过程与恢复步骤

4.1 先止血：临时把写流量集中到单节点

确认根因是冲突认证后，第一步不是改参数，而是立刻减少冲突面。最快的止血方式是在应用层把写流量切换到单一节点，让所有update落到同一个MGR成员上，把多主的并发写临时变成单主串行写。

这个操作不需要改动MGR配置，也不需要重启集群。当时我直接调整了应用连接池的路由策略，写操作固定使用同一个数据源。这样做的效果立竿见影，从切换完成开始，死锁报错和冲突计数立刻停止增长。

这里特别提醒一点：MGR的single_primary_mode属于创建group时的配置，不能在运行中直接动态切换。如果你没有应用层的写路由能力，临时止血只能选择停掉某个节点的接入，或者直接让应用只连一个成员，别指望一条SQL就能把多主改成单主。

4.2 数据一致性核查

虽然MGR认证机制会回滚冲突事务，理论上不会出现数据不一致，但线上故障恢复不能只靠理论。执行恢复前要对三个节点的数据做一次快速比对。

我没有用复杂的检查工具，只对热点表做了一轮主键维度的行数对比，再对几个关键表计算全表checksum。方法很朴素：分别在三节点执行同一张表的聚合查询，比较SUM结果。因为表的数据量不大，几分钟内就完成了对比。如果发现差异，处理方式是把异常节点从group里剔除，重新初始化后加回，让group以共识数据为准修复节点。

这次比对后三个节点结果一致，确认没有丢数据或重复扣减。MGR的冲突回滚机制在这一轮验证下来是可靠的。

4.3 根治方案：改造应用写入模型与集群配置

止血只是暂时的，根本问题在于业务模型违背了多主模式的使用边界。故障复盘后做了三块改造。

第一块是应用层改造。热点库存表的更新全部绑定到一个固定节点，同时把扣减逻辑从单行update重构成防冲突模型。具体做法有几种，可以选一种最适合业务形态的：一是把热点SKU的库存按数量拆分到多行，每次扣减随机选行或者轮询选行，把单行冲突变成多行均衡；二是在应用层引入分布式锁，让同一SKU的更新串行化；三是至少要做到事务失败后捕获死锁和冲突异常并进行有限次重试，重试时选择不同的可用节点，避免反复踢到同一块铁板。

我贴一段当时改造后的伪代码，思路很直接：

public boolean deductStock(String skuId, int number) { int retry = 0; while (retry < 3) { try { // 固定路由到持有该SKU库存分片的节点 return inventoryClient.deductOnFixedNode(skuId, number); } catch (DeadlockException | ConflictException e) { retry++; if (retry >= 3) { throw new BizException("库存扣减失败，请重试"); } // 短暂退避后重试 Thread.sleep(20L * retry); } } return false; }

重试不能无休止，否则故障期间会把数据库打到更惨。所以重试次数限制在3次以内，退避时间递增，让数据库有喘息空间。

第二块是事务模型改造。严禁在MGR多主节点上执行大批量update，比如一次update几万行这种操作必须拆分成小批次，每批几百行并控制事务时长。大事务除了放大锁竞争，还会拖慢认证队列，进而触发流控，属于双倍杀伤。

第三块是集群参数调整。innodb_lock_wait_timeout从默认的50秒下调到10秒，宁可让事务快速失败，也不要让锁等待堆积。group_replication_transaction_size_limit保持默认值，不因为业务需要就盲目调大，事务越大，认证冲突影响范围越大。流控机制保留默认开启，关掉流控等于在集群不稳定时去掉保护层，不到万不得已不要动。

这些调整之后，相同的促销流量再压进来，死锁和冲突计数都维持在个位数，数据更新不再出现大面积失败。

5. 这套故障留下的避坑清单

5.1 排查步骤速查表

再遇到MGR多主写入类故障，按这个顺序排查能少走弯路。

1. 先看replication_group_members，确认节点状态是否全部ONLINE。
2. 再看replication_group_member_stats，盯着CONFLICT计数是否在增长。
3. 翻错误日志，搜conflict和rolled back关键字。
4. 执行SHOW ENGINE INNODB STATUS，看LATEST DETECTED DEADLOCK和锁等待链。
5. 检查复制延迟和apply状态，排除流控场景。
6. 拉业务侧的报错SQL，分析事务大小和热点度。
7. 结合所有信息判断是认证冲突、锁冲突还是流控保护。

这个顺序也对应了故障影响范围从小到大的排查逻辑，先看集群自身，再看复制链路，最后看业务写入模型。

5.2 长期监控与告警要点

监控指标如果只选三个，我会选成员状态、冲突计数和复制延迟。成员状态不是ONLINE的要立刻告警；冲突计数器在正常业务下应该长期处于低位，一旦出现持续增长就要引起警觉，这往往是业务模型和多主模式冲突的前兆。

复制延迟这个指标需要结合业务容忍度设置告警阈值。MGR集群里单节点落后超过30秒，已经足够触发流控，再拖下去写延迟就会受影响。错误日志里可以增加对“conflict”和“rolled back”关键字的实时告警，有日志就报，不要等业务投诉。

另外建议定期做一次热点SQL审计。哪些SQL的高频执行集中在同一个表同一行，哪些update在高峰期跨节点被执行，这些信息通过审计日志或者慢查询日志都能分析出来。提前发现反模式，远比故障后再排查省力。

5.3 多主模式下写代码的纪律

这次故障之后，我把多主模式的写入纪律总结为几条硬性规则，贴在了团队的技术文档里。

第一，永远不要假设更新同一行会成功。MGR多主模式下，同一行高频更新必然伴随概率性失败，应用层必须做好冲突异常捕获和重试，这不是可选项，是必选项。

第二，大事务是原罪。多主模式下的大事务不仅会锁住自己的节点，还会拖累认证队列，间接影响所有节点。写操作尽量拆小，一个事务里不要塞太多行。

第三，热点数据要有意识地分散。库存、余额这类热点数据，如果按一行的方式存储，多主天然不适合；把热点拆行、分桶，才能发挥多节点的并行能力。

第四，外键在MGR多主场景下要特别谨慎。父子表关联更新会放大锁定范围，能去掉外键就尽量在应用层保证完整性，不能去掉就要特别注意跨节点的父子表并发更新。

第五，不要试图通过关掉流控来解决问题。流控是MGR的最后一道保护闸，看着像是制造了延迟，实际上它在阻止系统彻底崩掉。

写在最后

回到标题里的故障：MGR多主数据不能更新，很多时候不是集群坏了，恰恰是它在努力保护集群的一致性。冲突认证回滚是设计预期，不是程序BUG。这次的3354个字的经验里，我最想传递的一点是：多主模式的写入纪律比高可用能力本身更值得花时间。

如果你正在评估MGR方案，先问业务一个问题：同一行数据会不会被多个节点同时写入？如果是，老老实实单主；如果应用层能保证同一数据域的写操作绑定到同一节点，多主才有意义。官方文档里关于多主模式的限制写得清清楚楚，但只有真正被故障锤过一次，才会刻进脑子里。

最后再分享一个小技巧：排查MGR多主故障时，优先看performance_schema里的冲突计数器，它就像车里的仪表盘，数据不会说谎。大多数更新失败的根因，都能从计数器曲线里找到答案。