MySQL高可用-EW帮帮网

‌业务连续性‌
- 避免单点故障（SPOF），保障核心业务在服务器宕机、网络中断等场景下的持续运行（如电商交易、金融支付）。
- 典型需求：年停机时间 < 5分钟（99.999% 可用性）。
‌数据可靠性‌
- 通过数据冗余（复制、共享存储）确保数据不丢失，尤其在灾难场景（如机房断电）中恢复能力。
‌负载均衡与扩展性‌
- 读请求可通过多个副本分担压力，提升并发处理能力（如主库写、从库读）。
‌无缝维护‌
- 支持滚动升级、硬件更换等操作，无需停服。

二、高可用部署的 ‌核心原理‌

MySQL 高可用方案通常基于以下技术组合：

1. ‌数据复制（Replication）‌

‌异步复制（Async Replication）‌
- 主库（Master）提交事务后异步推送二进制日志（binlog）到从库（Slave）。
- ‌缺点‌：主库宕机时可能存在数据丢失（未同步到从库的日志）。
‌半同步复制（Semi-Sync Replication）‌
- 主库提交事务前需至少一个从库确认收到binlog，平衡性能与数据一致性。
‌组复制（Group Replication, MySQL 8.0+）‌
- 基于 Paxos 协议实现多主同步，确保数据一致性（CAP中的CP模型）。

2. ‌故障检测与切换（Failover）‌

‌心跳检测‌：通过定期发送心跳包（如每秒一次）判断节点存活状态。
‌VIP/DNS 切换‌：故障时自动将虚拟IP或域名解析指向新主库。
‌仲裁机制‌：防止脑裂（Split-Brain），例如使用奇数节点的投票机制（如3节点集群）。

3. ‌共享存储（Shared Storage）‌

使用分布式存储（如DRBD、SAN）实现多节点共享同一份数据。
‌优点‌：切换速度快（无需数据同步）。
‌缺点‌：存储层成为单点，需配合多路径访问。

三、典型高可用方案对比

方案	原理	优点	缺点	适用场景
‌主从复制+MHA‌	异步复制 + 脚本化故障转移	简单、成本低	数据可能丢失，切换延迟较高	中小规模业务
‌InnoDB Cluster‌	基于Group Replication + MySQL Shell	原生支持、自动化强	网络要求高，写性能受节点数影响	云环境、中等负载
‌Galera Cluster‌	多主同步（SST/IST）	强一致性、多节点写入	写冲突需处理，复杂性高	高一致性要求的OLTP
‌DRBD+Keepalived‌	共享存储 + VIP切换	切换快（秒级）	存储单点，扩展性有限	对切换速度敏感的场景

四、关键技术细节

1. ‌脑裂（Split-Brain）问题‌

‌原因‌：网络分区导致多个主库同时写入。
‌解决‌：
- 使用仲裁节点（Quorum）投票决定有效主库。
- 配置 fencing 机制隔离旧主库（如关闭网卡）。

2. ‌数据一致性级别‌

‌最终一致性‌：异步复制，适用于可容忍短暂不一致的场景（如用户评论）。
‌强一致性‌：同步复制（如Galera），适用于金融交易。

3. ‌故障转移时间‌

‌检测时间‌：通常依赖心跳超时（如3次心跳未响应，默认30秒）。
‌切换时间‌：从秒级（DRBD）到分钟级（MHA）不等。

五、部署建议

‌网络优化‌
- 确保低延迟、高带宽的私有网络（避免跨机房延迟）。
‌监控与告警‌
- 监控复制延迟、节点状态、VIP健康（如Prometheus+Alertmanager）。
‌定期演练‌
- 模拟主库宕机，验证切换流程和恢复时间（RTO）。

案例部署

‌一、双主互为主从配置‌

1. ‌MySQL双主同步配置‌

# 节点1配置（/etc/my.cnf） 
[mysqld] 
server-id = 1 
log_bin = mysql-bin 
binlog_format = ROW 
auto_increment_increment = 2 # 避免自增ID冲突 
auto_increment_offset = 1 
replicate-do-db = your_database 
log-slave-updates = ON # 级联复制关键参数:ml-citation{ref="4,5" data="citationList"} 

# 节点2配置（server-id=2，offset=2） 
auto_increment_offset = 2 

# 双向授权复制用户（两节点均执行） 
CREATE USER 'repl'@'%' IDENTIFIED BY 'password'; 
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%'; 

# 节点1指向节点2 
CHANGE MASTER TO
 MASTER_HOST='node2_ip',
 MASTER_USER='repl',
 MASTER_PASSWORD='password',
 MASTER_LOG_FILE='mysql-bin.000001',
 MASTER_LOG_POS=154; START SLAVE; 

# 节点2指向节点1（反向配置） 
CHANGE MASTER TO
 MASTER_HOST='node1_ip',
 MASTER_USER='repl',
 MASTER_PASSWORD='password',
 MASTER_LOG_FILE='mysql-bin.000001',
 MASTER_LOG_POS=154; 
START SLAVE;

2. ‌验证双主同步‌

-- 在节点1插入数据 
INSERT INTO test.t1 VALUES (1); 
-- 在节点2查询是否同步 
SELECT * FROM test.t1;

‌二、Haproxy负载均衡配置‌

1. ‌安装与基础配置‌

# 安装Haproxy 
yum install haproxy -y # CentOS 
apt-get install haproxy -y # Ubuntu 

# 配置文件（/etc/haproxy/haproxy.cfg） 
global
 log /dev/log local0
 maxconn 4096
 user haproxy
 group haproxy 

defaults
 mode tcp
 timeout connect 5s
 timeout client 1m
 timeout server 1m 

frontend mysql_front
 bind *:3306
 default_backend mysql_back

backend mysql_back
 balance leastconn
 option mysql-check user haproxy_check
 server mysql1 node1_ip:3306 check inter 2s rise 2 fall 3
 server mysql2 node2_ip:3306 check inter 2s rise 2 fall 3

2. ‌启动服务‌

systemctl enable haproxy 
systemctl restart haproxy

‌三、Keepalived高可用配置‌

1. ‌安装与VIP配置‌

# 安装Keepalived 
yum install keepalived -y 

# 主节点配置（/etc/keepalived/keepalived.conf） 
vrrp_instance VI_1 {
 state MASTER
 interface eth0
 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
 } 
} 

vrrp_script chk_haproxy {
 script "killall -0 haproxy"
 interval 2
 weight -20 
}

2. ‌备节点配置‌

# 修改state为BACKUP，priority设为90 
systemctl restart keepalived

‌四、架构总结‌

‌核心优势‌
- 双主同步实现读写负载均衡与故障自动切换
- Haproxy提供连接池管理，避免直连数据库导致连接耗尽
- Keepalived确保VIP无缝漂移（RTO<5秒）
‌注意事项‌
- 双主架构需严格处理自增ID冲突（通过auto_increment_increment调节）
- 网络分区时需依赖仲裁机制避免脑裂

‌监控建议‌

# 检查复制状态 
SHOW SLAVE STATUS\G 

# 测试VIP漂移 
ping vip_ip

检验步骤

‌一、基础功能验证‌

‌双主同步校验‌
- 在节点A执行数据写入：
```
INSERT INTO test.t1 VALUES (10); 
```
- 在节点B查询同步结果：
```
SELECT * FROM test.t1; 
```
- 反向验证（节点B写入，节点A查询）。
‌Haproxy负载均衡测试‌
- 通过VIP连接数据库并观察请求分发：
```
mysql -h vip_ip -u user -p -e "SHOW VARIABLES LIKE 'server_id'" 
```
- 多次执行应轮询返回不同节点的server_id。

‌二、高可用性验证‌

‌主节点故障切换‌
- 模拟节点A宕机：
```
systemctl stop mysqld 
```
- 验证：
  - VIP自动漂移至节点B（ip addr show eth0）。
  - 应用通过VIP写入数据应成功（原节点B提升为新主）。
‌Haproxy进程恢复‌
- 手动杀死Haproxy进程：
```
pkill haproxy 
```
- 检查Keepalived是否触发自动重启（journalctl -u keepalived）。

‌三、数据一致性校验‌

‌校验工具‌
- 使用pt-table-checksum比对双主数据：
```
pt-table-checksum --replicate=test.checksums h=node1_ip,u=admin,p=password 
```
- 通过pt-table-sync修复差异（若存在）。
‌日志位点检查‌
- 确认双主Exec_Master_Log_Pos一致：
```
SHOW SLAVE STATUS\G 
```

MySQL高可用

基础概念

一、高可用部署的 ‌核心意义‌

二、高可用部署的 ‌核心原理‌

1. ‌数据复制（Replication）‌

2. ‌故障检测与切换（Failover）‌

3. ‌共享存储（Shared Storage）‌

三、典型高可用方案对比

四、关键技术细节

1. ‌脑裂（Split-Brain）问题‌

2. ‌数据一致性级别‌

3. ‌故障转移时间‌

五、部署建议

案例部署

‌一、双主互为主从配置‌

1. ‌MySQL双主同步配置‌

2. ‌验证双主同步‌

‌二、Haproxy负载均衡配置‌

1. ‌安装与基础配置‌

2. ‌启动服务‌

‌三、Keepalived高可用配置‌

1. ‌安装与VIP配置‌

2. ‌备节点配置‌

‌四、架构总结‌

检验步骤

‌一、基础功能验证‌

‌二、高可用性验证‌

‌三、数据一致性校验‌

网站公告

今日签到

热门文章

最新发布