MySQL高可用性架构需要同时保障服务不中断和数据不丢失，单独依赖主从复制无法应对全量数据损坏场景，单独依赖备份则无法实现快速故障切换，将两者结合可以构建更完善的防护体系。
方案核心设计思路
该方案以主从复制为基础保障服务可用性，以定期备份为核心保障数据安全，两者通过二进制日志实现数据链路打通，整体架构分为三个核心部分：
- 主从复制层：搭建一主多从复制架构，主库处理写请求，从库同步主库数据并承担读请求，主库故障时可快速切换到从库提供服务
- 备份层：定期对主库或延迟从库执行全量备份，结合二进制日志做增量备份，备份数据存储在独立的远程存储节点
- 故障处理层：定义主库故障、数据误删等不同场景的切换和恢复流程，确保故障发生后服务快速恢复，数据损失降到最低
核心组件配置实现
1. 主从复制配置
首先完成主从复制的基础配置，主库需要开启二进制日志并配置唯一server-id：
-- 主库配置文件my.cnf添加以下配置 [mysqld] server-id=1 log-bin=mysql-bin binlog_format=ROW expire_logs_days=7 -- 主库创建复制账号 CREATE USER 'repl'@'从库IP' IDENTIFIED BY 'repl_password'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'从库IP'; FLUSH PRIVILEGES; -- 查看主库二进制日志状态 SHOW MASTER STATUS;
从库配置对应的server-id并启动复制线程：
-- 从库配置文件my.cnf添加以下配置 [mysqld] server-id=2 relay-log=relay-bin read-only=1 -- 从库配置复制链路，MASTER_LOG_FILE和MASTER_LOG_POS对应主库SHOW MASTER STATUS的结果 CHANGE MASTER TO MASTER_HOST='主库IP', MASTER_USER='repl', MASTER_PASSWORD='repl_password', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154; -- 启动复制 START SLAVE; -- 查看复制状态，确保Slave_IO_Running和Slave_SQL_Running都为Yes SHOW SLAVE STATUSG
2. 备份策略配置
采用全量备份加增量备份的组合策略，全量备份每周执行一次，增量备份每天执行一次，基于二进制日志实现增量数据捕获：
# 全量备份脚本，使用mysqldump执行全量备份
#!/bin/bash
BACKUP_DIR=/data/mysql_backup/full
DATE=$(date +%Y%m%d)
mysqldump -uroot -p'数据库密码' --all-databases --single-transaction --master-data=2 --flush-logs > ${BACKUP_DIR}/full_${DATE}.sql
# 将备份文件同步到远程存储
rsync -avz ${BACKUP_DIR}/full_${DATE}.sql root@备份存储IP:/backup/mysql/full/
# 增量备份脚本，每天复制新增的二进制日志
#!/bin/bash
BACKUP_DIR=/data/mysql_backup/increment
DATE=$(date +%Y%m%d)
# 复制主库当前所有未备份的二进制日志
mysql -uroot -p'数据库密码' -e "SHOW BINARY LOGS;" | awk 'NR>1{print $1}' | while read log; do
cp /var/lib/mysql/${log} ${BACKUP_DIR}/${log}_${DATE}
done
rsync -avz ${BACKUP_DIR} root@备份存储IP:/backup/mysql/increment/
故障场景处理流程
主库故障场景
当主库发生硬件故障无法恢复时，按照以下流程处理：
- 检查从库数据同步状态，选择数据最新的从库作为新主库
- 对比新主库和备份文件的二进制日志位置，补充未同步的增量日志数据
- 将其他从库的主库指向切换到新主库，恢复复制链路
- 修改应用连接配置指向新主库，恢复写服务
数据误删场景
当发生误删表或误删数据的情况时，处理流程如下：
- 从最近的备份文件中恢复全量数据到临时实例
- 解析增量备份的二进制日志，提取误删操作之前的数据变更记录
- 将提取的增量数据同步到临时实例，验证数据完整性
- 将恢复后的数据同步到生产库，完成数据修复
方案优势与注意事项
该方案的核心优势在于兼顾了服务可用性和数据安全：主从复制可以将故障切换时间控制在分钟级别，备份机制可以应对全量数据损坏、人为误删等极端场景。实际落地时需要注意以下事项：
- 定期检查复制状态，避免从库同步延迟过大导致故障切换时数据丢失
- 定期验证备份文件的可用性，避免备份文件损坏无法恢复
- 二进制日志需要保留足够长的时间，至少覆盖两次全量备份的周期
- 延迟从库可以应对人为误删场景，建议配置一个延迟1小时同步的从库
以下是不同方案的能力对比：
| 方案类型 | 故障切换速度 | 数据丢失风险 | 极端场景防护能力 |
|---|---|---|---|
| 单独主从复制 | 快（分钟级） | 中（存在同步延迟时丢数据） | 弱（无法应对全量数据损坏） |
| 单独定时备份 | 慢（小时级） | 高（依赖备份周期） | 强（可恢复全量数据） |
| 复制+备份结合 | 快（分钟级） | 低（可补全增量数据） | 强（覆盖所有数据风险场景） |