Linux下MySQL多源主从与Galera集群实战：搭建、调优与避坑

1. 为什么要在Linux上折腾多源主从与Galera两套集群

MySQL的集群方案多如牛毛，但真正在生产环境里被反复拿出来讨论、反复被DBA们对比的，其实就那么几套。多源主从复制和Galera Cluster算是两个典型代表，前者解决的是"多个主库往一个从库汇总"的聚合需求，后者解决的是"多节点同时可写、强一致"的高可用需求。这两个场景看起来风马牛不相及，但实际工作中经常会在同一个技术栈里同时出现——比如一个数据汇总平台，底层既要对接多个业务库做数据归集，又要保证汇总层自身的高可用。

我在实际项目里接触这两套方案的起因很朴素：业务侧有若干个独立的小库，每个库都有自己的写入节奏，汇总分析需要把这些库的数据实时同步到一个中心库上；同时中心库本身不能是单点，一旦挂掉整个报表体系就瘫了。最初想用一套方案通吃，试过单主多从、试过主主复制，最后发现多源主从负责"收"，Galera负责"稳"，各司其职才是正解。

这篇文章面向的是有一定Linux基础和MySQL使用经验、正在为数据聚合或高可用架构选型的同学。我会把两套集群的搭建思路、核心参数、踩坑记录都摊开讲，尽量做到你照着步骤能复现，遇到问题能对照排查。需要说明的是，文中涉及的具体IP、库名、业务场景均为虚构示例，参数值也是基于常见实践的合理取值，实际部署时请结合自己的硬件和网络条件调整。

2. 两套集群的核心定位与选型逻辑拆解

2.1 多源主从复制到底解决什么问题

多源主从复制（Multi-Source Replication）本质上是把多个主库的binlog汇聚到一个从库上重放。传统主从是一对一或者一主多从，数据流向是发散的；多源复制则是收敛的，多个源头往一个目标汇聚。这个特性决定了它天然适合数据归集场景——比如多个分支机构各自有独立的业务库，总部需要一个统一的数据视图做分析。

它的工作原理并不复杂：从库上为每个主库建立独立的复制通道（channel），每个通道有自己的IO线程和SQL线程，各自负责拉取和重放对应主库的binlog。MySQL 5.7之后对多源复制的支持已经相当成熟，通道之间互相隔离，一个通道出问题不影响其他通道。这一点很关键，意味着你可以针对不同主库设置不同的过滤规则、不同的重试策略。

选它而不选其他方案的理由，我总结下来有三条。第一是侵入性低，主库那边几乎不用做任何改动，只要开启binlog、建一个复制账号就行，对现有业务零影响。第二是灵活性高，哪个主库同步哪些表、哪些库，都可以通过复制过滤规则精确控制。第三是运维成本可控，出问题时排查路径清晰，看哪个通道的延迟高、哪个通道报错，一目了然。

当然它也有明显的短板。从库是只读的（除非你刻意配置），所有写入压力都压在各个主库上；从库的SQL线程是单线程重放（MySQL 8.0之前），多个主库同时有大量写入时，从库很容易成为瓶颈。这些问题在后面讲参数调优时会具体展开。

2.2 Galera集群的强一致是怎么做到的

Galera Cluster是基于同步多主复制（Synchronous Multi-Master Replication）的集群方案，通常配合Percona XtraDB Cluster或MariaDB Galera Cluster使用。它和传统主从最大的区别在于：写操作要在集群内大多数节点确认后才提交，也就是所谓的"认证提交"（certification-based replication）。

具体机制是这样的：客户端往任意一个节点发起写操作，该节点在本地执行后，把写集（write-set）广播给集群内所有其他节点。其他节点收到写集后做冲突检测，确认没有冲突就返回认证通过。发起节点收到大多数节点的确认后，才真正提交事务并返回客户端成功。这个"大多数"就是quorum的概念，也是集群能容忍少数节点故障的原因。

这个机制带来的好处是强一致——任何时刻从任意节点读到的数据都是一致的，不存在主从延迟导致的数据不一致问题。同时它是多主架构，任意节点都能读写，写压力可以分摊到多个节点上。对于需要高并发写入又要求数据强一致的场景，这是很有吸引力的。

代价也很明显。第一是写入延迟受网络影响大，因为每次提交都要等大多数节点确认，跨机房部署时网络RTT直接叠加到事务延迟上。第二是集群规模有上限，节点越多认证开销越大，一般建议3到5个节点。第三是冲突处理，虽然Galera有 certification 机制检测冲突，但高并发下冲突回滚的概率会上升，应用层需要能处理死锁和回滚。第四是脑裂风险，网络分区时少数派节点会自动停止服务，这个行为需要运维提前理解，否则容易误判为故障。

2.3 两套方案放在一起的架构考量

把多源主从和Galera放在同一个架构里，通常是这样分工的：多源主从的从库作为数据汇聚点，汇聚点本身再作为Galera集群的一个节点，或者汇聚点写入Galera集群。这样既解决了多源归集，又保证了汇聚层的高可用。

这里有个设计上的取舍需要提前想清楚：汇聚点到底是Galera的写入入口，还是先落到一个普通实例再同步进Galera。前者架构简洁但汇聚点的写入压力会直接打到Galera上，后者多一层但可以做缓冲和清洗。我在项目里选的是后者，因为汇聚的数据往往需要做字段映射、去重、补全，这些逻辑放在中间层处理更灵活，也避免脏数据直接污染Galera集群。

选型上没有绝对的对错，关键看你的数据量、实时性要求和运维能力。数据量不大、实时性要求高、团队对Galera熟悉，可以直接汇聚进Galera；数据量大、需要清洗转换、团队更熟悉传统复制，中间加一层更稳妥。

3. 多源主从集群的搭建细节与参数调优

3.1 环境准备与主库侧配置

假设我们有三个主库（示例IP：192.168.10.11、192.168.10.12、192.168.10.13）和一个从库（192.168.10.20），操作系统统一用主流Linux发行版，MySQL版本选8.0（多源复制在8.0上更稳定，且支持并行重放）。

主库侧需要确认几件事。第一，binlog必须开启，且格式建议用ROW。ROW格式记录的是行变更，不依赖SQL上下文，多源复制场景下最不容易出问题。STATEMENT格式在某些非确定性函数下会导致主从数据不一致，MIXED格式虽然折中，但排查问题时不如ROW直观。

# 主库 my.cnf 关键配置 [mysqld] server-id = 11 # 每个主库必须不同 log-bin = mysql-bin binlog_format = ROW binlog_row_image = FULL # 记录完整行镜像，便于排查 gtid_mode = ON enforce_gtid_consistency = ON

server-id 在多源复制里尤其重要，每个主库必须全局唯一，否则从库无法区分通道来源。GTID建议开启，它能让复制位点管理自动化，切换和重建从库时省去手动找binlog文件和位置的麻烦。binlog_row_image设为FULL会增大binlog体积，但排查数据问题时能直接看到变更前后的完整行，这个取舍我认为值得。

主库上还要建复制账号，权限给REPLICATION SLAVE和REPLICATION CLIENT即可，不要图省事给ALL。

CREATE USER 'repl_user'@'192.168.10.%' IDENTIFIED BY 'StrongPass_2024'; GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'repl_user'@'192.168.10.%'; FLUSH PRIVILEGES;

注意：复制账号的密码强度要够，且host限制到从库所在网段，不要用'%'开放给所有来源。多源复制意味着从库要连多个主库，账号在每个主库上都要建一遍。

3.2 从库多通道配置的完整流程

从库侧的配置是多源复制的核心。首先要确保从库自身的server-id唯一，且开启了binlog（如果从库还要作为其他实例的主库，比如汇聚后再往下游同步）。然后为每个主库建立独立的复制通道。

-- 通道1：对接主库1 CHANGE MASTER TO MASTER_HOST='192.168.10.11', MASTER_USER='repl_user', MASTER_PASSWORD='StrongPass_2024', MASTER_AUTO_POSITION=1 FOR CHANNEL 'ch_master1'; -- 通道2：对接主库2 CHANGE MASTER TO MASTER_HOST='192.168.10.12', MASTER_USER='repl_user', MASTER_PASSWORD='StrongPass_2024', MASTER_AUTO_POSITION=1 FOR CHANNEL 'ch_master2'; -- 通道3：对接主库3 CHANGE MASTER TO MASTER_HOST='192.168.10.13', MASTER_USER='repl_user', MASTER_PASSWORD='StrongPass_2024', MASTER_AUTO_POSITION=1 FOR CHANNEL 'ch_master3';

MASTER_AUTO_POSITION=1 表示使用GTID自动定位，前提是主库开了GTID。通道名（ch_master1等）自己定义，建议带上主库标识，方便后续运维时快速定位。

启动所有通道：

START SLAVE FOR CHANNEL 'ch_master1'; START SLAVE FOR CHANNEL 'ch_master2'; START SLAVE FOR CHANNEL 'ch_master3';

查看状态时要指定通道，否则默认只看第一个：

SHOW SLAVE STATUS FOR CHANNEL 'ch_master1'\G

重点看三个字段：Slave_IO_Running和Slave_SQL_Running是否都是Yes，Seconds_Behind_Master是否在可接受范围，Last_Error是否有报错。多源复制下每个通道都要单独检查，不能只看一个就以为全好了。

3.3 复制过滤与冲突规避的实操要点

多源复制最容易踩的坑是表名冲突。三个主库如果都有同名库同名表，汇聚到从库上就会互相覆盖。解决办法有两种：一是主库侧库名就区分开（比如branch1_db、branch2_db），从库原样接收；二是用复制过滤规则做映射，但MySQL的复制过滤不支持库名重写，只能做include/exclude，所以映射得靠中间层或者ETL工具。

如果各主库的库名本身不冲突，直接用即可。如果冲突且无法改主库，那就得在从库上为每个通道配置过滤规则，只同步需要的表，并且确保这些表在从库上不重名。配置方式是在CHANGE MASTER时加REPLICATE_WILD_DO_TABLE或REPLICATE_DO_TABLE。

CHANGE MASTER TO MASTER_HOST='192.168.10.11', ... REPLICATE_WILD_DO_TABLE='branch1.%' FOR CHANNEL 'ch_master1';

注意：复制过滤规则是在从库的SQL线程重放时生效的，IO线程仍然会拉取全部binlog。所以过滤能减少从库的写入压力，但减少不了网络传输量。如果主库binlog量很大而只需要其中几张表，更好的做法是在主库侧控制binlog，或者用中间层做抽取。

另一个坑是自增主键冲突。多个主库各自有自增列，汇聚到从库上如果表的主键是自增的，很容易撞。标准做法是给每个主库设置不同的auto_increment_offset和auto_increment_increment。比如三个主库，increment都设为3，offset分别设1、2、3，这样各主库生成的自增值天然错开。

# 主库1 auto_increment_increment = 3 auto_increment_offset = 1 # 主库2 auto_increment_increment = 3 auto_increment_offset = 2 # 主库3 auto_increment_increment = 3 auto_increment_offset = 3

这个配置要在主库侧做，从库侧不需要。改完之后新插入的数据才会按新规则生成，历史数据不受影响。如果历史数据已经有冲突，得先清洗再切。

3.4 并行重放与延迟优化的参数组合

多源复制从库的SQL线程默认是单线程重放，三个主库同时写入时，从库很容易积压。MySQL 8.0支持基于LOGICAL_CLOCK的并行重放，能显著提升重放吞吐。

# 从库 my.cnf [mysqld] slave_parallel_type = LOGICAL_CLOCK slave_parallel_workers = 8 slave_preserve_commit_order = ON

slave_parallel_workers的数量建议设为CPU核数的1到2倍，8核机器给8到16都合理。slave_preserve_commit_order=ON保证并行重放后提交顺序和主库一致，避免从库上出现主库没有的中间状态。这个参数在MySQL 8.0.27之后默认就是ON，老版本要手动开。

LOGICAL_CLOCK的原理是把主库上同一组并行提交的事务在从库上也并行重放，组内事务之间没有依赖。它的并行度取决于主库的并发度，如果主库本身写入就是串行的，从库并行也提不上去。所以这个优化对高并发写入的主库效果明显，对低频写入的主库意义不大。

实测下来，三个主库各有一个持续写入的业务，从库单线程重放时延迟能到几十秒，改成8个并行worker后延迟稳定在1秒以内。当然这跟硬件和写入模式强相关，不能一概而论。

4. Galera集群的部署与一致性保障

4.1 节点规划与基础环境统一

Galera集群建议至少3个节点，因为quorum需要大多数，3节点能容忍1个故障，5节点能容忍2个。2节点没有容错意义，因为任何一个挂掉就失去大多数。示例规划三个节点：192.168.20.31、192.168.20.32、192.168.20.33。

所有节点的软件版本必须完全一致，包括MySQL/Percona版本、Galera库版本、操作系统内核参数。版本不一致是Galera集群起不来的常见原因，尤其是wsrep_provider的so文件版本要和数据库版本匹配。

基础环境要统一几项：关闭swap（Galera对内存延迟敏感，swap会导致性能骤降）、设置文件句柄数、同步时间（NTP或chrony）、防火墙放行Galera通信端口（默认4567用于组通信，4444用于SST，4568用于IST）。

# 关闭swap swapoff -a sed -i '/swap/s/^/#/' /etc/fstab # 文件句柄 echo "* soft nofile 65535" >> /etc/security/limits.conf echo "* hard nofile 65535" >> /etc/security/limits.conf

注意：swap关闭要写进fstab，否则重启后又生效。文件句柄数不够时，Galera在高并发下会出现"Too many open files"导致节点被踢出集群，这个坑很隐蔽，建议提前设好。

4.2 wsrep配置项逐个拆解

Galera的核心配置都在wsrep_开头的参数里，下面这份配置是三个节点共用的模板，只有wsrep_node_name和wsrep_node_address不同。

[mysqld] # 基础 server-id = 31 binlog_format = ROW default_storage_engine = InnoDB innodb_autoinc_lock_mode = 2 # Galera wsrep_on = ON wsrep_provider = /usr/lib64/galera4/libgalera_smm.so wsrep_cluster_name = "galera_prod" wsrep_cluster_address = "gcomm://192.168.20.31,192.168.20.32,192.168.20.33" wsrep_node_name = "node1" wsrep_node_address = "192.168.20.31" wsrep_sst_method = xtrabackup-v2 wsrep_sst_auth = "sst_user:SstPass_2024" wsrep_slave_threads = 8 wsrep_sync_wait = 1

逐个说关键项。wsrep_provider指向Galera库的so文件，路径因发行版而异，Percona通常是/usr/lib64/galera4/libgalera_smm.so，MariaDB在/usr/lib64/galera-4/下，装完用find确认一下。

wsrep_cluster_address是集群成员列表，新节点加入时写全所有已知节点。第一个启动的节点要用gcomm://（空地址）启动，表示初始化新集群，后续节点再连上来。这个顺序不能错，否则集群起不来。

wsrep_sst_method选xtrabackup-v2，它做的是热备份，不锁表，适合生产。rsync会锁表，只在测试环境用。SST（State Snapshot Transfer）是新节点加入时从现有节点全量同步数据的过程，数据量大时耗时长，期间现有节点会有一定压力。

wsrep_slave_threads是并行应用写集的线程数，和前面多源复制的并行重放类似，建议设为CPU核数的一半到全部。wsrep_sync_wait=1表示读操作前等待节点追上最新写集，保证读到的数据是最新的，代价是读延迟略增。对一致性要求高的场景建议开，对读性能敏感且能容忍轻微延迟的场景可以设0。

innodb_autoinc_lock_mode=2是Galera的硬性要求，因为多主写入下自增锁不能是传统的表级锁。这个参数改了之后自增值的连续性不再保证，应用层不能依赖自增ID连续。

4.3 集群初始化与节点加入的实操记录

初始化第一个节点：

# 在node1上 systemctl start mysql@bootstrap.service # 或者手动 mysqld --wsrep-new-cluster &

启动后检查集群状态：

SHOW STATUS LIKE 'wsrep_cluster_size'; SHOW STATUS LIKE 'wsrep_cluster_status'; SHOW STATUS LIKE 'wsrep_ready';

wsrep_cluster_size应该是1，wsrep_cluster_status是Primary，wsrep_ready是ON。确认无误后再启动node2和node3，它们会自动通过SST从node1同步数据并加入集群。

# node2、node3 systemctl start mysql

加入过程中在node2上观察：

SHOW STATUS LIKE 'wsrep_local_state_comment';

状态会经历Joiner、Joined、Synced几个阶段，到Synced就表示同步完成、正常服务了。SST期间node1的wsrep_local_state_comment会显示Donor，表示它在提供数据。

注意：SST过程中如果数据量大，node1的磁盘IO和网络会很高，建议在业务低峰期加节点。另外SST需要足够的磁盘空间存放临时文件，xtrabackup会在datadir下建临时目录，空间不足会导致SST失败，节点反复重试。

三个节点都Synced后，集群就正常了。任意节点写入，其他节点立即可见，这就是同步复制的效果。

4.4 脑裂防护与quorum行为理解

Galera的quorum机制是它安全性的核心，也是最容易被误解的地方。集群总节点数为N，quorum为N/2+1。3节点集群quorum是2，意味着至少2个节点存活才能提供服务。如果网络分区导致节点分裂成1和2两组，1个节点那组因为达不到quorum会自动进入非Primary状态，拒绝写入；2个节点那组继续服务。

这个行为是保护性的，防止两边都接受写入导致数据分叉。但运维上要理解：少数派节点不是"挂了"，而是主动停止服务，网络恢复后它会自动重新加入。如果你看到某个节点wsrep_cluster_status变成non-Primary，先查网络，不要急着重启。

有个参数wsrep_provider_options里的pc.ignore_sb（ignore split-brain）可以控制是否忽略脑裂检测，默认false。生产环境绝对不要设为true，那等于放弃了脑裂保护，两边都写会导致数据不一致且难以修复。

另一个相关参数是gcs.fc_limit（流控阈值），默认16。当某个节点的接收队列积压超过这个值时，集群会暂停其他节点的写入，等慢节点追上。这个机制防止慢节点拖垮整个集群，但也会让快节点被慢节点拖累。如果集群里有性能较差的节点，可以适当调大这个值，但不要调太大，否则慢节点积压过多会导致更大的同步延迟。

5. 两套集群的联动与数据流转设计

5.1 汇聚层到Galera的写入路径

前面提到多源主从的从库作为汇聚点，汇聚点再往Galera写。这条路径的设计要考虑几个问题：写入方式、批量大小、失败重试。

写入方式上，如果汇聚点和Galera在同一个机房，直接用MySQL客户端连接Galera节点写入即可。如果跨机房，建议在Galera侧部署一个写入代理或者用中间件做连接管理，避免汇聚点直连某个固定节点导致单点压力。

批量大小很关键。Galera的每次事务提交都要走认证流程，单条小事务写入的吞吐远低于批量写入。但批量太大又会导致单个写集过大，认证和传输开销上升，且失败回滚的成本高。实测下来每批500到1000行、单批数据量控制在1MB以内比较均衡。

# 批量写入示例（伪代码，示意逻辑） def batch_write(rows, batch_size=500): for i in range(0, len(rows), batch_size): batch = rows[i:i+batch_size] try: cursor.executemany( "INSERT INTO summary_table (...) VALUES (%s, ...) " "ON DUPLICATE KEY UPDATE ...", batch ) conn.commit() except Exception as e: conn.rollback() # 记录失败批次，降级为逐条重试或落盘待补偿 log_failed_batch(batch, e)

ON DUPLICATE KEY UPDATE 用于处理重复写入，汇聚场景下同一批数据可能因为重试被写多次，用这个语法保证幂等。但要注意它在Galera下会触发行锁竞争，高并发时死锁概率上升，应用层要有重试逻辑。

5.2 一致性校验与延迟监控

两套集群联动后，数据从主库到汇聚点再到Galera，链路上任何一环出问题都会导致数据不一致或延迟。监控要覆盖每一段。

主库到汇聚点的延迟看多源复制的Seconds_Behind_Master，每个通道单独看。汇聚点到Galera的延迟看写入耗时和Galera的wsrep_local_recv_queue（接收队列长度），队列持续增长说明应用跟不上。

一致性校验建议定期做，用pt-table-checksum这类工具对关键表做校验和比对。多源复制场景下校验要注意指定通道对应的库，Galera场景下校验要在单个节点上做（因为数据是同步的，节点间本身一致）。

# pt-table-checksum 示例（针对汇聚点与主库的比对） pt-table-checksum --host=192.168.10.20 --databases=branch1_db \ --replicate=percona.checksums --no-check-binlog-format

注意：pt-table-checksum默认会检查binlog格式，Galera和多源复制环境下binlog格式都是ROW，加--no-check-binlog-format跳过检查避免误报。校验本身会产生额外负载，建议在低峰期跑，且限制chunk大小。

延迟监控的阈值要结合业务定。报表类业务容忍几分钟延迟，实时风控类业务要求秒级。阈值定好后配告警，延迟超阈值先看是网络问题、大事务阻塞还是从库资源不足，对症处理。

5.3 故障切换时的数据安全边界

多源主从的故障切换相对简单：某个主库挂了，对应通道的IO线程报错，其他通道不受影响。恢复主库后重新START SLAVE即可，GTID会自动定位断点。如果主库彻底不可用需要提升从库，那要先把其他通道停掉，避免提升后继续接收旧数据。

Galera的故障切换是自动的：节点挂掉后，只要剩余节点满足quorum，集群继续服务，客户端重连到存活节点即可。应用侧要配置多节点连接串或者用代理做故障转移，不能写死单个节点IP。

数据安全边界上，多源复制的从库在故障时可能丢失最后一段未重放的数据（取决于relay log是否落盘）。Galera因为同步提交，已提交的事务在所有存活节点上都有，不会丢；但未提交的事务会回滚，客户端会收到错误，需要应用层处理。

有个细节要注意：Galera节点故障恢复后重新加入，如果落后太多会走IST（Incremental State Transfer）增量同步，落后太多则走SST全量同步。IST依赖gcache（写集缓存），gcache大小由gcache.size控制，默认128M。写入频繁的集群gcache很快被覆盖，落后稍多就得走SST。建议把gcache.size调到1G到4G，减少全量同步的概率。

wsrep_provider_options = "gcache.size=2G; gcache.page_size=128M"

6. 常见问题排查与避坑经验实录

6.1 多源复制典型故障速查

多源复制的问题集中在通道状态和冲突上，下面这张表是我整理的高频问题对照。

主键冲突这个坑我踩过。当时三个主库的auto_increment没统一规划，汇聚后频繁1062。临时办法是用sql_slave_skip_counter跳过，但那是治标，根子上还是要把offset错开、把历史冲突数据清洗掉。清洗时要注意，冲突的行可能在各主库含义不同，不能简单删一条了事，得按业务主键去重。

6.2 Galera集群启动失败的排查路径

Galera起不来时，先看错误日志，路径通常在/var/log/mysql/error.log或datadir下的hostname.err。常见错误和对应处理：

第一类，wsrep_provider加载失败。报错"Could not open library"或"undefined symbol"，说明so文件路径不对或版本不匹配。用find / -name "libgalera*"确认实际路径，检查数据库版本和Galera版本是否配套。

第二类，集群地址连不上。报错"failed to connect to cluster"或一直停在Joiner状态。检查wsrep_cluster_address里的IP是否可达、4567端口是否放行、第一个节点是否用gcomm://空地址启动。如果之前集群有残留状态，新集群初始化前要清掉grastate.dat里的seqno或者用--wsrep-new-cluster强制初始化。

第三类，SST失败。报错里会带xtrabackup的输出，常见是sst_user密码错、磁盘空间不足、xtrabackup版本不兼容。wsrep_sst_auth的格式是user:password，冒号不能少。SST临时目录空间要留足，至少和现有数据量相当。

第四类，节点加入后反复被踢。看wsrep_local_state_comment在Synced和Joiner之间跳，通常是网络不稳定或者流控触发。检查节点间网络延迟和丢包，调大gcs.fc_limit观察。

注意：集群起不来时不要盲目重启所有节点。先确认哪个节点是最后正常关闭的（grastate.dat里seqno最大的），从它开始启动最安全。如果所有节点seqno都是-1，说明是非正常关闭，需要选一个数据最全的节点用--wsrep-new-cluster强制启动，其他节点再加入。

6.3 两套方案共存的资源与运维建议

两套集群跑在同一批机器上（或者同一机房），资源竞争要提前规划。多源复制的从库是IO密集型（拉binlog、重放），Galera是网络和CPU密集型（认证、广播）。如果混部，建议给多源从库和Galera节点分不同的物理机或至少分不同的磁盘。

运维上，两套集群的监控指标要分开采集。多源复制重点看通道状态和延迟，Galera重点看集群大小、节点状态、接收队列、gcache使用率。告警阈值分开设，不要用一套模板套两个场景。

备份策略也要分开。多源从库可以用mysqldump或xtrabackup做逻辑/物理备份，Galera建议在单个节点上做物理备份（因为数据同步，备一个节点等于备全集群），备份时用wsrep_desync让该节点暂时脱离同步，避免备份锁影响集群。

-- 备份前让节点脱离同步 SET GLOBAL wsrep_desync = ON; -- 备份完成后恢复 SET GLOBAL wsrep_desync = OFF;

wsrep_desync=ON期间该节点不参与流控，备份不会拖慢集群，但该节点的数据会落后，备份完要等它追上再恢复业务读。这个操作要在低峰期做，且备份完确认wsrep_local_recv_queue归零再关desync。

7. 我在实际部署中的几点体会

这套架构从设计到稳定运行，前后调整了好几轮。最开始想省事，把多源从库直接当Galera的一个节点，结果汇聚写入的批量操作经常触发Galera的流控，把整个集群的写入都拖慢了。后来拆成独立的多源从库加中间写入层，问题才解决。这个教训是：Galera对写入模式很敏感，大批量、长事务、高冲突的写入都不适合直接打进去，中间加一层缓冲和整形很有必要。

另一个体会是关于参数调优的节奏。不要一上来就把所有参数调到"最优值"，那样出了问题根本不知道是哪个参数导致的。我的做法是先跑默认配置，观察瓶颈在哪，一次只调一个参数，调完压测对比。wsrep_slave_threads、gcache.size、slave_parallel_workers这几个是收益最明显的，但也最需要结合实际负载调，照搬别人的配置往往水土不服。

最后说个容易被忽略的点：时间同步。多源复制和Galera都依赖准确的时间来做延迟判断和日志分析，节点间时间偏差超过几秒，排查问题时的时间线就乱了。chrony配好，定期检查偏移量，这个基础工作做扎实，后面省很多事。