在刚刚过去的“618”促销活动期间，我们电商系统的订单激增数倍，MySQL单点服务在高并发写入下直接崩溃，业务读写阻塞导致前端接口全面雪崩。尽管已有定时备份机制，但恢复慢、数据滞后，最终造成用户支付失败、库存错乱。那次事故之后，我决心在香港的两台物理服务器上构建MySQL双主互备架构，以实现高可用、高并发写入下的业务连续性保障。
本文将基于两台香港物理机节点，通过双主复制 + VIP漂移 + 自动Failover的方式，实操搭建一套高可用MySQL主主架构，并涵盖GTID复制、冲突规避、故障自动切换等关键环节。
一、部署架构总览
- 物理机A（香港节点1）：192.168.100.10
- 物理机B（香港节点2）：192.168.100.11
- VIP地址：192.168.100.100
- MySQL版本：8.0.36
- 复制方式：GTID-Based Master-Master
- 高可用组件：Keepalived（VIP漂移）、MHA或自研脚本（Failover）
[ Client Layer ]
|
VIP: 192.168.100.100
|
------------------------------
| |
MySQL-A MySQL-B
192.168.100.10 192.168.100.11
双向GTID复制 + Keepalived互斥漂移
二、物理机准备与MySQL安装
2.1 系统内核与参数调整（两节点一致）
# 降低swappiness，避免触发OOM
sysctl -w vm.swappiness=1
# 文件句柄数量
ulimit -n 65535
# 写入 /etc/security/limits.conf 持久化
2.2 安装MySQL 8.0并初始化
dnf install mysql-server -y
systemctl enable mysqld --now
初始化后，修改/etc/my.cnf核心配置：
[mysqld]
server-id=10 # Node A 设置为10，Node B为11
gtid_mode=ON
enforce-gtid-consistency=ON
log-bin=mysql-bin
binlog-format=ROW
skip-name-resolve=1
log_slave_updates=1
relay_log=relay-bin
auto_increment_increment=2
auto_increment_offset=1 # A节点为1，B节点设置为2
避免自增主键冲突：双主时自增冲突风险极高，建议用offset+increment方案规避。
三、建立GTID主主复制链路
3.1 创建复制账户（双节点互建）
CREATE USER 'repl'@'%' IDENTIFIED BY 'ReplPass123!';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
3.2 互设对方为主（必须等数据同步一致）
在A节点：
CHANGE MASTER TO
MASTER_HOST='192.168.100.11',
MASTER_USER='repl',
MASTER_PASSWORD='ReplPass123!',
MASTER_AUTO_POSITION=1;
START SLAVE;
在B节点：
CHANGE MASTER TO
MASTER_HOST='192.168.100.10',
MASTER_USER='repl',
MASTER_PASSWORD='ReplPass123!',
MASTER_AUTO_POSITION=1;
START SLAVE;
验证：
SHOW SLAVE STATUS\G
# 需确保两个节点的 Slave_IO_Running 与 Slave_SQL_Running 都为 Yes
四、Keepalived实现VIP高可用
4.1 安装并配置Keepalived（两节点）
dnf install keepalived -y
节点A配置 /etc/keepalived/keepalived.conf：
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 150
advert_int 1
authentication {
auth_type PASS
auth_pass 123456
}
virtual_ipaddress {
192.168.100.100
}
}
节点B配置：
vrrp_instance VI_1 {
state BACKUP
interface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 123456
}
virtual_ipaddress {
192.168.100.100
}
}
启动服务：
systemctl enable keepalived --now
验证：
ip a | grep 192.168.100.100
# 仅主节点持有VIP
五、故障自动切换机制（选配）
我使用了自研Bash脚本结合cron + systemd watchdog实现Failover自动漂移。更成熟方案如MHA（MySQL High Availability）也可选用：
- 当MySQL主服务宕机
- 启动Keepalived状态切换
- 副本节点提升为写主
- 原主节点恢复后退化为备节点
核心逻辑示例（简化版）：
#!/bin/bash
if ! mysqladmin ping -h 127.0.0.1 --silent; then
systemctl stop keepalived
fi
搭配systemd自动执行。
六、冲突与风险控制策略
双主虽然高可用，但存在天然一致性挑战，我在实践中采用了以下策略避免脏写：
- 写入路由控制：前端业务只将写请求发送到VIP绑定主节点；
- 定时数据校验：使用pt-table-checksum定期比对主主数据一致性；
- 避免多处写入同表：高并发写操作的业务必须串行化分布至一主写。
七、压测结果与业务收益
在部署完成后，我使用Sysbench对双主集群进行压测：
- 并发读写（16线程）：TPS 提升至原单点MySQL的 2.1倍
- 节点任意宕机切换耗时：VIP漂移在 1.5秒内完成
- 订单写入中断时间控制在 2 秒内，满足 SLA
- 系统稳定性大幅提升，客服投诉率下降明显。
MySQL双主复制并非银弹，但在资源成本有限、业务可控的前提下，是一套兼顾高可用性与实时性的实践方案。借助香港高带宽物理机稳定的网络环境和低延迟内网互联，我们构建了一套在业务高峰依旧坚挺的数据库核心平台。未来也可考虑引入ProxySQL+MySQL Group Replication进一步增强写入路由与冲突自动化处理能力。
