1. 查看详细错误日志

详细的错误日志通常能给出更精准的错误信息，协助你定位问题。你可以在从服务器上使用如下命令查看 MySQL 错误日志：

bash

tail -n 50 /var/log/mysql/error.log

通过查看错误日志，你可能会发现诸如表结构不匹配、唯一键冲突等具体错误。

2. 检查 performance_schema.replication_applier_status_by_worker 表

这个表会记录复制工作线程的详细状态，能帮助你进一步分析错误原因。在从服务器的 MySQL 客户端中执行以下查询：

sql

SELECT * FROM performance_schema.replication_applier_status_by_worker;

查询结果可能会显示更具体的错误，比如 SQL 语句执行错误、数据类型不匹配等。

3. 跳过错误事务

若错误是由特定事务引发的，你可以尝试跳过该事务，让复制继续进行。步骤如下：

sql

-- 停止从服务器的复制进程
STOP SLAVE;

-- 跳过一个事务
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;

-- 重新启动从服务器的复制进程
START SLAVE;

-- 再次查看从服务器状态
SHOW SLAVE STATUS \G;

若跳过一个事务后问题依旧存在，可根据实际情况增加 SQL_SLAVE_SKIP_COUNTER 的值，不过要谨慎使用此方法，因为跳过事务可能会导致数据不一致。

4. 检查数据一致性

主从服务器的数据不一致可能会致使复制出错。你可以从以下方面检查：

• 表结构：在主从服务器上分别使用 SHOW CREATE TABLE 语句查看相关表的结构，确保完全一致。

sql

-- 在主服务器上查看表结构
SHOW CREATE TABLE your_table_name;

-- 在从服务器上查看表结构
SHOW CREATE TABLE your_table_name;

• 数据内容：可以使用 pt-table-checksum 工具检查主从服务器的数据一致性。该工具能找出主从数据不一致的表。

5. 重新初始化从服务器

若上述方法都无法解决问题，可考虑重新初始化从服务器，步骤如下：

主服务器操作

sql

-- 锁定所有表，确保数据一致性
FLUSH TABLES WITH READ LOCK;

-- 查看主服务器二进制日志状态
SHOW MASTER STATUS;
-- 记录下 File 和 Position 的值

-- 使用 mysqldump 备份所有数据库
mysqldump -u root -p --all-databases > backup.sql

-- 解锁表
UNLOCK TABLES;

从服务器操作

bash

# 将备份文件从主服务器复制到从服务器
scp root@<master_server_ip>:backup.sql .

# 恢复备份数据
mysql -u root -p < backup.sql

重新配置从服务器的主从复制

sql

-- 停止从服务器的复制进程
STOP SLAVE;

-- 重新配置主从复制参数
CHANGE MASTER TO
    MASTER_HOST='192.168.31.19',
    MASTER_USER='shitou',
    MASTER_PASSWORD='shitou521',
    MASTER_LOG_FILE='<记录的 File 值>',
    MASTER_LOG_POS=<记录的 Position 值>;

-- 启动从服务器的复制进程
START SLAVE;

-- 查看从服务器状态
SHOW SLAVE STATUS \G;