国产化迁移实战：基于Galera Cluster构建高可用MySQL集群

1. 项目概述：从单点到集群的国产化跃迁

最近几年，我身边不少朋友和客户都在聊一个词：国产化。这不仅仅是政策导向，更是在当前复杂国际环境下，企业保障自身数据安全与业务连续性的必然选择。很多核心业务系统，过去可能跑在Oracle、DB2或者开源的MySQL单实例上，现在都需要考虑迁移到符合信创要求的国产软硬件环境。在这个过程中，数据库作为数据的核心载体，其迁移方案的稳妥与否，直接决定了整个项目的成败。

我这次要聊的，就是一个在国产化迁移浪潮中，被反复验证过的经典方案：将原有的MySQL数据库，迁移到基于Galera Cluster构建的高可用MySQL集群。这个标题听起来技术性很强，但拆解开来，它解决的是一个非常实际的问题：如何在保证数据零丢失、服务几乎不停机的前提下，把一个跑了好几年的“老”MySQL数据库，平稳地搬到新的国产化平台上，并且还要让它未来能扛得住更大的流量、具备更高的可靠性。

简单来说，MySQL Galera Cluster是一种基于同步复制的多主集群方案。它不像传统的主从复制（一个写，多个读），而是集群中每个节点都可以读写，并且任何写入都会同步到所有节点，保证了数据的强一致性。这对于国产化迁移场景来说，简直是“天作之合”。迁移过程本身可以看作是一次特殊的“数据同步”，利用Galera的同步特性，我们可以将新集群的节点逐步加入，实现数据的平滑迁移和切换。完成迁移后，新集群本身就具备了多活高可用的能力，一举两得。

这篇文章，我会从一个实践者的角度，把这次迁移的里里外外讲透。无论你是正在规划国产化迁移的架构师，还是需要具体执行迁移的DBA或运维工程师，甚至是负责业务开发的同事想了解底层数据层的变化，都能从中找到可落地的思路和避坑指南。我们不止讲“怎么做”，更会深入探讨“为什么这么做”，以及“我踩过哪些坑”。

2. 核心需求解析：为什么是Galera Cluster？

在决定采用某个技术方案之前，我们必须先搞清楚它到底解决了什么问题，以及为什么它是当前场景下的最优解。对于国产化迁移中的数据库部分，核心需求可以归纳为以下几点，而Galera Cluster恰好能一一满足。

2.1 高可用与业务连续性保障

这是国产化迁移的底线要求，绝不能因为迁移导致业务长时间中断。传统的停机备份恢复方式，动辄数小时的窗口期，对于7x24小时在线的核心业务是无法接受的。Galera Cluster的同步多主架构，天生为高可用设计。在迁移过程中，我们可以先将一个Galera节点部署在新的国产化服务器上，并将其配置为“捐赠者”或通过特定的备份工具（如Percona XtraBackup）从原库拉取全量数据，并进入集群同步状态。此时，应用依然访问原库。当新节点数据追平后，我们可以逐步将应用读写流量切换到新集群的节点上。由于Galera的强一致性，切换过程中不会有数据不一致的风险。即使切换后原库或新集群某个节点故障，其他节点也能立即接管服务，实现RPO（恢复点目标）≈0，RTO（恢复时间目标）在秒级的故障切换。

2.2 数据强一致性的硬性要求

金融、政务、电信等领域的业务系统，对数据的一致性要求极为苛刻。传统的异步主从复制存在延迟，在主库故障切换时可能丢失最新数据。而Galera Cluster采用基于认证的同步复制，一个事务必须在所有节点（或大多数节点）上预提交成功，才在主节点上真正提交。这确保了集群内所有节点数据的实时一致性。在迁移的最终切换时刻，这一点至关重要——你能百分百确信，新集群上的数据和旧库在切换时间点是完全一致的，没有任何“大概齐”、“基本同步”的模糊地带。

2.3 线性扩展写能力

国产化迁移往往伴随着硬件平台的变更（例如从x86到ARM），初期可能对新平台的性能存疑。Galera Cluster的多主特性允许写操作分发到不同节点，理论上可以提供接近线性的写扩展能力。这意味着，如果单节点写性能因架构差异略有不足，可以通过横向增加节点来提升整体写吞吐量，为性能预留了弹性空间。当然，这一点需要谨慎评估，因为同步复制本身会带来网络延迟开销，并非所有场景都适合多主同时高强度写入。

2.4 对应用透明，改造成本低

这是Galera Cluster在迁移方案中最大的优势之一。对于应用程序来说，Galera Cluster在大多数情况下就像一个普通的MySQL服务器。应用通过标准的MySQL驱动和连接串进行访问。我们通常会在集群前端部署一个负载均衡器（如HAProxy、ProxySQL或F5）来分发连接。应用只需要连接到这个虚拟IP或域名，无需关心后端是单个MySQL还是多节点的Galera集群。这意味着，在从旧单实例迁移到新集群的过程中，应用程序的代码几乎不需要修改，仅需更改数据库连接地址。这极大地降低了迁移的复杂度和风险，也缩短了整体工期。

注意：说“几乎”不需要修改，是因为要警惕少数不兼容的SQL语句或客户端行为，例如对LAST_INSERT_ID()函数在多主写入下的特殊处理、对系统变量@@server_id的依赖等，但这些都可以通过规范或配置解决。

2.5 开源与生态兼容性

Galera Cluster本身是开源的，其最流行的实现是与Percona XtraDB Cluster（PXC）和MariaDB Galera Cluster绑定。这意味着它没有额外的商业许可成本，符合国产化对自主可控和成本控制的要求。同时，它基于标准的MySQL/InnoDB，兼容绝大部分MySQL生态工具，如主流的管理客户端、备份工具（XtraBackup）、监控系统（Prometheus+mysqld_exporter, Zabbix等）。这使得迁移后的运维体系可以平滑过渡，团队学习成本相对较低。

3. 迁移方案全景设计与核心考量

明确了为什么用Galera，接下来就要设计具体的迁移路径。一个完整的迁移方案不是简单的“安装新软件，拷贝数据”，它需要周密的计划，平衡风险、成本与效率。下面这张图概括了从评估到上线的核心流程，我们将逐一拆解每个环节。

flowchart TD A[迁移启动：现状评估与目标规划] --> B{集群拓扑与规模设计}; B --> C[国产化环境准备<br>硬件/OS/存储/网络]; C --> D[Galera集群部署与初始化]; D --> E[全量数据迁移<br>（XtraBackup物理备份还原）]; E --> F[增量数据同步与追平<br>（利用Galera IST/SST）]; F --> G{数据验证与一致性校验}; G -- 校验通过 --> H[应用连接切换<br>（通过负载均衡器）]; G -- 校验失败 --> E; H --> I[旧系统下线与观察]; I --> J[迁移完成， 进入常态化运维];

3.1 阶段一：迁移前评估与规划

在动手之前，必须对现有系统和新环境有透彻的了解。

1. 现状调研清单：

• 数据库规模：数据总量、每日增量、最大表大小、表数量。这决定了全量备份恢复的时间和网络带宽需求。
• 业务流量模式：QPS（每秒查询数）、TPS（每秒事务数）、读写比例、高峰时段。这关系到新集群的规格设计和性能测试标准。
• 对象与特性依赖：检查存储过程、触发器、视图、自定义函数、特定字符集（如utf8mb4）、隔离级别（如REPEATABLE-READ）的使用情况。Galera对DDL（如ALTER TABLE）和某些锁操作有特殊处理，需提前识别。
• 客户端情况：应用使用的编程语言、MySQL驱动版本、连接池配置（如HikariCP, Druid）。确保驱动支持并正确配置了多主机故障转移。

2. 目标集群设计：

• 节点数量：生产环境至少3个节点，以确保脑裂时能形成多数派。可以根据读写压力和可用性要求考虑5节点。奇数个节点是黄金法则。
• 硬件与存储规划：国产化CPU（如鲲鹏、飞腾）的核心数、内存容量需匹配原性能指标。存储性能至关重要，推荐使用SSD或NVMe硬盘，因为Galera的写集（write-set）复制和认证过程会产生大量的IO。网络建议万兆互联，并确保节点间低延迟（通常要求<1ms）。
• 部署架构：通常所有节点部署在同一数据中心（同城跨机房）以保证低延迟。若需跨地域容灾，需采用特殊架构（如Galera + ProxySQL的多写组），普通同步模式不适用。

3.2 阶段二：国产化环境与Galera集群部署

这是搭建新“房子”的阶段，每一步的扎实程度决定了后续迁移的稳定性。

1. 操作系统与依赖配置：

• 在国产化OS（如麒麟、统信UOS、OpenEuler）上，优先使用其软件源或从Percona/MariaDB官方获取对应架构（aarch64）的二进制安装包。
• 统一所有节点的系统时间，务必配置NTP或Chrony服务进行时间同步，节点间时间差过大可能导致事务认证失败。
• 优化内核参数，特别是vm.swappiness（建议设为1）、net.core.somaxconn等，并确保防火墙开放Galera所需的端口（通常是4567, 4568, 4444）。

2. Galera集群初始化部署：

• 第一个节点（引导节点）：在my.cnf配置文件中，除了常规的MySQL配置外，核心是Galera的配置段：

  [mysqld] wsrep_on=ON wsrep_provider=/usr/lib64/galera-4/libgalera_smm.so wsrep_cluster_name=my_galera_cluster # 集群名称，所有节点一致 wsrep_cluster_address=gcomm:// # 初始节点留空或指定为gcomm:// wsrep_node_name=node1 # 节点唯一名称 wsrep_node_address=192.168.1.101 # 节点IP wsrep_sst_method=xtrabackup-v2 # 状态快照传输方法 wsrep_sst_auth=sstuser:sstpassword # SST传输用户 binlog_format=ROW # 必须为ROW格式 default_storage_engine=InnoDB innodb_autoinc_lock_mode=2 # 建议设置为2，适应多主写入

  启动第一个节点时，需要使用特殊的启动命令来初始化集群：systemctl start [e-mail]或mysqld_safe --wsrep-new-cluster &。
• 后续节点加入：在其他节点上，wsrep_cluster_address需设置为已存在集群节点的地址，如gcomm://192.168.1.101,192.168.1.102。然后正常启动MySQL服务，该节点会自动通过SST（State Snapshot Transfer）从现有节点拉取全量数据并加入集群。

实操心得：wsrep_sst_method推荐使用xtrabackup-v2，它支持热备份，阻塞时间短。务必提前创建好sstuser并授予足够的权限（RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT）。在国产化ARM平台上，务必确认Percona XtraBackup有对应的aarch64版本可用。

3.3 阶段三：数据迁移与同步策略详解

这是迁移的核心阶段，目标是让新集群的数据与原库实时同步，并最终切换。

1. 全量数据迁移（Initial State Transfer, IST）：我们通常不直接在生产Galera集群上做第一次全量，而是先搭建一个临时节点或利用其中一个节点，从原生产库拉取数据。

• 使用Percona XtraBackup：这是最推荐的方式。在原库上执行xtrabackup --backup进行物理备份，将备份文件拷贝到新集群的某个节点上，然后使用xtrabackup --prepare和xtrabackup --copy-back进行恢复。恢复后的数据目录，就包含了原库在备份时刻的一致性数据点以及对应的GTID或二进制日志位置。
• 配置该节点加入集群：在恢复数据的节点上，正确配置Galera并指向已存在的集群地址（如果这是第二个节点）。启动时，Galera的SST机制会识别到本地的数据，并可能跳过全量传输，直接进入增量同步阶段，这比从网络拉取全量快得多。

2. 增量数据追平与同步：全量恢复后，新集群节点上的数据是“静止”在备份时刻的。我们需要让它追平原库从备份点之后产生的所有新数据。

• 建立主从复制通道：此时，不要立即让该节点以Galera成员身份启动。我们可以先将其作为一个普通的MySQL从库，通过传统的基于GTID的主从复制，从原生产库同步增量数据。这样可以将对原库的影响降到最低。
• 追平与切换：当从库的延迟（Seconds_Behind_Master）变为0时，意味着数据已经完全追平。此时，停止从库的IO_THREAD和SQL_THREAD，记录下最终执行的GTID集合。
• 无缝接入Galera集群：修改该节点的配置，将其wsrep_cluster_address指向目标Galera集群，并确保其数据目录下的grastate.dat文件中的seqno值有效（或设为-1以触发SST）。然后启动MySQL服务。由于数据几乎一致，集群通常会采用IST（Incremental State Transfer）传输少量差异数据，该节点便能快速加入集群并进入同步状态。

3.4 阶段四：应用切换与验证

当新集群所有节点数据同步且稳定运行后，就可以进行应用切换了。

1. 切换前最终验证：

• 数据一致性校验：使用pt-table-checksum等工具，对原库和新集群的某个节点进行数据一致性校验。这是一个关键的安全步骤。
• 性能与功能测试：在新集群上模拟业务SQL进行压测，验证响应时间和吞吐量。测试所有关键业务功能，特别是写操作和复杂事务。
• 客户端兼容性测试：确保应用连接新集群的负载均衡器后，连接池、事务、重试机制等工作正常。

2. 灰度切换方案：

• 通过负载均衡器引流：这是最平滑的方式。假设我们使用HAProxy，可以配置后端服务器组包含原库和新集群节点。通过动态调整权重，先将少量只读流量（如报表查询）指向新集群，观察无误后，再将写流量按比例逐步切过来。例如，先切10%的写流量，稳定运行一段时间后再切50%，最后100%切换。
• 修改应用配置：如果不用负载均衡器，也可以分批重启应用实例，更新其数据库连接串为新集群的VIP或域名。采用分批次、分业务模块的灰度发布策略。

3. 切换后监控与回滚准备：

• 切换期间及之后一段时间，密切监控新集群的各项指标：wsrep_flow_control_paused（流控暂停时间，应接近0）、wsrep_local_recv_queue（接收队列长度）、节点状态等。
• 务必准备好回滚方案：在切换初期，原库保持只读或静默状态。一旦新集群出现不可预知的问题，立即将应用连接切回原库。这个回滚窗口期可能需要维持数小时甚至一天。

4. 部署实操：从零构建三节点Galera集群

理论讲完，我们进入实战环节。假设我们要在三个国产化ARM服务器（IP: 192.168.1.101, .102, .103）上，部署Percona XtraDB Cluster 8.0。

4.1 系统准备与依赖安装

在所有三个节点上执行：

1. 配置主机名和hosts：

   # 节点1 hostnamectl set-hostname pxc-node1 # 编辑 /etc/hosts， 添加 192.168.1.101 pxc-node1 192.168.1.102 pxc-node2 192.168.1.103 pxc-node3

2. 关闭SELinux和防火墙或配置规则（生产环境建议配置精确规则）：

   setenforce 0 sed -i 's/^SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config systemctl stop firewalld && systemctl disable firewalld # 或者开放端口：4567, 4568, 4444, 3306

3. 安装依赖包：

   yum install -y socat perl-DBI perl-DBD-MySQL perl-IO-Socket-SSL perl-Time-HiRes

4. 配置时间同步：

   yum install -y chrony systemctl start chronyd && systemctl enable chronyd chronyc sources -v

4.2 安装Percona XtraDB Cluster

1. 配置Percona的YUM源（以CentOS/RHEL系为例，需根据实际国产OS调整）：

   yum install -y https://repo.percona.com/yum/percona-release-latest.noarch.rpm percona-release setup pxc-80

2. 安装PXC 8.0：

   yum install -y percona-xtradb-cluster

   这个包会同时安装MySQL服务器、Galera库以及Percona XtraBackup。

4.3 配置与初始化第一个节点

在pxc-node1 (192.168.1.101)上操作：

1. 编辑配置文件/etc/my.cnf：

   [client] port = 3306 socket = /var/lib/mysql/mysql.sock [mysqld] server-id=1 datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock log-error=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid # 字符集 character-set-server=utf8mb4 collation-server=utf8mb4_unicode_ci # InnoDB设置 innodb_buffer_pool_size=系统内存的50-70% innodb_log_file_size=1G innodb_flush_log_at_trx_commit=1 innodb_autoinc_lock_mode=2 # 二进制日志与GTID (Galera要求) log_bin=mysql-bin binlog_format=ROW gtid_mode=ON enforce_gtid_consistency=ON # Galera 特定配置 wsrep_on=ON wsrep_provider=/usr/lib64/galera-4/libgalera_smm.so wsrep_cluster_name=my_galera_cluster wsrep_cluster_address=gcomm:// # 初始节点留空 wsrep_node_name=pxc-node1 wsrep_node_address=192.168.1.101 wsrep_sst_method=xtrabackup-v2 wsrep_sst_auth=sstuser:s3cretPass wsrep_slave_threads=4 # 根据CPU核心数调整

2. 初始化数据库并启动（引导集群）：

   systemctl start [e-mail] # 或者 mysqld_safe --wsrep-new-cluster &

3. 设置root密码和SST用户：

   mysql -uroot -p # 初始密码在日志文件中 ALTER USER 'root'@'localhost' IDENTIFIED BY 'YourStrongRootPass'; CREATE USER 'sstuser'@'localhost' IDENTIFIED BY 's3cretPass'; GRANT RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'sstuser'@'localhost'; FLUSH PRIVILEGES;

4.4 加入第二和第三个节点

在pxc-node2和pxc-node3上，配置文件与node1类似，关键修改以下几项：

# pxc-node2 的 /etc/my.cnf 部分 server-id=2 wsrep_node_name=pxc-node2 wsrep_node_address=192.168.1.102 wsrep_cluster_address=gcomm://192.168.1.101,192.168.1.102,192.168.1.103 # 列出所有节点 # pxc-node3 的 /etc/my.cnf 部分 server-id=3 wsrep_node_name=pxc-node3 wsrep_node_address=192.168.1.103 wsrep_cluster_address=gcomm://192.168.1.101,192.168.1.102,192.168.1.103

然后，直接在node2和node3上启动MySQL服务即可：

systemctl start mysqld

启动过程中，节点会自动通过wsrep_sst_method指定的方法（xtrabackup-v2）从集群中获取全量数据。观察日志/var/log/mysqld.log，看到类似[Note] [MY-000000] [Galera] Synchronized with group, ready for connections的提示，即表示加入成功。

4.5 验证集群状态

在任何节点上登录MySQL，执行：

SHOW STATUS LIKE 'wsrep%';

关注几个关键状态：

• wsrep_cluster_size: 应为3。
• wsrep_cluster_status: 应为Primary。
• wsrep_connected: 应为ON。
• wsrep_ready: 应为ON。
• wsrep_local_state_comment: 应为Synced。

创建一个测试库表，在其他节点上查询，验证数据是否同步。

5. 迁移实战：将生产单实例数据迁入Galera集群

假设我们有一个运行在192.168.10.100上的生产MySQL 5.7单实例，需要迁移到刚才搭建好的三节点PXC集群。我们采用基于GTID的主从复制+最终接入集群的混合方案，最大化减少停机时间。

5.1 在原生产库上做准备

1. 启用GTID（如果未启用）：

   -- 在my.cnf中配置并重启 gtid_mode=ON enforce_gtid_consistency=ON

2. 创建复制账号：

   CREATE USER 'repl'@'192.168.1.%' IDENTIFIED BY 'ReplPass123'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.%'; FLUSH PRIVILEGES;

3. 进行一次全量备份：

   # 在原生产库服务器上执行 xtrabackup --backup --target-dir=/data/backup/full --user=root --password=YourPass xtrabackup --prepare --target-dir=/data/backup/full

5.2 在Galera集群的一个节点上恢复并建立主从

我们选择pxc-node1作为数据接收和转换的节点，但暂时不将其以Galera模式启动。

1. 传输备份文件并恢复：

   # 在pxc-node1上， 确保MySQL服务已停止， 并清空数据目录 systemctl stop mysqld rm -rf /var/lib/mysql/* # 将原生产库的备份文件拷贝过来 scp -r user@192.168.10.100:/data/backup/full /tmp/ # 恢复数据 xtrabackup --copy-back --target-dir=/tmp/full chown -R mysql:mysql /var/lib/mysql

2. 以单实例模式启动并配置为主从的从库：
   • 临时修改pxc-node1的my.cnf，注释掉所有wsrep_开头的配置，并设置server-id=100（区别于原库）。
   • 启动MySQL：systemctl start mysqld。
   • 配置复制通道：

     CHANGE MASTER TO MASTER_HOST='192.168.10.100', MASTER_USER='repl', MASTER_PASSWORD='ReplPass123', MASTER_AUTO_POSITION=1; START SLAVE; SHOW SLAVE STATUS\G

     确认Slave_IO_Running和Slave_SQL_Running均为Yes，且Seconds_Behind_Master逐渐减少。

5.3 追平数据并切换

1. 等待从库完全追平：监控Seconds_Behind_Master变为0。
2. 停止复制，记录GTID：

   STOP SLAVE; SELECT @@GLOBAL.GTID_EXECUTED; -- 记录下这个值， 例如： ‘source-server-uuid:1-1000’

3. 准备接入Galera集群：
   • 停止MySQL服务：systemctl stop mysqld。
   • 恢复my.cnf中Galera的配置，并将wsrep_cluster_address指向集群（例如gcomm://192.168.1.102,192.168.1.103，因为node1要作为新节点加入）。
   • 为了确保集群识别该节点状态，可以编辑/var/lib/mysql/grastate.dat，将seqno设置为-1，这会在下次启动时强制触发SST。但由于我们数据几乎是最新的，集群更可能采用IST。
4. 启动并加入集群：

   systemctl start mysqld

   观察日志，应该会看到IST或SST的过程。由于数据几乎一致，IST过程会很快。
5. 验证与切换应用：
   • 在集群所有节点上验证数据一致性。
   • 将应用的数据库连接地址，从原来的192.168.10.100改为Galera集群前端的负载均衡器地址（例如HAProxy的VIP）。
   • 先切换只读查询，再切换写操作。密切监控集群状态。

5.4 原库下线与收尾

1. 确认所有应用流量都已切换到新集群，并稳定运行至少一个业务高峰周期。
2. 将原生产库192.168.10.100设置为只读，作为应急回滚的备份，保留一段时间（如一周）。
3. 最终下线原库，完成迁移。

6. 避坑指南与生产环境调优

Galera Cluster很强大，但如果不了解其特性，生产环境很容易踩坑。下面是我在多次迁移和运维中总结的关键点。

6.1 常见问题与解决方案速查表

问题现象	可能原因	排查步骤与解决方案
节点无法加入集群， SST失败	SST认证失败、端口不通、防火墙、磁盘空间不足	1. 检查wsrep_sst_auth用户权限及密码。 2. 检查4567, 4444端口通断及防火墙规则。 3. 检查接收节点数据目录磁盘空间是否足够。
集群状态出现Non-Primary或Disconnected	网络分区、脑裂、超过半数节点失联	1. 检查节点间网络延迟和连通性。 2. 确认存活节点是否构成多数派（>= N/2+1）。 3. 在多数派节点上尝试重启或重新引导集群。
写操作卡住，wsrep_flow_control_paused值很高	慢节点拖慢整个集群，复制跟不上	1. 使用SHOW PROCESSLIST查看是否有慢查询。 2. 检查慢节点的IO/CPU性能，特别是磁盘IO。 3. 优化大事务，拆分为小事务。 4. 适当增加wsrep_slave_threads。
DDL语句（如ALTER TABLE）执行时间极长或导致集群阻塞	Galera对DDL采用TOI（Total Order Isolation）方式，会在所有节点串行执行	1. 避免在业务高峰执行大表DDL。 2. 使用pt-online-schema-change或gh-ost等在线改表工具。 3. 对于MariaDB，可以考虑使用RSU（Rolling Schema Upgrade）方式。
多主写入时出现主键冲突	使用了AUTO_INCREMENT且未正确配置	1. 确保innodb_autoinc_lock_mode=2。 2. 为每个节点设置不同的auto_increment_increment和auto_increment_offset。例如3节点：increment=3,offset分别设为1,2,3。
应用报错Deadlock found when trying to get lock	多主写入下，不同节点并发更新同一行，在认证阶段可能产生死锁	1. 这是Galera的预期行为之一，应用端需要增加重试机制。 2. 优化业务逻辑，减少热点行的并发更新。

6.2 关键性能调优参数

除了基础的InnoDB调优，以下Galera相关参数对性能影响显著：

• wsrep_slave_threads: 处理写集复制的线程数。建议设置为CPU核心数的2-4倍。监控wsrep_local_recv_queue和wsrep_local_send_queue，如果队列持续增长，可适当增加此值。
• wsrep_provider_options: Galera提供者的选项字符串。有几个关键子项：
  • gcache.size: 写集缓存大小，用于存储尚未被其他节点确认的事务。这是最重要的参数之一。建议设置为可用内存的10%-20%，但至少1-2GB。如果wsrep_local_cached_downto经常大于wsrep_gcache_size，说明缓存不足，会导致SST。
  • gcs.fc_limit: 流控阈值。当接收队列超过此值时，触发流控。默认值可能偏小，在高负载下可适当调大，如gcs.fc_limit=256。
  • socket.ssl: 如果节点跨公网或不可信网络，务必设置为YES并配置SSL证书，保证数据传输安全。
• innodb_flush_log_at_trx_commit&sync_binlog: 为了极致性能，有些场景会将其设为2或0，但这在Galera下可能增加故障恢复的复杂度。对于要求强一致性的场景，建议保持默认值1。

6.3 监控要点

一个健康的Galera集群需要持续监控。除了常规的MySQL指标（连接数、QPS、慢查询、InnoDB状态），必须关注以下Galera特有指标：

1. 集群健康度：wsrep_cluster_size,wsrep_cluster_status,wsrep_connected。
2. 节点状态：wsrep_ready,wsrep_local_state_comment(应为Synced)。
3. 流控与延迟：wsrep_flow_control_paused（应长期接近0），wsrep_local_recv_queue（接收队列长度，应接近0）。
4. 复制性能：wsrep_cert_deps_distance（平均并行度），wsrep_apply_oooe（应用队列乱序率）。
5. GCache状态：wsrep_gcache_size,wsrep_local_cached_downto。确保缓存足够，避免频繁的SST。

可以使用Prometheus +mysqld_exporter+percona提供的Galera监控指标，配合Grafana制作专属监控看板。

6.4 备份策略

Galera集群每个节点数据一致，因此可以从任何一个节点进行备份。但备份操作本身可能触发SST或影响性能。

• 推荐使用Percona XtraBackup：在从节点上执行备份，并添加--galera-info选项，它会记录备份时刻的Galera GTID位置，便于后续搭建从库或恢复。
• 避免在所有节点同时备份：错开备份时间，并尽量在业务低峰期进行。
• 定期测试恢复：备份的有效性必须通过恢复演练来验证。模拟单个节点故障，从备份恢复并重新加入集群。

国产化迁移是一项系统工程，数据库迁移是其中的关键战役。采用MySQL Galera Cluster方案，不仅实现了数据的平滑迁移，更是一步到位地构建了一个高可用、强一致、可扩展的数据库架构，为业务在国产化平台上的稳定运行奠定了坚实基础。整个过程中，最深的体会是：充分的评估测试、清晰的切换预案、以及细粒度的监控，比任何技术选型都更重要。技术方案解决的是“能不能做”的问题，而这些过程保障解决的则是“能不能做好”和“出问题怎么办”的问题。希望这篇基于实战的拆解，能帮助你在自己的国产化迁移之路上，走得更加稳健。