予晚1. 为什么需要MySQL主从复制集群
在互联网应用快速发展的今天，单机数据库已经很难满足高并发、高可用的业务需求。我曾经负责的一个电商项目就遇到过这样的困境：促销活动期间，数据库服务器CPU直接飙到100%，导致整个网站响应缓慢，最终不得不临时下线活动页面。
MySQL主从复制（Master-Slave Replication）正是解决这类问题的经典方案。它通过将数据从主库（Master）自动同步到一个或多个从库（Slave），实现了：
-
读写分离：写操作走主库，读操作分散到多个从库，有效分担主库压力。实测在1主2从架构下，读性能可以提升2-3倍。
-
数据备份：从库相当于实时备份，在主库故障时可快速切换。去年我们一次硬盘故障就靠从库实现了10分钟内恢复服务。
-
负载均衡：配合中间件（如MyCat、ShardingSphere）可以实现请求的智能分发。
-
高可用基础：这是后续实现MHA、MGR等高可用方案的前提条件。
重要提示：主从复制是异步的，存在毫秒级延迟。对强一致性要求的场景（如金融交易）需要特殊处理。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 环境准备与基础配置
2.1 服务器规划建议
根据我的踩坑经验，生产环境部署主从集群时，建议采用如下配置：
| 角色 | 数量 | 配置推荐 | 磁盘类型 | 网络要求 |
|---|---|---|---|---|
| Master | 1 | 16核32G内存 | SSD/NVMe | 与Slave延迟<1ms |
| Slave | ≥2 | 8核16G内存（与QPS相关） | SSD | 与Master同机房 |
避坑指南：
- 避免主从服务器配置差异过大，否则容易导致复制延迟
- 务必保证服务器时间同步（建议配置NTP服务）
- 生产环境强烈建议主从分布在不同的物理机上
2.2 MySQL安装最佳实践
以CentOS 7为例，推荐使用官方Yum源安装MySQL 5.7（社区版）：
bash复制# 添加MySQL官方Yum源
wget https://dev.mysql.com/get/mysql57-community-release-el7-11.noarch.rpm
sudo rpm -ivh mysql57-community-release-el7-11.noarch.rpm
# 安装MySQL服务器
sudo yum install -y mysql-community-server
# 启动服务并设置开机自启
sudo systemctl start mysqld
sudo systemctl enable mysqld
安装完成后需要获取临时密码：
bash复制grep 'temporary password' /var/log/mysqld.log
安全配置建议运行：
bash复制mysql_secure_installation
3. 主库(Master)配置详解
3.1 核心参数配置
编辑/etc/my.cnf，在[mysqld]段添加以下配置：
ini复制[mysqld]
# 服务器唯一ID（必须）
server-id = 1
# 二进制日志配置（关键）
log-bin = mysql-bin
binlog_format = ROW
binlog_row_image = FULL
expire_logs_days = 7
max_binlog_size = 100M
# 需要同步的数据库（可选）
binlog-do-db = your_database_name
# 从库连接配置
sync_binlog = 1
innodb_flush_log_at_trx_commit = 1
参数解析：
binlog_format=ROW：这是最安全的复制模式，比STATEMENT更能保证数据一致性sync_binlog=1：每次事务提交都刷盘，避免主库崩溃导致数据丢失server-id必须唯一，通常主库设为1，从库依次递增
3.2 创建复制账号
在主库执行：
sql复制CREATE USER 'repl'@'%' IDENTIFIED BY 'StrongPassword123!';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;
安全提示：生产环境建议限制repl账号的访问IP（如'192.168.1.%'）
3.3 获取主库状态
执行关键命令：
sql复制FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;
记录输出中的File和Position值，例如：
code复制+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000003 | 785 | your_db | |
+------------------+----------+--------------+------------------+
保持这个会话不要退出！新开会话导出数据。
4. 从库(Slave)配置实战
4.1 初始数据同步
在主库执行数据导出：
bash复制mysqldump -uroot -p --opt --single-transaction --flush-logs --master-data=2 --databases your_database_name > db_dump.sql
然后在主库解锁：
sql复制UNLOCK TABLES;
将备份文件传到从库并导入：
bash复制mysql -uroot -p < db_dump.sql
4.2 从库配置文件
编辑从库的/etc/my.cnf：
ini复制[mysqld]
server-id = 2 # 必须唯一且不同于主库
relay-log = mysql-relay-bin
read_only = 1 # 从库设为只读
log_slave_updates = 1 # 级联复制时需要
4.3 启动复制进程
在从库执行：
sql复制CHANGE MASTER TO
MASTER_HOST='master_ip',
MASTER_USER='repl',
MASTER_PASSWORD='StrongPassword123!',
MASTER_LOG_FILE='mysql-bin.000003', -- 前面记录的File值
MASTER_LOG_POS=785; -- 前面记录的Position值
START SLAVE;
检查复制状态：
sql复制SHOW SLAVE STATUS\G
关键指标检查：
Slave_IO_Running: YesSlave_SQL_Running: YesSeconds_Behind_Master应该逐渐减小
5. 高级配置与性能优化
5.1 半同步复制配置
默认异步复制可能丢失数据，建议配置半同步复制：
在主库：
sql复制INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
SET GLOBAL rpl_semi_sync_master_enabled = 1;
SET GLOBAL rpl_semi_sync_master_timeout = 10000; # 10秒超时
在从库：
sql复制INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
SET GLOBAL rpl_semi_sync_slave_enabled = 1;
5.2 多线程复制
MySQL 5.7+支持基于库的并行复制，在从库配置：
ini复制slave_parallel_workers = 4
slave_parallel_type = LOGICAL_CLOCK
5.3 常见问题排查
问题1：复制中断
sql复制STOP SLAVE;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
START SLAVE;
问题2：主从数据不一致
使用pt-table-checksum工具检查：
bash复制pt-table-checksum --replicate=test.checksums h=master_ip,u=root,p=password
pt-table-sync --replicate=test.checksums h=master_ip,u=root,p=password --sync-to-master
6. 生产环境维护要点
6.1 监控指标清单
必须监控的关键指标：
| 指标名称 | 报警阈值 | 检查命令 |
|---|---|---|
| 复制延迟(Seconds_Behind) | >30秒 | SHOW SLAVE STATUS\G |
| Slave_IO_Running | 不是Yes | SHOW SLAVE STATUS\G |
| Slave_SQL_Running | 不是Yes | SHOW SLAVE STATUS\G |
| 主库binlog空间 | >80% | SHOW BINARY LOGS; |
6.2 日常维护命令
主库binlog清理：
sql复制PURGE BINARY LOGS TO 'mysql-bin.000010'; # 删除000010之前的所有binlog
从库重建复制（当主从差异过大时）：
sql复制STOP SLAVE;
RESET SLAVE ALL;
# 然后重新执行CHANGE MASTER和START SLAVE
6.3 故障切换演练
建议每季度进行一次主从切换演练：
- 在从库执行
STOP SLAVE; - 设置
SET GLOBAL read_only=0; - 修改应用连接串指向新主库
- 配置原主库作为新从库
我在实际运维中发现，定期演练能确保故障时切换时间控制在5分钟以内。