MySQL 的多源复制和 Galera 集群这两个词放在一起很多人的第一反应是这俩不是一回事吗。实际上它们解决的是完全不同层面的问题多源复制解决的是多个上游数据源如何汇入一个下游节点的数据聚合问题Galera 解决的是多个节点如何保持强一致写入的多主同步问题。我在实际项目中既用过前者做数据汇总也用后者做过高可用写入层踩过的坑各有各的滋味。这篇内容就把这两套方案在 Linux 环境下的部署逻辑、参数取舍、以及那些文档里不会写的注意事项完整地拆一遍。如果你正在面对多个业务库的数据要汇总到一张报表库或者写入层不能有单点、切换不能丢数据这类需求下面的内容应该能直接拿去用。我会从架构选型的判断依据讲起然后分别给出多源主从和 Galera 的落地步骤最后把两类方案在实际运维中最容易翻车的地方单独拎出来说。1. 先搞清楚两类集群各自解决什么问题在动手配之前得先把选型逻辑理清楚。我见过不少团队一上来就说我们要做多主集群结果业务场景其实只是想把三个分库的数据合并查询用 Galera 纯属给自己找麻烦。所以这一节先把两类方案的适用边界划清楚。1.1 多源主从的本质是数据汇聚而非高可用多源复制Multi-Source Replication的核心能力是一个从节点可以同时从多个主节点接收 binlog 并重放。注意这里的关键词是接收和重放它本质上仍然是主从复制模型只不过把一对多的下行方向改成了多对一。这个特性天然适合的场景是数据汇总。比如你有一套订单库、一套用户库、一套商品库各自独立运行但报表系统需要跨库关联查询。传统做法是写 ETL 脚本定时抽数或者用中间件做数据同步而多源复制让你可以在数据库层面直接把三路 binlog 汇聚到一个实例上省掉中间层。但它的局限也很明显从节点是只读的除非额外配置不具备写入高可用能力。如果主节点挂了从节点不会自动接管你仍然需要一套故障转移机制。所以如果你的诉求是写入不能停多源主从不是答案。1.2 Galera 的核心价值是同步多主与强一致Galera Cluster 走的是另一条路。它基于认证复制Certification-Based Replication机制所有节点地位对等写入可以落在任意节点上事务在提交前需要经过集群认证确保不会产生冲突。认证通过后事务会以同步方式广播到所有节点只有多数节点确认收到提交才算完成。这里有个关键点很多人会误解Galera 的同步指的是认证阶段的同步而不是所有节点数据落盘后才返回。实际流程是本地执行事务 → 收集行锁 → 发送到所有节点做认证 → 多数派确认无冲突 → 本地提交并广播 write set。所以它保证的是集群内不出现数据冲突而不是所有节点时刻完全一致。这个区别决定了 Galera 的适用场景需要多节点同时可写、且对数据一致性要求高的 OLTP 业务。典型如电商的库存扣减、金融的交易记录。但它对写性能有损耗因为每次提交都要走一轮集群通信网络延迟直接反映在事务响应时间上。1.3 选型判断表把两类方案的差异整理成一张表方便对照自己的场景做判断维度多源主从Galera 集群拓扑结构多主一从汇聚型多主对等网状型写入能力仅主节点可写从节点只读任意节点可写一致性模型异步复制存在延迟同步认证强一致典型场景数据汇总、报表聚合、分库合并查询高可用写入层、读写分离、故障自动切换写性能损耗低异步中高每次提交走集群通信网络要求低高节点间低延迟、稳定带宽故障切换需外部工具配合内置自动剔除故障节点数据冲突处理不涉及单向复制认证阶段检测并回滚冲突事务注意如果你的场景既需要多源汇聚又需要高可用写入这两套方案可以叠加使用——用 Galera 做写入层保证高可用再用多源复制把多个 Galera 集群的数据汇聚到分析节点。但这种叠加会显著增加运维复杂度中小规模场景要慎重。2. 多源主从复制的落地配置假设现在有三套独立的上游数据库需要把它们的增量数据汇聚到一台汇总节点上。下面按实际操作顺序走一遍重点说清楚每一步的意图和容易出错的参数。2.1 上游主节点的必要配置每个上游主节点都需要开启 binlog 并设置唯一的 server-id。这一步看起来基础但多源场景下 server-id 冲突是最高频的故障原因——因为汇聚节点要同时连接多个主节点如果两个主节点的 server-id 相同复制线程会直接报错退出。# 上游主节点 my.cnf 片段 [mysqld] server-id 101 # 每个主节点必须不同建议按业务编号规划 log-bin mysql-bin binlog_format ROW # 多源复制强烈建议 ROW 格式 binlog_row_image FULL # 确保行镜像完整避免部分列更新导致重放异常 gtid_mode ON enforce_gtid_consistency ON关于binlog_format这里必须强调多源复制场景下务必使用 ROW 格式。STATEMENT 格式在跨库汇聚时极易因为上下文差异比如自增列、函数调用导致主从数据不一致而多源汇聚恰恰是上下文差异最大的场景。binlog_row_image FULL则是为了保证更新操作能完整重放MINIMAL 模式下只记录变更列在某些跨版本汇聚时会出现字段缺失问题。GTID 的开启同样重要。多源复制下每个复制通道需要独立管理位点用传统的 binlog file position 方式管理三路通道位点信息容易混乱。GTID 模式下每个通道自动追踪已执行的事务集合切换和重建都简单得多。2.2 汇聚节点的参数调优汇聚节点是多源复制的核心它的配置直接决定了复制能否稳定运行。除了常规的 server-id 和 binlog 配置外有几个参数需要特别关注# 汇聚节点 my.cnf 片段 [mysqld] server-id 200 log-bin mysql-bin binlog_format ROW gtid_mode ON enforce_gtid_consistency ON # 多源复制关键参数 replica_parallel_workers 8 # 并行重放线程数建议等于 CPU 核数 replica_parallel_type LOGICAL_CLOCK # 基于逻辑时钟的并行策略 replica_preserve_commit_order ON # 保证并行重放后的提交顺序 slave_transaction_retries 10 # 事务重试次数应对锁冲突replica_parallel_workers的设置需要结合上游写入压力来定。如果三路主节点的写入都很密集并行线程数太少会导致重放积压但设得过大也会带来额外的上下文切换开销。我的经验值是CPU 核数的 1 到 1.5 倍然后观察SHOW REPLICA STATUS中的Seconds_Behind_Source是否稳定在低位。replica_preserve_commit_order ON这个参数在多源场景下尤其关键。并行重放时不同通道的事务可能交错提交如果提交顺序与原始顺序不一致依赖事务先后关系的业务逻辑比如先插入后更新就会出错。开启这个参数后并行线程会按原始提交顺序落盘牺牲一点并行度换取正确性这笔账是划算的。2.3 复制通道的建立与验证MySQL 8.0 之后多源复制通过FOR CHANNEL语法管理多个复制通道每个通道对应一个上游主节点。建立通道的步骤如下-- 在汇聚节点执行为每个上游建立独立通道 CHANGE REPLICATION SOURCE TO SOURCE_HOST upstream-a-host, SOURCE_PORT 3306, SOURCE_USER repl_user, SOURCE_PASSWORD repl_pass, SOURCE_AUTO_POSITION 1 FOR CHANNEL channel_a; CHANGE REPLICATION SOURCE TO SOURCE_HOST upstream-b-host, SOURCE_PORT 3306, SOURCE_USER repl_user, SOURCE_PASSWORD repl_pass, SOURCE_AUTO_POSITION 1 FOR CHANNEL channel_b; -- 启动所有通道 START REPLICA FOR CHANNEL channel_a; START REPLICA FOR CHANNEL channel_b;SOURCE_AUTO_POSITION 1配合 GTID 使用省去了手动指定 binlog 位点的麻烦。通道命名建议带上业务含义如channel_order、channel_user后续排查问题时一眼就能定位是哪个上游出的状况。验证阶段重点看两个地方SHOW REPLICA STATUS FOR CHANNEL channel_a\G中的Replica_IO_Running和Replica_SQL_Running是否都为Yes以及Retrieved_Gtid_Set和Executed_Gtid_Set是否在持续推进。如果 IO 线程正常但 SQL 线程报错通常是表结构不一致或主键冲突需要到Last_SQL_Error里看具体原因。2.4 多源汇聚的冲突预防多源复制最容易出问题的地方是主键冲突。三个上游如果各自有独立的自增主键汇聚到同一张表时必然撞车。解决办法有两种第一种是分表汇聚每个上游的数据落到汇聚节点上不同的表查询时用视图或 UNION 合并。这种方式最安全但查询侧要改。第二种是自增步长隔离给每个上游设置不同的auto_increment_offset和auto_increment_increment让各自生成的主键落在不同区间。比如三个上游分别设 offset 为 1/2/3、increment 为 3生成的主键就是 1,4,7...、2,5,8...、3,6,9...天然不冲突。-- 上游 A SET GLOBAL auto_increment_increment 3; SET GLOBAL auto_increment_offset 1; -- 上游 B SET GLOBAL auto_increment_increment 3; SET GLOBAL auto_increment_offset 2; -- 上游 C SET GLOBAL auto_increment_increment 3; SET GLOBAL auto_increment_offset 3;注意自增步长方案要求所有上游的 increment 值一致否则区间会重叠。而且这个设置只影响新插入的数据存量数据的主键不会改变所以要在业务上线前就规划好中途切换需要处理存量冲突。3. Galera 集群的部署与调优Galera 的部署比多源复制复杂因为它涉及集群引导、节点加入、状态同步等多个阶段。下面按从零搭建的顺序走重点讲清楚每个阶段的关键动作和参数含义。3.1 节点基础环境与依赖准备Galera 通常以 Percona XtraDB Cluster 或 MariaDB Galera Cluster 的形式落地两者配置逻辑基本一致。以 PXC 为例三个节点的基础环境需要保持一致操作系统版本、MySQL 大版本、wsrep 插件版本都要对齐否则节点加入集群时可能因为协议不兼容被拒绝。每个节点的my.cnf中wsrep 相关配置是核心[mysqld] # 基础复制配置 server-id 1 # 每个节点唯一 log-bin mysql-bin binlog_format ROW gtid_mode ON enforce_gtid_consistency ON # wsrep 集群配置 wsrep_on ON wsrep_provider /usr/lib/galera/libgalera_smm.so wsrep_cluster_name my_galera_cluster wsrep_cluster_address gcomm://node1-ip,node2-ip,node3-ip wsrep_node_name node1 wsrep_node_address node1-ip wsrep_sst_method xtrabackup-v2 wsrep_sst_auth sst_user:sst_passwsrep_cluster_address里列出所有节点的地址新节点加入时会依次尝试连接。wsrep_sst_method选择状态快照传输方式xtrabackup-v2是生产环境的首选它支持在线热备不会阻塞 donor 节点的写入。rsync方式虽然简单但会锁表只适合测试环境。wsrep_sst_auth指定的账号需要有RELOAD、LOCK TABLES、REPLICATION CLIENT、PROCESS等权限以及备份目录的读写权限。这个账号建漏权限是 SST 失败最常见的原因报错信息往往只显示authentication failed不会告诉你具体缺哪个权限排查起来很费时间。3.2 集群引导与节点加入的顺序Galera 集群的启动有严格的顺序要求第一个节点必须以引导模式启动后续节点才能正常加入。如果三个节点同时以普通模式启动它们会互相等待对方提供数据形成死锁。# 在 node1 上以引导模式启动 systemctl stop mysql mysqld_safe --wsrep-new-cluster # 确认 node1 成为主组件 mysql -e SHOW STATUS LIKE wsrep_cluster_size; # 应显示 1 # 在 node2、node3 上正常启动 systemctl start mysqlnode2 和 node3 启动后会自动连接wsrep_cluster_address中的节点触发 SST状态快照传输从 donor 节点拉取全量数据。SST 期间 donor 节点会记录增量变更传输完成后追平这个过程称为 IST增量状态传输。验证集群状态的关键指标SHOW STATUS LIKE wsrep_cluster_size; -- 应为 3 SHOW STATUS LIKE wsrep_cluster_status; -- 应为 Primary SHOW STATUS LIKE wsrep_ready; -- 应为 ON SHOW STATUS LIKE wsrep_local_state_comment; -- 应为 Syncedwsrep_cluster_status如果不是Primary说明节点处于非主组件状态通常是因为集群分裂后该节点所在的分区节点数不足多数派。这时候需要人工介入判断哪个分区是合法的再决定是否强制引导。3.3 流控机制与写入节流Galera 有一个容易被忽视但影响巨大的机制流控Flow Control。当某个节点的接收队列积压到阈值时它会向集群发送暂停写入的信号所有节点都会等待直到该节点追上进度。这个机制保证了慢节点不会拖垮整个集群的一致性但代价是写入吞吐会被最慢的节点拖累。如果集群中有一个节点磁盘性能差或者网络延迟高整个集群的写入都会间歇性卡顿。相关参数wsrep_provider_options gcs.fc_limit128;gcs.fc_factor0.8;gcs.fc_master_slaveNOgcs.fc_limit是触发流控的队列长度阈值默认 16 偏保守适当调大可以提升吞吐但会增加节点间数据滞后的窗口。gcs.fc_factor是流控解除的恢复比例0.8 表示队列降到阈值的 80% 时恢复写入。这两个参数需要结合集群的实际写入压力和节点性能来调没有放之四海皆准的值。我的经验是先保证所有节点硬件规格一致这是避免流控频繁触发的最有效手段。如果确实存在异构节点把性能差的节点配置为gcs.fc_master_slaveYES并指定它只做只读查询减少它参与写入认证的压力。3.4 脑裂预防与多数派判断Galera 用法定人数Quorum机制防止脑裂。集群中节点数过半的分区才能继续提供服务不足半数的分区会自动进入非主状态拒绝写入。三节点集群的容错能力是挂一个节点剩余两个仍构成多数派2 1.5集群正常挂两个节点剩余一个不构成多数派1 1.5该节点停止写入。所以三节点集群只能容忍一个节点故障这是很多人部署时的认知盲区。如果需要容忍两个节点同时故障至少需要五节点集群3 2.5。但五节点意味着每次写入要等待更多节点确认写延迟会上升。实际选型时要在容错能力和写性能之间做权衡。# 调整节点权重可选 wsrep_provider_options pc.weight2pc.weight可以给不同节点设置不同权重权重高的节点在法定人数计算中占更大比重。这个参数在跨机房部署时有用——把主机房节点的权重调高避免备机房网络抖动导致主机房失去多数派。但权重配置要谨慎设置不当反而会增加脑裂风险。4. 两类方案在实际运维中的高频问题配置跑通只是开始真正消耗精力的是日常运维中的各种异常。这一节把多源复制和 Galera 各自最容易出问题的地方单独拎出来说都是实际踩过的。4.1 多源复制的延迟排查链路多源复制最常见的告警是汇聚节点延迟过高。排查时不能只看Seconds_Behind_Source因为这个指标在多源场景下会取所有通道的最大值容易误导。正确的排查顺序是第一步分通道看延迟。SHOW REPLICA STATUS FOR CHANNEL xxx逐个通道检查定位是哪个上游拖慢了整体。第二步判断是 IO 延迟还是 SQL 延迟。如果Replica_IO_Running正常但Seconds_Behind_Source持续增长说明 binlog 拉取没问题是重放跟不上。这时候要看Replica_SQL_Running_State如果显示Waiting for dependent transaction to commit说明并行重放遇到了依赖等待需要调大replica_parallel_workers或检查是否有大事务。第三步检查大事务。上游一个批量更新几百万行的操作在汇聚节点重放时会长时间占用一个工作线程导致其他事务排队。解决办法是在上游把大事务拆小或者临时调大replica_parallel_workers让其他通道不受影响。第四步检查汇聚节点的写入压力。如果汇聚节点同时还在承载报表查询查询的锁竞争会拖慢重放。这种情况考虑把重放和查询做资源隔离或者把报表查询迁到独立的只读副本上。4.2 Galera 的 SST 失败与 donor 选择Galera 节点加入时的 SST 失败是高频问题表现是新节点一直卡在Joining状态日志里反复出现 SST 相关错误。常见原因和对策现象可能原因处理方式SST 请求被拒绝donor 节点正在处理大事务或流控中等待流控解除后重试或手动指定 donor认证失败sst_user 权限不足补齐 RELOAD、LOCK TABLES、REPLICATION CLIENT、PROCESS 权限传输中断网络带宽不足或超时调大wsrep_sst_donor超时检查网络磁盘空间不足donor 节点备份目录空间不够清理空间或更换备份目录手动指定 donor 的方式是在新节点的配置里加wsrep_sst_donornode2强制从指定节点拉取。这个技巧在某个节点负载过高时特别有用可以避免它被选为 donor 后雪上加霜。还有一个隐蔽的坑SST 期间 donor 节点会记录所有增量变更如果 SST 耗时过长增量日志可能撑爆磁盘。所以大库的 SST 要提前评估时间必要时先用物理备份恢复一个基线再让节点以 IST 方式加入缩短同步窗口。4.3 写入冲突的识别与业务侧规避Galera 的认证机制能检测冲突但检测到冲突后是回滚后提交的事务而不是阻止冲突发生。这意味着业务侧会收到一个死锁类似的错误错误码 1213 或 1205需要应用层做重试。冲突的高发场景是两个节点同时对同一行做更新。比如库存扣减节点 A 和节点 B 同时读到库存 100各自扣减后提交先提交的成功后提交的在认证阶段被发现基于旧版本被回滚。规避思路有三条一是热点行集中写入。把同一商品的库存扣减路由到固定节点避免跨节点并发。这需要在应用层做路由牺牲一点灵活性换取低冲突率。二是缩短事务持有时间。冲突窗口与事务持续时间正相关把大事务拆成小事务减少行锁持有时间能显著降低冲突概率。三是应用层重试。这是兜底手段捕获 1213/1205 错误后做有限次重试配合退避策略。重试次数不宜过多否则在持续冲突时会放大集群压力。4.4 备份策略的差异多源复制和 Galera 的备份逻辑不同不能套用同一套脚本。多源复制的汇聚节点本质上是普通 MySQL 实例用mysqldump或xtrabackup常规备份即可。但要注意备份时记录各通道的 GTID 位点恢复后需要重新指向正确的位点否则会重复重放或漏重放。Galera 的备份要复杂一些。虽然任意节点都可以做备份但建议在非 donor 节点上做避免备份 IO 与 SST 传输争抢资源。备份工具推荐xtrabackup它能正确处理 wsrep 相关的元数据。恢复时要注意从备份恢复的节点不能直接以引导模式启动必须先以普通模式加入现有集群让集群帮它追平差异。提示Galera 集群做逻辑备份时建议先SET GLOBAL wsrep_desyncON让该节点暂时脱离同步备份完成后再SET GLOBAL wsrep_desyncOFF重新加入。这样可以避免备份期间的长事务触发流控影响整个集群的写入。5. 混合架构下的协同与边界有些场景下两类方案会同时出现比如用 Galera 做写入层、多源复制做数据汇聚。这种混合架构能发挥各自优势但协同处有不少细节要注意。5.1 Galera 节点作为多源复制的上游把 Galera 集群的某个节点配置为多源复制的上游时要确保该节点的 binlog 配置正确。Galera 的写入是在所有节点上重放的所以任意节点的 binlog 都包含完整的事务流选一个稳定的节点作为复制源即可。但要注意Galera 的 binlog 中事务的 GTID 与普通 MySQL 有差异因为 wsrep 会在事务提交时附加集群相关的元信息。多源复制通道用SOURCE_AUTO_POSITION1连接 Galera 节点时GTID 集合的匹配逻辑仍然有效但建议先在测试环境验证一遍确认位点推进正常。另一个细节是流控的影响。如果 Galera 集群触发流控写入会暂停多源复制的 IO 线程会看到 binlog 暂时没有新内容表现为延迟短暂上升。这是正常现象不需要干预流控解除后会自动恢复。5.2 汇聚节点的写入隔离如果汇聚节点既要接收多源复制的数据又要承载查询建议做资源隔离。最直接的方式是用resource group把复制线程和查询线程分到不同的 CPU 组-- 创建资源组 CREATE RESOURCE GROUP rg_replication TYPE SYSTEM VCPU 0-3 THREAD_PRIORITY 10; -- 将复制线程绑定到该组需在启动时配置 -- my.cnf 中增加 -- replica_parallel_workers 4 -- 并通过 performance_schema 确认线程归属更彻底的隔离是把汇聚节点拆成接收节点和查询节点两级接收节点只跑复制查询节点从接收节点再复制一份。这样查询压力完全不会影响复制链路代价是多一跳复制延迟。5.3 故障切换时的顺序问题混合架构下的故障切换要考虑顺序。如果 Galera 集群发生主组件切换多源复制的上游地址可能需要更新。建议把多源复制的上游指向一个 VIP 或代理层而不是直接指向某个 Galera 节点这样 Galera 内部切换时复制链路不受影响。反过来如果汇聚节点故障需要重建时要确保新节点从正确的 GTID 位点开始复制。建议定期把各通道的Executed_Gtid_Set记录到外部配置中心重建时直接指定避免从头全量同步。6. 一些参数之外的实战体会配置和参数能解决大部分问题但有些经验是参数表里看不到的。关于硬件一致性。Galera 集群对节点性能差异极其敏感一个慢节点就能拖垮整个集群的写入。我见过因为一个节点的磁盘从 SSD 换成了机械盘导致整个集群写入延迟从 2ms 涨到 50ms 的案例。所以部署 Galera 时节点规格必须对齐这不是建议是硬性要求。关于监控指标的选择。多源复制重点监控分通道延迟和重放线程状态Galera 重点监控wsrep_local_recv_queue接收队列长度、wsrep_flow_control_paused流控暂停比例和wsrep_cluster_size集群节点数。wsrep_flow_control_paused如果持续大于 0.1说明流控频繁触发需要排查慢节点。关于版本升级。Galera 的滚动升级有严格顺序先升级所有节点的 wsrep 插件到目标版本再逐个重启节点。升级过程中集群始终保持多数派可用但每次重启一个节点后要等它完成 IST 追平再动下一个。多源复制的升级相对简单汇聚节点和上游可以独立升级只要 binlog 格式兼容即可。关于测试环境的价值。这两类方案在测试环境跑通不代表生产可用。多源复制的冲突问题、Galera 的流控问题都需要在接近生产的数据量和并发下才会暴露。建议在测试环境用生产数据的脱敏副本做压测重点观察冲突率和流控触发频率这两个指标决定了方案在生产环境的实际表现。最后说一个我自己的习惯每次调整完集群参数不管多小的改动都先在从节点或非核心节点上验证一轮确认wsrep_ready和复制线程状态正常后再推到全集群。这个习惯帮我避免过好几次因为参数笔误导致的集群抖动。参数这东西改错一个数字的代价往往比多花十分钟验证要大得多。