1. 在从库检查复制状态
在从库（Slave）上执行：
SHOW SLAVE STATUS\G;
关注以下关键字段：
Slave_IO_Running: Yes → I/O 线程是否正常
Slave_SQL_Running: Yes → SQL 线程是否正常
Seconds_Behind_Master: 0 → 复制延迟时间（理想情况下应为 0 或接近 0）
Last_IO_Error 和 Last_SQL_Error → 检查是否有错误
如果 Slave_IO_Running 或 Slave_SQL_Running 为 No，说明复制有问题。
2. 在主库检查主从连接
在主库（Master）上执行：
SHOW PROCESSLIST;
查看是否有 Binlog Dump 线程（表示主库正在向从库发送 binlog）：
| Id | User | Host | db | Command | Time | State | Info |
|---- |--------|----------|-----|------------|------|-------------|------|
| 5 | repl | 192.168.1.2:34678 | NULL | Binlog Dump | 120 | Master has sent all binlog to slave; waiting for more updates | NULL |
如果没有 Binlog Dump 线程，则可能主库未向从库发送日志，需要检查主库的 binlog 配置。
3. 检查主库的二进制日志（Binlog）
SHOW MASTER STATUS;
输出示例：
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 | 987654 | testdb | |
+------------------+----------+--------------+------------------+
确保 File 和 Position 在从库同步过程中发生变化。
4. 在从库检查 Relay Log 状态
SHOW RELAYLOG EVENTS LIMIT 10;
如果 relay log 没有更新，则可能从库的 IO 线程有问题。
5. 检查网络连通性
如果 Slave_IO_Running 为 No，可以测试从库到主库的连接：
telnet 主库IP 3306
或者使用 mysql -h 连接主库，检查是否能正常访问。
6. 查看 MySQL 错误日志
主库错误日志（检查 binlog 相关错误）：
cat /var/log/mysql/error.log
从库错误日志（检查复制错误）：
cat /var/log/mysql/error.log
7. 解决常见问题
| 问题 | 可能原因 | 解决方案 |
|---|---|---|
| Slave_IO_Running: No | 端口未开放、防火墙阻拦 | 确保主库 3306 端口开放，并检查 iptables 或 firewalld 规则 |
| Slave_SQL_Running: No | SQL 执行错误 SHOW SLAVE STATUS\G; | 查看 Last_SQL_Error，手动修复错误 |
| Seconds_Behind_Master 较大 | 复制延迟 | 可能是主库负载过高或网络问题，检查 CPU、IO 和网络带宽 |
| SHOW MASTER STATUS 无输出 | binlog 未开启 | 在 my.cnf 中添加 log_bin=mysql-bin 并重启 MySQL |
如果主从复制仍然无法恢复，可以尝试
STOP SLAVE;
RESET SLAVE;
CHANGE MASTER TO …;
START SLAVE;
重新配置。
