MySQL主从复制通过将主库的变更日志同步到从库，实现数据冗余和读写分离，是构建高可用数据库架构的基础。配置过程需要主从库协同完成参数调整和数据同步设置。
一、MySQL主从复制配置步骤
1. 主库配置
首先修改主库的MySQL配置文件my.cnf，添加以下核心参数：
[mysqld] # 启用二进制日志，主从复制依赖该日志 log-bin=mysql-bin # 设置唯一的服务器ID，集群内所有节点ID不能重复 server-id=1 # 二进制日志格式，推荐使用ROW格式保证数据一致性 binlog_format=ROW # 可选：指定需要同步的数据库，不设置则同步所有库 # binlog-do-db=test_db
修改完成后重启主库MySQL服务，然后登录主库执行以下命令创建用于同步的账号并授权：
-- 创建同步账号，用户名slave_user，密码为slave_pass，允许从库IP连接 CREATE USER 'slave_user'@'从库IP' IDENTIFIED BY 'slave_pass'; -- 授予同步权限 GRANT REPLICATION SLAVE ON *.* TO 'slave_user'@'从库IP'; -- 刷新权限 FLUSH PRIVILEGES; -- 查看主库当前二进制日志状态，记录File和Position值，后续从库配置需要用到 SHOW MASTER STATUS;
2. 从库配置
修改从库的my.cnf配置文件，添加如下参数：
[mysqld] # 设置唯一的服务器ID，和主库以及其他从库不能重复 server-id=2 # 开启中继日志，用于存放从主库同步过来的日志 relay-log=mysql-relay-bin # 可选：设置从库只读，避免误操作修改数据 read-only=1
重启从库MySQL服务后，登录从库执行同步配置命令：
-- 配置主库连接信息，替换对应的值 CHANGE MASTER TO MASTER_HOST='主库IP', MASTER_USER='slave_user', MASTER_PASSWORD='slave_pass', MASTER_LOG_FILE='之前记录的主库File值', MASTER_LOG_POS=之前记录的主库Position值; -- 启动从库同步进程 START SLAVE; -- 查看从库同步状态 SHOW SLAVE STATUSG
查看同步状态时，需要确认Slave_IO_Running和Slave_SQL_Running两个字段的值都为YES，说明主从复制配置成功。
二、实现高可用需要注意的要点
1. 主从延迟问题处理
主从延迟是主从架构常见的问题，可能导致从库读取到旧数据。可以通过以下方式缓解：
- 主库尽量批量写入数据，减少小事务提交频率
- 从库配置更高的硬件资源，尤其是磁盘IO性能
- 业务层面区分读写场景，对实时性要求高的读请求走主库
- 使用并行复制功能，MySQL 5.7及以上版本可以开启基于事务的并行复制
2. 故障自动切换机制
主库故障时需要快速切换到从库，避免服务中断。可以搭配Keepalived或者Orchestrator等工具实现自动故障检测和切换：
- 提前配置好主从切换的脚本，自动提升从库为主库
- 切换完成后及时更新应用端的数据库连接配置
- 原主库恢复后需要重新加入集群作为从库，避免数据不一致
3. 数据一致性保障
要保证主从数据一致，需要注意以下事项：
- 开启半同步复制，主库提交事务时至少等待一个从库接收日志后再返回成功
- 定期使用
pt-table-checksum工具校验主从数据差异 - 避免直接在从库执行写操作，防止数据冲突
- 主库执行大批量数据变更时，提前评估对同步的影响，必要时暂停从库同步
4. 监控与告警
需要建立完善的监控体系，关注以下指标：
| 监控指标 | 说明 |
|---|---|
| 从库同步状态 | 监控Slave_IO_Running和Slave_SQL_Running是否为YES |
| 主从延迟时间 | 记录从库落后主库的时间，超过阈值触发告警 |
| 主从服务器资源使用率 | 包括CPU、内存、磁盘IO、磁盘空间等 |
| 二进制日志和中继日志大小 | 避免日志占满磁盘空间 |
5. 备份策略配合
主从复制不能替代备份，需要定期做全量备份和增量备份：
- 可以从从库执行备份，避免影响主库性能
- 备份文件需要存储到异地，防止单机房故障导致数据丢失
- 定期验证备份文件的可恢复性，确保故障时能快速恢复数据