MySQL Galera集群的核心特点是多个节点可以同时接受写入，并且任何节点上的提交都会被同步到组内其他节点。这种能力并不是通过将事务日志异步复制到从库实现的，而是把事务提交过程本身扩展成了一次组通信。当一个事务在某个节点上执行到提交阶段时，节点会把该事务产生的所有行变更打包成一个写集，广播给集群中的其他成员。其他成员在收到写集后，会先进行冲突检测，确认没有与本地正在并发提交的事务冲突，然后决定应用或回滚。
写集复制与认证流程
Galera同步的最小单位是事务的写集（Write Set），它记录了事务修改了哪些行、修改前后的值以及主键信息。写集不包含SQL语句本身，而是基于行的变更描述。这样做的好处是各节点可以独立应用写集，避免解析SQL带来的不确定性。例如一条UPDATE语句可能修改多行，写集就会包含每一行的主键和变更后的列值。节点在事务提交前，写集会被发送到组通信层，由组通信层保证所有节点接收到完全一致的写集顺序。
组通信层采用类似Paxos的协议来保证消息的全序投递。所有节点看到的写集顺序完全相同，这是认证和冲突检测的基础。当一个节点收到写集后，会将其放入本地队列，然后进入认证阶段。认证的核心是检查写集涉及的键是否与本地正在提交或已经提交但尚未应用的键冲突。如果冲突，则根据事务的优先级和序列号决定是继续应用还是回滚。
全局事务ID（GTID）在认证中扮演关键角色。每个写集都带有一个全局唯一的序列号（seqno），组内节点根据序列号判断事务的先后顺序。认证时，如果发现本地有一个序列号更小但修改了相同键的事务尚未完成，那么当前写集就会被判定为冲突，提交会被拒绝，客户端会收到死锁错误。这种机制使得Galera在并发写入相同数据时能够保持一致性，避免了主从复制场景下常见的更新丢失问题。
SHOW STATUS LIKE 'wsrep_last_committed'; SHOW STATUS LIKE 'wsrep_local_recv_queue_avg';
以上两条状态变量分别显示最后提交的全局事务序列号和本地接收队列的平均长度，是排查同步延迟和冲突的重要指标。
多主写入与冲突处理
传统主从复制要求所有写入都必须在主库上执行，从库只读。Galera打破了这种限制，每个节点都可写，但多主写入带来的挑战是同一个键可能在不同节点上被同时修改。Galera的冲突处理基于乐观并发控制：事务在本地执行时并不加锁，而是在提交时进行冲突检测。如果两个节点同时修改同一行，两个事务在各自节点都能完成执行，但只有一个事务的写集能够通过认证，另一个会被回滚。
回滚对于应用程序来说表现为提交失败，错误码通常为 1213（死锁）。应用程序需要捕获这个错误并重试事务。这种行为要求使用Galera的应用程序具备幂等或可重试的逻辑，否则可能因为自动回滚导致业务数据不完整。为了避免频繁冲突，设计表结构时应尽量让写入分散到不同的行和索引，减少热点更新。
有时我们希望某些节点不参与写入，例如只读副本。可以通过参数wsrep_on和read_only来控制节点是否接收客户端写入。需要注意的是，即使节点被设置为只读，它仍然会应用来自其他节点的写集，以保证数据一致。认证冲突的处理策略还可以通过wsrep_provider_options中的certification相关参数调整，但通常默认行为已经足够。
SET GLOBAL read_only=ON; SET GLOBAL wsrep_on=OFF;
上面的配置可以把节点临时切换为纯复制节点，用于执行备份或维护操作。
流控机制与性能调优
Galera强一致性的代价之一是节点间的同步延迟会被放大。如果某个节点处理写集的速度跟不上其他节点，接收队列会不断增长，最终拖慢整个集群。为了防止这种情况，Galera引入了流控机制（Flow Control）。流控会根据节点的接收队列长度动态调整写入节点的吞吐量，当队列超过阈值时，节点会暂停处理新事务，直到队列被消化。
流控的关键参数定义在wsrep_provider_options中，包括gcs.fc_limit、gcs.fc_factor和gcs.fc_master_slave。其中gcs.fc_limit表示触发流控的队列长度阈值，gcs.fc_factor是阈值调整因子。默认情况下，gcs.fc_limit为16，gcs.fc_factor为0.5。当队列长度超过16时开始流控，直到队列降到8以下才恢复。这些值可以根据集群规模和硬件性能调整，但调整不当可能导致频繁流控或者节点落后过多。
SET GLOBAL wsrep_provider_options='gcs.fc_limit=32'; SET GLOBAL wsrep_provider_options='gcs.fc_factor=0.8';
除了直接修改参数，还可以通过监控状态变量来观察流控是否频繁发生。例如wsrep_flow_control_paused_ns表示流控暂停的总纳秒数，wsrep_local_recv_queue_avg表示本地接收队列平均长度。如果流控发生非常频繁，说明集群中至少有一个节点性能不足，需要考虑升级硬件或者减少该节点的负载。
另一个影响性能的因素是事务大小。大事务会产生巨大的写集，不仅增加网络传输负担，还会让认证和流控压力急剧上升。Galera建议将事务控制在合理范围内，避免在一个事务中修改数万行。可以通过批处理拆分大事务，或者使用异步执行框架分散负载。
部署要点与监控指标
在部署Galera集群时，网络质量是首要考虑因素。因为写集必须实时广播到所有节点，网络延迟和丢包会直接影响提交性能。建议使用低延迟的专用网络，避免跨地域部署多主节点。节点数量通常为3个以上，以保证选举和容错能力。如果只有两个节点，一旦其中一个失败，另一个节点可能无法形成法定人数，集群将不可用。
监控Galera集群需要关注以下几个维度：节点状态（wsrep_cluster_status）、集群成员数（wsrep_cluster_size）、本地接收队列（wsrep_local_recv_queue_avg）、流控暂停时间（wsrep_flow_control_paused_ns）以及认证失败次数。这些指标能够帮助快速定位是网络问题、冲突过多还是节点性能瓶颈。
SELECT * FROM performance_schema.replication_group_members; SHOW STATUS LIKE 'wsrep_cluster_size';
通过定期采集这些状态变量并绘制趋势图，可以在问题扩大之前发现异常。例如wsrep_local_recv_queue_avg持续大于0，说明集群存在同步延迟，需要检查流控设置或者硬件资源。认证失败频繁时，应分析业务写入模式，减少对相同键的并发更新。
MySQL Galera多主集群同步机制修改时间：2026-10-05 04:09:32