MySQL主从复制搭建核心是配置主库binlog与从库I/O、SQL线程，并全程验证状态、权限和网络。主库需启用binlog、设唯一server-id、创建带REPLICATION SLAVE权限的用户；从库配不同server-id，执行CHANGE MASTER TO并START SLAVE；通过SHOW SLAVE STATUS检查双线程运行及延迟；常见问题按权限、网络、配置顺序排查。
MySQL主从复制搭建核心在于配置主库的二进制日志（binlog）和从库的I/O线程+SQL线程，确保从库能准确读取并重放主库变更。关键不是“装完就跑”，而是每一步都要验证状态、权限和网络连通性。
主库配置：开启binlog并创建复制用户
主库必须启用binlog，并设置唯一server-id；复制用户需有REPLICATION SLAVE权限，建议限定来源IP增强安全。
- 修改/etc/my.cnf（或/etc/mysql/mysql.conf.d/mysqld.cnf），在[mysqld]下添加：
server-id = 1 log-bin = mysql-bin binlog-format = ROW expire_logs_days = 7
- 重启MySQL：systemctl restart mysqld
- 登录MySQL，创建复制账号（替换'repl_user'和'your_password'）：
CREATE USER 'repl_user'@'192.168.1.%' IDENTIFIED BY 'your_password'; GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'192.168.1.%'; FLUSH PRIVILEGES;
- 记录当前binlog位置（后续从库需要）：
SHOW MASTER STATUS;
记下File（如mysql-bin.000001）和Position（如154）值。
从库配置：指定server-id并配置复制连接
从库不能与主库server-id冲突，且需确保能通过复制用户连接主库（检查防火墙、SELinux、网络可达性）。
- 修改从库my.cnf，设置唯一server-id（如2），无需开binlog（除非要级联）：
server-id = 2
- 重启从库MySQL
- 执行CHANGE MASTER TO命令（填入主库IP、端口、用户名、密码、binlog文件名和位置）：
CHANGE MASTER TO MASTER_HOST='192.168.1.10', MASTER_PORT=3306, MASTER_USER='repl_user', MASTER_PASSWORD='your_password', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154;
- 启动复制：
START SLAVE;
验证复制是否正常运行
不能只看“YES”，要查两个关键线程是否Running，以及Seconds_Behind_Master是否为0或稳定增长后归零。
- 执行：SHOW SLAVE STATUS\G
- 重点检查字段：
Slave_IO_Running: Yes ← I/O线程是否在拉取日志 Slave_SQL_Running: Yes ← SQL线程是否在执行日志 Seconds_Behind_Master: 0 ← 延迟秒数（0或较小值为佳） Last_IO_Error: ← 若非空，说明连接或权限问题 Last_SQL_Error: ← 若非空，说明SQL执行出错（如主从表结构不一致）
- 简单测试：在主库建库、建表、插入数据，立刻查从库是否同步。
常见问题排查要点
多数失败集中在权限、网络、配置一致性三类，按顺序快速定位。
- 连接拒绝（Error 2003）：检查主库防火墙是否放行3306、MySQL是否绑定0.0.0.0（而非127.0.0.1）、复制用户host是否匹配
- I/O线程未启动（Slave_IO_Running: No）：用mysql -h主IP -urepl_user -p手动测试能否登录；检查MASTER_LOG_FILE和MASTER_LOG_POS是否过期（主库binlog被清理）
- SQL线程报错（如1032/1062错误）：通常是主从数据不一致导致，可跳过单个事务（谨慎！）：SET GLOBAL sql_slave_skip_counter = 1; START SLAVE;，但更推荐先修复数据再同步
- 延迟持续升高：检查从库负载、慢查询、大事务、是否启用了innodb_flush_log_at_trx_commit=1等影响性能的参数
