主从复制解决了读扩展和基础高可用问题，但它的本质还是单主写入，存在切换时的停机窗口和可能出现的数据不一致。当业务对数据强一致性和写入高可用有更高要求时，多主集群就进入了视野。在 MySQL 生态中，Galera Cluster 和它的知名发行版 Percona XtraDB Cluster（PXC） 是应用最广泛的方案。
20.2.1 多主集群解决了什么问题
传统主从架构下，所有写入都压在主库上，一旦主库故障，需要切换到从库，这个过程即使自动，通常也伴随着几十秒到几分钟的不可用。而多主集群的核心价值在于：任意节点都可以读写，任一节点失效不影响整体可用性，数据在节点间实时同步且强一致。
Galera 集群并不是 MySQL 官方原生的功能，而是一个独立的复制插件，它工作在 InnoDB 存储引擎之下，通过拦截事务的提交过程，将写集（Write-set）同步到所有节点并进行全局排序和认证，从而实现多主同步复制。
20.2.2 Galera Cluster 的核心原理
Galera 基于 同步复制 和 乐观并发控制，工作流程大致如下：
- 客户端提交事务：应用向集群中某个节点发送
COMMIT。 - 生成写集（Write-set）：节点在事务提交前，将本次修改涉及的行捕获为写集，这是一个包含所有变更行键值的集合。
- 全局排序与分发：写集被广播给集群中的所有其他节点，并附带一个全局事务 ID（GTID）。
- 认证（Certification）：每个节点在自己的队列中检查是否有冲突（即是否有其他并发事务修改了相同的行）。如果没有冲突，则该事务可以提交；如果有冲突，则后到达的事务会被回滚，应用端会收到死锁错误，需要重试。
- 提交与应用：认证通过后，各节点写入自己的数据文件并返回提交成功。
整个过程中，数据在节点间传输的是写集而非完整的 binlog 事件，这比传统复制更为轻量。而且因为数据在提交前已经完成同步，读哪个节点都能获得已提交的一致性数据。
20.2.3 PXC 与 Galera 的关系
Galera Cluster 是技术底层，由 Codership 公司开发，是一个通用的 MySQL 集群插件。
Percona XtraDB Cluster（PXC） 是 Percona 公司打包的发行版，它将 Galera 插件与 Percona Server（一个增强版的 MySQL 分支）深度集成，并附带了一系列运维工具（如 pxc_scheduler_handler）、监控模板和文档。对用户来说，PXC 就是一个开箱即用的多主集群解决方案，下载解压就能配置运行，不需要单独去编译 Galera。
此外还有 MariaDB Galera Cluster，逻辑与 PXC 相同，只是底层服务器换成了 MariaDB。三者在原理上完全一致，选型时可以认为 PXC 更贴近社区版 MySQL 使用习惯。
20.2.4 多主集群的核心优势
- 多主写入，横向扩展写入能力：所有节点都可以写入，不需要分库分表即可部分缓解写入压力。一般建议 3 个节点，奇数个便于选举。
- 数据强一致性：基于同步复制和写集验证，节点间数据真正实时一致，不会出现主从延迟导致读到旧数据的问题。
- 自动故障切换，RPO＝0：任一节点宕机，集群自动将其剔除，其他节点照常工作，数据零丢失（已提交的事务都在其他节点）。
- 无脑数据修复：故障节点恢复后，会自动从其他节点同步缺失的数据（SST 状态传输或 IST 增量传输），无需人工介入。
20.2.5 必须正视的限制与成本
多主集群强大，但不是万能，选择它意味着接受一些硬性约束：
- 只支持 InnoDB 引擎：Galera 只复制 InnoDB 表，MyISAM、Memory 等引擎的数据会被忽略。
- 所有表必须有主键：写集认证依赖主键或唯一键来检测冲突，缺主键的表会导致性能问题甚至复制错误。
- 写入延迟会放大：一个事务的提交速度取决于最慢的那个节点。因为需要等所有节点认证完成，所以网络延迟对性能影响巨大。通常要求节点间网络延迟 < 1ms，最好是同机房部署。
- 冲突处理是事后重试：当多个节点同时修改同一行时，最后提交的那个会失败并回滚，应用必须承接这种报错并重试。这和单机 MySQL 的行锁等待体验完全不同，对应用程序有侵入性。
- 大规模写入吞吐不及分库分表：因为所有节点都要处理全部写入集，整体写入能力约等于单节点性能的 80% 左右，不能无限水平扩展。如果写入量巨大，分库分表依然是最终解。
20.2.6 集群搭建要点与实操建议
以 PXC 三节点集群为例，关键配置包括：
[mysqld]
# 启用 PXC 集成
default_storage_engine=InnoDB
binlog_format=ROW
# Galera 库（所有节点一致）
wsrep_provider=/usr/lib/libgalera_smm.so
wsrep_cluster_name=pxc-cluster
wsrep_cluster_address=gcomm://192.168.1.1,192.168.1.2,192.168.1.3
# 节点自身信息
wsrep_node_name=node1
wsrep_node_address=192.168.1.1
# SST 方式，推荐 xtrabackup-v2 或 rsync
wsrep_sst_method=xtrabackup-v2启动第一个节点（引导） 需要使用 systemctl start mysql@bootstrap.service 或 mysqld --wsrep_new_cluster，后续节点正常启动即可自动加入。
状态监控 重点看这几个值：
SHOW STATUS LIKE 'wsrep_cluster_size'; -- 应等于节点数
SHOW STATUS LIKE 'wsrep_local_state_comment'; -- 应为 Synced
SHOW STATUS LIKE 'wsrep_ready'; -- 应为 ON生产落地真实建议：
- 最小节点数 3，避免脑裂。奇数节点便于选举。
- 不要试图跨机房部署，网络波动会直接表现为数据库不可用。多主集群的容灾应当在同城低延迟网络内实现。
- 应用必须实现“写失败重试”逻辑，因为冲突导致的
Deadlock错误需要业务代码捕获并重试。 - 大事务是集群的杀手，一个包含大量行修改的事务会阻塞整个集群的认证流程。必须将批量操作拆分成小事务。
- 备份策略依然重要。虽然集群数据是冗余的，但误删数据等逻辑错误仍需要从备份恢复，PXC 配合 xtrabackup 做全量备份是常规操作。
20.2.7 适用场景取舍
多主集群适合的场景非常明确：对数据一致性要求极高、不能接受主从切换丢数据、且写入量可以预见在有限节点能够承载的范围内。典型的如金融支付、交易系统、资产管理系统等。
相反，如果你的业务写入量已经大到单集群不够用，或对网络延迟容忍度低，那么多主集群不是首选项。此时更合理的路径是分库分表 + 主从复制，利用业务切分来横向扩展写入能力。
总的来说，PXC/Galera 不是 MySQL 高可用的终点，而是强一致性这一维度上的特化解法。理解了它的原理和约束，你就能在合适的场景下，用很小的运维代价换取极致的可靠性。