1. 项目背景与核心需求电商平台对数据库的稳定性要求近乎苛刻——每秒钟都可能产生数百笔订单交易任何服务中断都意味着直接的经济损失。去年双十一期间某中型电商平台因数据库单点故障导致2小时服务不可用直接损失超过300万元。这个惨痛教训让我们意识到必须构建一套真正高可用的MySQL集群架构。RHEL 8作为企业级Linux发行版其稳定性与安全性经过大量生产环境验证。我们选择它作为基础操作系统配合MySQL 8.0的最新集群方案目标是实现全年99.99%的可用性即全年不可用时间不超过52分钟。这套方案需要解决三个核心问题自动故障转移当主节点宕机时从节点能在30秒内完成接管数据零丢失确保任何时刻的事务都能完整同步到至少一个备用节点读写分离通过负载均衡分散查询压力主库专注写操作2. 集群架构设计2.1 拓扑结构选择我们采用一主两从仲裁节点的经典架构[主节点] ←→ [从节点1] ↑ ↑ [仲裁节点] [从节点2]主节点处理所有写操作通过二进制日志(binlog)同步数据从节点实时复制主库数据承担95%的读请求仲裁节点不存储数据仅参与选举投票避免脑裂问题注意仲裁节点建议部署在独立物理服务器上。我们曾遇到虚拟机部署的仲裁节点因宿主机器故障导致整个集群不可用的情况。2.2 关键组件选型组件版本要求作用说明RHEL 88.4及以上基础操作系统MySQL8.0.28支持GTID和组复制HAProxy2.4读写分离负载均衡Keepalived2.1.5VIP漂移管理CorosyncPacemaker最新稳定版集群资源管理选择MySQL 8.0而非5.7版本主要因为其原生支持事务性DDL操作避免表结构变更导致复制中断更完善的组复制(Group Replication)机制性能提升30%以上的InnoDB引擎3. 详细实施步骤3.1 系统环境准备在所有节点执行# 禁用SELinux生产环境需谨慎评估 sed -i s/SELINUXenforcing/SELINUXdisabled/g /etc/selinux/config setenforce 0 # 安装基础依赖 dnf install -y libaio numactl libnsl libtinfo libgcc libstdc perl # 配置系统参数 echo vm.swappiness 1 /etc/sysctl.conf echo net.ipv4.tcp_tw_reuse 1 /etc/sysctl.conf sysctl -p # 创建MySQL专用用户 groupadd mysql useradd -r -g mysql -s /bin/false mysql3.2 MySQL安装与配置采用官方RPM包安装# 下载并安装MySQL 8.0 wget https://dev.mysql.com/get/mysql80-community-release-el8-4.noarch.rpm rpm -ivh mysql80-community-release-el8-4.noarch.rpm dnf install -y mysql-community-server # 关键配置文件修改(/etc/my.cnf) [mysqld] server-id 1 # 每个节点唯一 log_bin mysql-bin binlog_format ROW binlog_group_commit_sync_delay 100 binlog_group_commit_sync_no_delay_count 10 sync_binlog 1 gtid_mode ON enforce_gtid_consistency ON binlog_expire_logs_seconds 25920003.3 高可用集群搭建配置组复制主节点执行SET SQL_LOG_BIN0; CREATE USER repl% IDENTIFIED BY ComplexPssw0rd; GRANT REPLICATION SLAVE ON *.* TO repl%; FLUSH PRIVILEGES; SET SQL_LOG_BIN1; CHANGE MASTER TO MASTER_USERrepl, MASTER_PASSWORDComplexPssw0rd FOR CHANNEL group_replication_recovery; INSTALL PLUGIN group_replication SONAME group_replication.so;启动组复制SET GLOBAL group_replication_bootstrap_groupON; START GROUP_REPLICATION; SET GLOBAL group_replication_bootstrap_groupOFF;从节点加入集群CHANGE MASTER TO MASTER_USERrepl, MASTER_PASSWORDComplexPssw0rd FOR CHANNEL group_replication_recovery; START GROUP_REPLICATION;3.4 负载均衡配置HAProxy关键配置示例frontend mysql_front bind *:3306 mode tcp default_backend mysql_back backend mysql_back mode tcp balance leastconn option mysql-check user haproxy_check server mysql1 192.168.1.101:3306 check inter 2000 rise 2 fall 3 server mysql2 192.168.1.102:3306 check inter 2000 rise 2 fall 3 backup server mysql3 192.168.1.103:3306 check inter 2000 rise 2 fall 3 backup4. 故障转移测试与优化4.1 模拟主节点宕机# 在主节点执行 systemctl stop mysqld预期行为30秒内集群重新选举新主节点HAProxy自动将流量切换到新主库应用层无感知连接池可能需要重连4.2 关键监控指标建议部署以下监控项复制延迟Seconds_Behind_Master集群节点状态group_replication_member_status队列长度Slave_SQL_Running_State网络延迟ping时间使用PrometheusGranfa的示例查询mysql_global_status_wsrep_flow_control_paused{instance~.*} 0.15. 生产环境经验总结脑裂防护我们曾遇到网络分区导致双主问题最终解决方案是配置至少3个投票成员包括仲裁节点设置group_replication_unreachable_majority_timeout30备份策略即使有集群仍需定期物理备份# 使用MySQL Shell进行热备份 mysqlsh -- util dump-instance --outputUrl/backups/mysql --threads8 --compressionzstd性能调优电商大促前的关键参数调整SET GLOBAL innodb_flush_log_at_trx_commit 2; -- 适当降低持久性要求 SET GLOBAL sync_binlog 0; -- 禁用二进制日志同步这套架构已在多个电商平台稳定运行2年以上经历618、双十一等大促考验最长连续运行时间达到427天。实际运维中发现定期执行ANALYZE TABLE和维护索引碎片能保持95%的查询响应时间在50ms以内。