Ubuntu 18.04 下 Galera 集群高可用部署与调优实战

1. 为什么在 Ubuntu 18.04 上坚持用 Galera 而不是原生 MySQL Group Replication？

Galera Cluster 不是 MySQL 的一个“插件”，而是一套独立演进、深度耦合的同步复制协议实现。很多人第一次接触时会下意识把它和 MySQL 8.0 自带的 Group Replication（MGR）划等号，甚至觉得“既然官方出了，何必再折腾第三方”。我在 2019 年给一家电商 SaaS 做高可用架构升级时就踩过这个认知坑——当时团队花两周把 MGR 部署上线，结果在一次促销压测中，订单服务连续三次因“事务回滚率突增 37%”触发熔断。事后复盘发现，MGR 的流控机制在写入密集型场景下存在不可忽视的延迟累积效应，而 Galera 的认证失败（Certification Failure）反馈路径更短、更确定。

Ubuntu 18.04 这个发行版选择本身就有明确指向性：它处于 LTS 生命周期中期（2018.04–2023.04），内核为 4.15，glibc 版本稳定在 2.27，MySQL 官方对它的二进制包支持完整，且社区长期验证了 Percona XtraDB Cluster（PXC）与 MariaDB Galera Cluster 在该系统上的兼容性边界。我实测过，在同一台 32GB 内存、8 核 CPU 的物理服务器上，用 Ubuntu 18.04 + MySQL 5.7.36 + Galera 3.28 的组合，单节点写入吞吐可稳定在 12,800 TPS；换成 Ubuntu 20.04 后，因内核调度器变更和 NUMA 策略调整，同等配置下首次启动集群耗时多出 4.3 秒，且在 10 分钟压力测试后出现一次非预期的 IST（Incremental State Transfer）中断——这不是 Galera 的 bug，而是底层 OS 行为变化引发的连锁反应。

Galera 的核心价值不在于“多活”，而在于 强一致性下的故障透明性 。它通过全局顺序广播（GCache）+ 认证复制（Certification-based Replication）确保所有节点执行完全相同的事务序列。这意味着：当你在 Node1 执行 INSERT INTO orders VALUES (1001, 'pending') ，Node2 和 Node3 不是“稍后收到这条 SQL”，而是 在同一逻辑时间点，基于完全一致的集群状态，独立完成事务认证并提交 。这种机制天然规避了异步复制中的“主从延迟”和半同步复制中的“确认抖动”，也彻底消除了 MGR 中常见的“view change timeout”导致的脑裂风险。你不需要写复杂的故障检测脚本，也不需要依赖外部仲裁节点（如 Pacemaker），只要三个节点中有两个在线，集群就能自动恢复服务——这是它在金融、计费、库存类业务中被反复选用的根本原因。

提示：Galera 不是万能的。它对大事务（> 2MB）、长事务（> 60s）、DDL 操作（尤其是 ALTER TABLE ... ENGINE=InnoDB ）极其敏感。我在某次迁移中曾因一条未加 pt-online-schema-change 包装的 ADD COLUMN 语句，导致整个集群卡死 117 秒。这不是配置问题，而是 Galera 协议层的设计约束：DDL 必须在所有节点串行化执行，期间阻塞所有写入。这一点必须在架构设计初期就写进技术评审 checklist。

2. Ubuntu 18.04 环境准备：那些被忽略却决定成败的系统级配置

很多教程直接跳到 apt install mysql-server ，但 Galera 对 Ubuntu 底层环境的要求远超普通 MySQL。我见过太多案例：集群看似启动成功，运行一周后突然全部挂掉，日志里只有一行 WSREP: gcs/src/gcs_group.cpp:gcs_group_handle_join_msg():1250: Will never receive state transfer from any group member —— 这其实是系统资源限制触发的静默失败。

2.1 内核参数调优：不只是 net.core.somaxconn

Galera 节点间通信高度依赖 TCP 连接池和内存缓冲区。默认的 Ubuntu 18.04 内核参数在高并发下会成为瓶颈。你需要在 /etc/sysctl.conf 中追加以下内容：

# 提升连接队列长度，避免 SYN Flood 导致握手失败
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 5000

# 减少 TIME_WAIT 状态占用，加速端口复用（Galera 使用 4567/4568 端口）
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_tw_reuse = 1

# 关键：增大 TCP 接收/发送缓冲区，直接影响 IST 和 SST 速度
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 262144 16777216
net.ipv4.tcp_wmem = 4096 262144 16777216

# 禁用 IPv6（除非你明确需要），避免 Galera 绑定错误
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

执行 sudo sysctl -p 生效后，务必验证： sysctl net.core.rmem_max 应返回 16777216 。我曾在一个客户现场发现， /etc/sysctl.conf 修改后未执行 sysctl -p ，集群在负载升高时频繁触发 gcs failed to recv data 错误，排查三天才发现是缓冲区仍为默认的 212992 字节。

2.2 文件系统与磁盘 I/O：ext4 还是 XFS？必须选 XFS

Ubuntu 18.04 默认文件系统是 ext4，但它在高并发小文件写入场景下存在元数据锁竞争问题。Galera 的 GCache（环形缓冲区）和 SST（State Snapshot Transfer）过程会产生大量 4KB~64KB 的随机写，ext4 的 journal 机制在此类负载下会导致 iowait 持续高于 40%。我们对比测试过：

XFS 的延迟优势来自其 B+Tree 目录索引和延迟分配（delayed allocation）策略。切换方法很简单：备份数据后，用 mkfs.xfs -f /dev/sdb1 重新格式化数据盘，挂载时指定 noatime,inode64,swalloc