数据库复制失败怎么排查

数据库复制（主从复制 / 读写分离 / 集群同步）失败是常见运维问题，排查一般按**“链路 → 状态 → 日志 → 数据 → 配置”的顺序进行。下面以MySQL 主从复制**为主（其他数据库思路类似），给你一套可落地的排查清单。

一、先确认复制状态（最关键）

MySQL

SHOW SLAVE STATUS\G

重点看：

• Slave_IO_Running：是否为 Yes
• Slave_SQL_Running：是否为 Yes
• Last_IO_Error
• Last_SQL_Error
• Seconds_Behind_Master

常见问题对应：

二、网络与连接排查

1. 主从网络是否通

ping 主库IP
telnet 主库IP 3306

2. 复制账号是否正常

SELECT user, host FROM mysql.user;

确认：

• 账号存在
• host 允许从库连接
• 有 REPLICATION SLAVE 权限

三、Binlog 与位点问题（非常常见）

1. 主库 binlog 是否存在

SHOW MASTER STATUS;

从库 Master_Log_File 是否 ≤ 主库当前 binlog

2. 位点不一致

常见于：

• 从库重启
• 主库 binlog 被清理
• 手动 CHANGE MASTER

解决思路：

• 重新 CHANGE MASTER TO
• 或重建从库（最稳妥）

四、SQL 线程错误（数据冲突）

典型错误：

• Duplicate entry
• Unknown table
• Row not found

常见原因

• 从库被直接写入
• 主从数据不一致
• 使用了不支持的语句

临时处理（仅测试环境）

SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
START SLAVE;

⚠️ 生产环境不推荐跳过，应追数据。

五、查看错误日志（最权威）

从库错误日志

tail -f mysql-error.log

通常能看到：

• 连接失败原因
• SQL 执行失败详情
• 权限问题

六、配置类问题排查

检查从库配置：

server-id（主从不能相同）
log_bin
relay_log
read_only

常见坑

• 主从 server-id 相同
• 从库未开启 log_slave_updates
• GTID 模式不一致

七、GTID 复制失败（如果用 GTID）

SHOW SLAVE STATUS\G

看：

• Retrieved_Gtid_Set
• Executed_Gtid_Set

问题常因：

• GTID 被手动跳过
• 主库事务未同步

八、快速定位思路总结

复制断了
  ↓
SHOW SLAVE STATUS
  ↓
IO / SQL 哪个 NO
  ↓
看 Error 信息
  ↓
网络 / 账号 / binlog / 数据
  ↓
修复 or 重建

九、如果还解决不了

可以告诉我：

1. 数据库类型（MySQL / PG / Redis / Oracle）
2. 复制方式（主从 / 集群 / 云数据库）
3. 具体错误信息（贴 SHOW SLAVE STATUS 或日志）

我可以帮你逐条精确定位。