Galera集群实战:构建强一致性的MySQL多主同步架构
1. 为什么需要Galera集群当你的MySQL数据库需要支撑核心业务时单点故障就像悬在头顶的达摩克利斯之剑。我经历过一次惨痛的教训某次服务器宕机导致电商平台停摆3小时直接损失上百万订单。传统的主从复制方案在故障切换时存在数据不一致风险而Galera提供的多主同步架构彻底解决了这个问题。Galera集群本质上是一组可以同时读写的MySQL节点任何节点的写入都会实时同步到其他节点。这种架构特别适合需要高可用的场景金融系统的转账交易必须保证数据强一致性电商大促期间需要多个节点同时承担读写流量实时报表系统要求所有节点数据完全同步提示Galera的同步复制机制不同于MySQL原生的异步复制它能确保事务在所有节点提交成功后才向客户端返回成功。2. 环境准备与基础配置2.1 硬件与网络要求在阿里云实际部署时我发现这些配置最稳定服务器规格至少4核8GSSD存储建议ESSD云盘网络延迟节点间ping值要稳定在1ms以内系统优化需要关闭透明大页和调整swappiness# 检查透明大页状态 cat /sys/kernel/mm/transparent_hugepage/enabled # 永久关闭方法需要重启 echo never /sys/kernel/mm/transparent_hugepage/enabled2.2 软件安装要点通过官方仓库安装最稳定以CentOS 7为例# 添加MariaDB官方仓库 cat /etc/yum.repos.d/MariaDB.repo EOF [mariadb] name MariaDB baseurl http://yum.mariadb.org/10.5/centos7-amd64 gpgkeyhttps://yum.mariadb.org/RPM-GPG-KEY-MariaDB gpgcheck1 EOF # 安装Galera和MySQL服务 yum install MariaDB-server MariaDB-client galera-43. 集群初始化实战3.1 首次启动的坑点第一次启动集群时必须确保所有节点数据目录为空。我曾在测试环境因为残留数据导致SST同步失败。正确的启动顺序应该是在主节点执行galera_new_cluster systemctl start mysql在其他节点执行systemctl start mysql注意如果看到日志中出现WSREP: Failed to prepare for incremental state transfer很可能是防火墙阻止了4567端口通信。3.2 关键参数调优这些参数经过生产环境验证[mysqld] # 基础配置 binlog_formatROW default_storage_engineInnoDB innodb_autoinc_lock_mode2 # Galera核心配置 wsrep_provider/usr/lib64/galera-4/libgalera_smm.so wsrep_cluster_namemy_galera_cluster wsrep_cluster_addressgcomm://node1_ip,node2_ip,node3_ip wsrep_node_addresscurrent_node_ip wsrep_sst_methodmariabackup wsrep_sst_authsst_user:password # 性能优化 wsrep_slave_threads16 wsrep_trx_fragment_unitbytes wsrep_trx_fragment_size10240004. 生产环境运维技巧4.1 监控指标解读这几个指标最能反映集群健康状态wsrep_flow_control_paused大于0.1说明有节点跟不上同步速度wsrep_local_recv_queue持续高于100要考虑增加wsrep_slave_threadswsrep_cluster_size突然减少意味着有节点掉线我习惯用这个命令做实时监控watch -n 1 mysql -e SHOW STATUS LIKE \wsrep%\; | grep -E cluster_size|ready|flow_control|recv_queue4.2 脑裂处理实战当网络分区发生时Galera可能出现脑裂split-brain。去年我们机房光纤被挖断时就遇到了这种情况。正确的处理步骤是确认各分区状态SHOW STATUS LIKE wsrep%;选择包含多数节点的分区作为主分区在其他分区节点执行systemctl stop mysql galera_recovery systemctl start mysql5. 性能优化进阶5.1 批量写入优化处理大批量导入时建议采用这些技巧将大事务拆分为多个小事务每批1000条左右使用LOAD DATA INFILE代替INSERT语句临时调整参数SET GLOBAL wsrep_osu_methodTOI; -- 改为total order isolation SET GLOBAL innodb_flush_log_at_trx_commit2;5.2 跨机房部署方案在上海和深圳机房部署时我们这样优化使用wsrep_provider_options调整网络超时wsrep_provider_optionsevs.inactive_timeoutPT30S; evs.suspect_timeoutPT10S; gmcast.peer_timeoutPT3S启用压缩减少带宽消耗wsrep_provider_optionscompressionlz46. 常见故障排查6.1 SST失败处理上周刚解决一个SST卡住的问题排查步骤供参考检查donor节点日志tail -f /var/log/mysql/error.log | grep -i sst验证认证信息SELECT * FROM mysql.user WHERE Usersst_user;手动执行备份测试mariabackup --backup --usersst_user --passwordxxx --target-dir/backup6.2 长事务阻塞遇到一个UPDATE语句执行2小时导致整个集群卡顿。应急方案找出阻塞事务SELECT * FROM information_schema.processlist WHERE TIME 60 ORDER BY TIME DESC;临时调大flow control阈值SET GLOBAL wsrep_flow_control_threshold131072;7. 最佳实践总结经过3年生产环境验证这些经验特别重要集群规模不要超过9个节点3-5个节点是最佳平衡点定期执行CHECK TABLE预防数据不一致升级时采用滚动更新方式先升级从节点再升主节点监控磁盘空间SST过程需要1.5倍原数据大小的空间某次大促前我们通过调整这些参数扛住了3倍日常流量wsrep_slave_threads32 innodb_buffer_pool_size48G wsrep_flow_control_threshold262144