MariaDB Galera Cluster部署与高可用实践指南

1. MariaDB Galera Cluster 核心价值解析

在当今数据驱动的业务环境中，数据库高可用性已成为基础设施的刚性需求。传统主从复制架构在故障切换时存在数据不一致和人工干预成本高的问题，而MariaDB Galera Cluster提供的多主同步复制方案彻底改变了这一局面。我曾在金融支付系统中部署过该方案，实测故障自动恢复时间可控制在10秒内，业务完全无感知。

Galera Cluster的核心机制在于其真正的多主架构——所有节点均可读写，且通过wsrep API实现行级同步复制。与常规异步复制不同，任何节点提交的事务都会通过认证方式广播到集群，只有当多数节点确认后才会提交。这种同步复制机制确保了数据的强一致性，避免了脑裂情况的发生。

2. 环境规划与系统准备

2.1 硬件资源配置建议

根据生产环境经验，建议采用以下配置：

• 节点数量：至少3个（满足quorum要求）
• 内存：每节点不低于8GB（针对中型业务）
• 存储：建议SSD阵列，RAID10配置
• 网络：万兆互联，延迟<1ms

bash复制# 系统参数调优示例（CentOS 7）
echo "net.ipv4.tcp_tw_recycle = 1" >> /etc/sysctl.conf
echo "net.core.somaxconn = 16384" >> /etc/sysctl.conf
sysctl -p

2.2 操作系统级优化

部署前需确保：

1. 关闭透明大页（THP）
2. 配置正确的swapiness值（建议10-30）
3. 时间同步服务必须启用（NTP或chrony）

重要提示：所有节点系统时间偏差必须控制在1秒内，否则会导致集群状态异常。

3. MariaDB 10.6集群部署实战

3.1 软件仓库配置

bash复制# MariaDB官方仓库设置（CentOS）
cat > /etc/yum.repos.d/mariadb.repo <<EOF
[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/10.6/centos7-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1
EOF

3.2 核心组件安装

bash复制yum install -y MariaDB-server MariaDB-client galera-4 rsync

安装后需特别注意：

• galera-4包提供wsrep补丁
• 默认不安装SST传输工具（如xtrabackup需单独安装）

3.3 集群配置文件详解

/etc/my.cnf.d/server.cnf关键配置段：

ini复制[galera]
wsrep_on=ON
wsrep_provider=/usr/lib64/galera-4/libgalera_smm.so
wsrep_cluster_address="gcomm://node1_ip,node2_ip,node3_ip"
wsrep_cluster_name='production_cluster'
wsrep_node_address='current_node_ip'
wsrep_node_name='node1'
wsrep_sst_method=rsync
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2

配置要点解析：

• wsrep_sst_method：初始状态传输方式，生产环境建议xtrabackup
• innodb_autoinc_lock_mode=2：多主写入必须配置
• 每个节点的wsrep_node_name必须唯一

4. 集群启动与状态管理

4.1 引导集群流程

首节点启动：

bash复制galera_new_cluster
systemctl start mariadb

其他节点加入：

bash复制systemctl start mariadb

验证命令：

sql复制SHOW STATUS LIKE 'wsrep%';

关键状态指标说明：

• wsrep_ready: ON表示可正常处理请求
• wsrep_cluster_size: 当前集群节点数
• wsrep_local_state_comment: Synced表示同步正常

4.2 集群维护操作

安全重启流程：

1. 确认无写入请求
2. 按顺序停止节点：最后停止首节点
3. 启动时首节点必须用galera_new_cluster

5. 生产环境优化策略

5.1 性能调优参数

ini复制innodb_buffer_pool_size = 6G  # 物理内存的70-80%
innodb_log_file_size = 2G
wsrep_slave_threads = 16  # CPU核心数的2-4倍
wsrep_provider_options="gcache.size=4G"  # 建议2-4G

5.2 监控方案实施

推荐监控指标：

1. 集群状态（wsrep_cluster_status）
2. 流控次数（wsrep_flow_control_paused）
3. 复制延迟（wsrep_local_recv_queue_avg）

Prometheus监控示例配置：

yaml复制- job_name: 'mariadb_galera'
  static_configs:
    - targets: ['node1:9104', 'node2:9104']
  metrics_path: '/metrics'

6. 故障处理与常见问题

6.1 典型故障场景

脑裂情况处理：

1. 确认各节点网络连通性
2. 选择数据最新的节点作为主节点
3. 其他节点需清空datadir后重新加入

SST失败处理：

1. 检查防火墙规则（需开放4567, 4444端口）
2. 验证认证文件权限
3. 检查磁盘空间是否充足

6.2 状态恢复命令集

sql复制-- 强制重置本地节点状态
SET GLOBAL wsrep_provider_options='pc.bootstrap=YES';

-- 查看冲突事务
SHOW STATUS LIKE 'wsrep_last_committed%';

7. 安全加固措施

7.1 通信加密配置

生成SSL证书：

bash复制openssl req -newkey rsa:2048 -nodes -keyout galera-key.pem -x509 -days 365 -out galera-cert.pem

配置项追加：

ini复制wsrep_provider_options="socket.ssl_cert=/path/to/galera-cert.pem;socket.ssl_key=/path/to/galera-key.pem"

7.2 访问控制策略

建议配置：

1. 限制galera端口（4567/tcp）的源IP
2. 为SST操作创建专用账户
3. 启用数据库审计插件

8. 备份与恢复方案

8.1 物理备份策略

使用xtrabackup进行热备：

bash复制innobackupex --user=backup_user --password=xxx --no-timestamp /backup_path

8.2 集群扩容流程

新节点加入步骤：

1. 安装相同版本软件
2. 配置相同my.cnf（修改node_name）
3. 启动时自动同步数据

9. 版本升级注意事项

滚动升级原则：

1. 从非主节点开始升级
2. 每次只升级一个节点
3. 验证兼容性后再继续

升级检查清单：

• 确认wsrep_provider版本兼容
• 检查SQL模式变更影响
• 验证存储引擎兼容性

我在实际运维中发现，Galera Cluster对DDL操作特别敏感。建议在业务低峰期执行表结构变更，并预先在测试环境验证。曾经因为一个ALTER TABLE操作导致整个集群性能下降，最终通过调整wsrep_desync参数临时解决。