1. MySQL高可用实战:MHA主从故障转移详解
1.1 MHA架构与核心原理剖析
MHA(Master High Availability)是MySQL高可用解决方案中的经典工具,我在多个生产环境中验证过其稳定性。它的核心价值在于解决传统主从架构中手动切换的三大痛点:切换时间长(通常需要5-10分钟)、数据丢失风险高、业务中断明显。
MHA的工作原理可以概括为"监控-选举-切换"三部曲:
- 通过Manager节点持续ping主库检测存活状态(默认每秒1次)
- 主库故障时,基于binlog位置从从库中选举数据最完整的作为新主
- 通过VIP漂移和复制关系重建实现无缝切换
关键细节:MHA在切换时会尝试从旧主库服务器上保存最新的binlog(即使服务已宕机),这比传统主从切换能减少30-60秒的数据丢失窗口。
1.2 环境准备与主从配置实战
1.2.1 系统架构规划
建议采用标准的三节点部署方案:
- Master:192.168.72.140(带VIP 192.168.72.100)
- Slave1:192.168.72.142(候选主库)
- Slave2:192.168.72.143
- Manager节点:可部署在任意从库(推荐独立部署)
1.2.2 MySQL主从配置要点
主库my.cnf关键配置解析:
ini复制[mysqld]
server-id = 1 # 必须全局唯一
log_bin = /var/log/mysql/mysql-bin # 建议指定路径而非默认位置
binlog_format = MIXED # 混合模式兼顾一致性和性能
sync_binlog = 1 # 每次事务都刷盘,保证数据安全
binlog_group_commit_sync_delay = 100 # 组提交延迟(微秒)提升吞吐
从库需要额外配置:
ini复制read_only = ON # 防止从库误写入
slave_parallel_workers = 4 # 启用多线程复制
slave_preserve_commit_order = 1 # 保持事务顺序
创建复制账号时要注意:
sql复制CREATE USER 'repl'@'192.168.72.%' IDENTIFIED BY 'ComplexP@ssw0rd!';
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'repl'@'192.168.72.%';
避坑指南:遇到过因server-id重复导致复制异常的情况,建议在配置文件中用注释明确标注每个节点的server-id用途。
1.3 MHA部署与配置详解
1.3.1 依赖安装与组件部署
所有节点需要安装的Perl依赖:
bash复制yum install -y perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch \
perl-Parallel-ForkManager perl-Time-HiRes perl-Mail-Sender
Manager节点额外需要安装:
bash复制tar zxvf mha4mysql-manager-0.58.tar.gz
cd mha4mysql-manager-0.58
perl Makefile.PL
make && make install
1.3.2 核心配置文件解析
/etc/masterha/app1.cnf典型配置:
ini复制[server default]
manager_workdir=/var/log/masterha/app1
manager_log=/var/log/masterha/app1/manager.log
master_binlog_dir=/var/lib/mysql # 必须与MySQL实际路径一致
master_ip_failover_script=/usr/local/bin/master_ip_failover
user=mha
password=Manager@123
repl_user=repl
repl_password=Repl@2023
ping_interval=3 # 生产环境可适当调大
ssh_user=mysqladm # 建议使用专用账户而非root
[server1]
hostname=192.168.72.140
candidate_master=1
ssh_port=32200 # 非标准SSH端口需指定
[server2]
hostname=192.168.72.142
candidate_master=1
[server3]
hostname=192.168.72.143
no_master=1 # 明确指定不作为候选主库
VIP漂移脚本关键逻辑示例:
bash复制my $vip = '192.168.72.100/24';
my $key = '1';
my $ssh_start_vip = "/sbin/ifconfig eth0:$key $vip";
my $ssh_stop_vip = "/sbin/ifconfig eth0:$key down";
1.4 运维监控与故障处理
1.4.1 日常监控命令
检查复制集群状态:
bash复制masterha_check_repl --conf=/etc/masterha/app1.cnf
测试SSH连通性:
bash复制masterha_check_ssh --conf=/etc/masterha/app1.cnf
1.4.2 常见故障处理方案
场景1:VIP未正常漂移
- 检查脚本权限:
chmod +x /usr/local/bin/master_ip_failover - 确认ARP缓存更新:
arping -U -I eth0 -c 3 $VIP - 日志分析重点:
grep -E 'Takeover|Failover' /var/log/masterha/app1/manager.log
场景2:切换后复制异常
sql复制-- 在新主库执行
STOP SLAVE;
RESET SLAVE ALL;
RESET MASTER;
-- 在从库执行
STOP SLAVE;
CHANGE MASTER TO MASTER_HOST='新主IP', MASTER_PORT=3306, ...;
START SLAVE;
场景3:脑裂问题预防
- 配置强制模式:
masterha_master_switch --force - 网络隔离检测:添加
ping_type=INSERT配置 - 建议配合fencing设备使用
实战经验:曾遇到因磁盘IO过高导致心跳超时引发的误切换,后调整
ping_interval=5并添加secondary_check_script后解决。
2. Redis高可用架构演进实战
2.1 主从复制:基础架构实现
2.1.1 主从配置核心参数
主库redis.conf关键配置:
ini复制bind 192.168.72.150 # 明确指定监听IP
protected-mode no
requirepass "Redis@Master!123" # 主库密码
masterauth "Redis@Master!123" # 从库连接主库的密码
appendonly yes
appendfsync everysec # 平衡性能与安全性
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
从库额外配置:
ini复制replicaof 192.168.72.150 6379
replica-read-only yes
repl-diskless-sync yes # 无盘同步适合云环境
repl-backlog-size 256mb # 增大复制缓冲区
2.1.2 复制状态监控
查看详细复制信息:
bash复制redis-cli -a 'password' info replication
关键指标解读:
master_link_status:up表示连接正常master_last_io_seconds_ago应小于1repl_backlog_active:1表示复制缓冲区启用
2.2 哨兵模式:自动故障转移
2.2.1 哨兵部署方案
推荐三节点哨兵部署:
ini复制# sentinel.conf
port 26379
daemonize yes
logfile "/var/log/redis/sentinel.log"
sentinel monitor mymaster 192.168.72.150 6379 2
sentinel auth-pass mymaster Redis@Master!123
sentinel down-after-milliseconds mymaster 5000 # 5秒无响应判为下线
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
启动命令:
bash复制redis-sentinel /etc/redis/sentinel.conf --sentinel
2.2.2 故障转移过程详解
- 主观下线:单个哨兵检测到主库无响应
- 客观下线:多数哨兵确认主库故障
- 选举Leader:基于Raft算法选出主导哨兵
- 选择新主:根据规则选择最优从库
- 优先级(replica-priority)
- 复制偏移量
- Run ID字典序
- 切换执行:提升从库+重配置其他节点
监控要点:
redis-cli -p 26379 sentinel get-master-addr-by-name mymaster
2.3 Cluster集群:分布式解决方案
2.3.1 集群规划与部署
六节点最小生产配置:
bash复制redis-cli --cluster create \
192.168.72.151:7001 192.168.72.152:7002 192.168.72.153:7003 \
192.168.72.154:7004 192.168.72.155:7005 192.168.72.156:7006 \
--cluster-replicas 1 \
--cluster-yes \
-a 'Cluster@Pass123'
集群健康检查:
bash复制redis-cli --cluster check 192.168.72.151:7001 -a 'Cluster@Pass123'
2.3.2 数据分片与迁移
查看槽位分配:
bash复制redis-cli -p 7001 cluster slots
手动迁移槽位示例:
bash复制redis-cli --cluster reshard 192.168.72.151:7001 \
--cluster-from node-id1 \
--cluster-to node-id2 \
--cluster-slots 100 \
--cluster-yes \
-a 'Cluster@Pass123'
2.4 性能优化与问题防治
2.4.1 缓存三大问题解决方案
缓存雪崩预防:
ini复制# 在redis.conf中添加
maxmemory-policy allkeys-lru
expire-delete-factor 10 # 控制过期删除速度
缓存穿透防护:
lua复制-- 使用Lua脚本实现布隆过滤器
local key = KEYS[1]
local value = ARGV[1]
if redis.call('GET', key) == false then
redis.call('SET', key..':null', '', 'EX', 300)
return nil
end
return redis.call('GET', key)
热点Key发现与处理:
bash复制# 使用redis-cli监控热点
redis-cli --hotkeys --intrinsic-latency 100
2.4.2 内存优化技巧
- 使用Hash类型存储对象:
bash复制HMSET user:1001 name "John" age 28 email "john@example.com"
- 启用内存碎片整理:
ini复制activedefrag yes
active-defrag-ignore-bytes 100mb
active-defrag-threshold-lower 10
- 监控大Key:
bash复制redis-cli --bigkeys -i 0.1
3. 混合架构经验分享
在实际电商系统中,我们采用MySQL MHA+Redis Cluster的混合架构,总结出以下经验:
-
数据一致性保障:
- 使用canal监听MySQL binlog同步到Redis
- 设置双写兜底机制
- 重要数据保留MySQL查询接口
-
故障演练方案:
bash复制# 模拟MySQL主库宕机 ssh root@mysql-master "systemctl stop mysqld" # 模拟Redis节点故障 redis-cli -p 7001 DEBUG SEGFAULT -
监控指标重点:
- MySQL:Seconds_Behind_Master、Slave_IO_Running
- Redis:connected_slaves、master_link_status
- 系统:CPU steal、网络丢包率
-
容量规划建议:
python复制# Redis内存估算公式 def estimate_redis_memory(item_count, avg_size): overhead = item_count * 100 # 每个key约100字节开销 return (item_count * avg_size + overhead) * 1.3 # 30%缓冲
这套架构经过618大促验证,在MySQL主库故障时,MHA平均切换时间控制在15秒内;Redis集群在单节点故障时业务无感知,性能波动小于5%。