企业官网建设流程全解析

1. MySQL高可用架构核心设计解析

在企业级数据库应用中，单点故障是绝对不能容忍的风险。我经历过多次深夜被叫醒处理数据库宕机的惨痛教训后，彻底认识到高可用架构的重要性。本次搭建的MySQL高可用方案采用主主复制+HAProxy+Keepalived的组合，这个架构在电商、金融等行业经过多年实战检验，能实现99.99%的可用性。

这套架构的核心优势在于：

• 数据层：通过MySQL主主复制实现双向数据同步，任何一台服务器故障时，另一台可立即接管
• 访问层：HAProxy作为智能流量分发器，自动将请求路由到健康的MySQL节点
• 高可用层：Keepalived实现VIP漂移，确保客户端始终通过同一个虚拟IP访问服务

重要提示：主主复制不是简单的互为主从，需要特别注意自增ID冲突问题。我建议采用奇偶分配策略（node1用奇数ID，node2用偶数ID），这个技巧在实际运维中非常实用。

2. MySQL主主复制深度配置

2.1 服务器基础环境准备

我推荐使用CentOS 7.9作为操作系统，以下是两台服务器的基本配置要求：

• CPU：至少4核（建议8核）
• 内存：16GB起步（重要生产环境建议32GB+）
• 磁盘：SSD阵列，RAID10配置
• 网络：千兆内网互联

安装MySQL 8.0时特别注意：

# 禁用默认的密码强度检查（初期配置阶段可临时关闭） sudo systemctl set-environment MYSQLD_OPTS="--validate-password=OFF" # 安装MySQL社区版 sudo yum install -y mysql-community-server

2.2 主主复制核心配置

在/etc/my.cnf中需要配置的关键参数（以node1为例）：

[mysqld] server-id = 1 log_bin = mysql-bin binlog_format = ROW binlog_row_image = FULL auto_increment_increment = 2 auto_increment_offset = 1 gtid_mode = ON enforce_gtid_consistency = ON binlog_group_commit_sync_delay = 100 binlog_group_commit_sync_no_delay_count = 10

node2的配置差异点：

server-id = 2 auto_increment_offset = 2 # 关键区别点

配置完成后需要执行的命令：

-- 在node1执行 CREATE USER 'repl'@'%' IDENTIFIED BY 'ComplexPassword123!'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%'; SHOW MASTER STATUS\G -- 在node2执行 CHANGE MASTER TO MASTER_HOST='node1_ip', MASTER_USER='repl', MASTER_PASSWORD='ComplexPassword123!', MASTER_AUTO_POSITION=1; START SLAVE;

2.3 复制状态监控技巧

我习惯使用这套监控命令组合：

SHOW SLAVE STATUS\G SELECT * FROM performance_schema.replication_group_members; SELECT @@hostname, NOW();

常见问题处理经验：

1. 遇到1062主键冲突时，先检查auto_increment配置
2. 网络闪断导致复制中断，优先使用START SLAVE UNTIL SQL_AFTER_GTIDS
3. 大事务导致延迟，建议拆分为小事务

3. HAProxy负载均衡实战

3.1 高性能配置模板

这是经过生产验证的haproxy.cfg核心配置：

global maxconn 4096 tune.ssl.default-dh-param 2048 defaults mode tcp timeout connect 5000ms timeout client 50000ms timeout server 50000ms listen mysql-cluster bind *:3306 balance leastconn option mysql-check user haproxy_check server mysql1 node1_ip:3306 check inter 2000 rise 2 fall 3 server mysql2 node2_ip:3306 check inter 2000 rise 2 fall 3

3.2 健康检查优化

MySQL健康检查的进阶配置技巧：

option mysql-check user haproxy_check post-41 # 在MySQL创建专用监控账号 CREATE USER 'haproxy_check'@'haproxy_ip' IDENTIFIED BY 'check_password';

3.3 流量分发策略对比

我测试过的几种算法效果：

实测建议：Web应用用leastconn，数据分析类用source

4. Keepalived高可用实现

4.1 双机热备配置

keepalived.conf关键配置：

vrrp_script chk_haproxy { script "killall -0 haproxy" interval 2 weight 50 } vrrp_instance VI_1 { interface eth0 state MASTER virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { vip_ip/24 dev eth0 } track_script { chk_haproxy } }

4.2 脑裂预防方案

我总结的防脑裂 checklist：

1. 确保防火墙允许VRRP协议（IP协议号112）
2. 配置多播心跳检测
3. 设置优先级差至少20
4. 部署第三方仲裁脚本

4.3 故障切换实测

模拟主节点宕机的正确姿势：

# 不推荐直接kill -9，应该优雅测试 sudo systemctl stop keepalived # 观察日志时间戳 tail -f /var/log/messages | grep Keepalived

切换时间优化技巧：

• advert_int从默认1改为0.5秒
• preempt_delay设置为5秒
• 配合HAProxy的fastinter参数

5. 生产环境调优经验

5.1 性能基准测试

我用sysbench做的对比测试结果：

sysbench oltp_read_write \ --db-driver=mysql \ --mysql-host=vip_ip \ --mysql-port=3306 \ --mysql-user=test \ --mysql-password=test \ --mysql-db=sbtest \ --tables=10 \ --table-size=100000 \ --threads=32 \ --time=300 \ --report-interval=10 \ prepare

关键指标优化前后对比：

5.2 监控体系搭建

我必装的监控项：

1. 复制延迟（seconds_behind_master）
2. 线程连接数（Threads_connected）
3. 缓冲池命中率（innodb_buffer_pool_reads/requests）
4. HAProxy的session当前队列

推荐使用这个Grafana监控SQL：

SELECT UNIX_TIMESTAMP(create_time) as time_sec, threads_connected as value, 'connections' as metric FROM sys.session WHERE program_name='sysbench'

5.3 应急预案清单

必须准备好的四个场景：

1. 主节点宕机：验证VIP切换时间
2. 网络分区：测试脑裂处理
3. 复制中断：演练数据修复流程
4. HAProxy崩溃：检查Keepalived接管情况

每次升级前必做的检查：

mysql -h vip_ip -e "SHOW VARIABLES LIKE 'version%'" haproxy -vv | grep Version keepalived --version

这套架构在真实业务场景中，曾经帮助我们实现过年故障时间不超过5分钟的记录。关键是要定期做故障演练，我建议至少每季度做一次完整的断网测试。