MySQL主从复制-配置前提

提前准备好两台服务器，分别安装Mysql并启动服务成功。

这页的目标是把“主从复制能跑起来”所需的前置条件讲清楚：哪些配置必须有、每一步在验证什么、常见坑在哪里。

关联：MySQL主从复制 / MySQL主从复制-读写分离案例

关键前提清单（先对照再动手）

• Master/Slave 的 server_id 必须不同
• Master 必须开启 binlog（主库把写入记录到二进制日志）
• Slave 需要能连到 Master（网络、防火墙、权限、端口）
• 复制账号具备 REPLICATION SLAVE 权限
• 业务写入只走主库；从库建议只读（避免误写导致数据漂移）

验证点（做完每步就能自检）

• Master：SHOW MASTER STATUS; 能看到 File、Position
• Slave：SHOW SLAVE STATUS\G 能看到 IO/SQL 线程状态与延迟信息

配置-主库Master

第二步，重启mysql服务
systemctl restart mysqld

主库侧需要做的事情（语义版）

1. 配置并重启：保证开启 binlog，并设置唯一 server_id
2. 创建复制账号：给从库一个“只用于复制”的账号与权限
3. 记录主库位点：给从库一个“从哪儿开始追”的起点（File/Position 或 GTID）

示例（账号与权限，按你的实际环境替换）：

CREATE USER 'repl'@'%' IDENTIFIED BY 'your_password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;
SHOW MASTER STATUS;

配置-从库Slave

第二步：重启Mysql服务
systemctl restart mysqld

从库侧需要做的事情（语义版）

1. 配置并重启：设置唯一 server_id，并建议打开只读
2. 指向主库：配置 master host/user/password 与起始位点
3. 启动复制线程：让从库开始拉取并回放 binlog
4. 验证状态：确认 IO/SQL 线程都正常且延迟可接受

验证命令：

SHOW SLAVE STATUS\G

常见坑（出现问题优先排查）

• server_id 相同导致复制异常
• binlog 未开启或权限不足导致 SHOW MASTER STATUS 无法得到有效位点
• 防火墙/白名单导致从库连不上主库（IO 线程异常）
• 误把业务写入打到从库（只读未生效或绕过）

下一步：读写分离落地见 MySQL主从复制-读写分离案例。