MySQL解决主从复制的报错问题

MySQL 8.4 非 GTID 模式部分数据库主从复制指南

在进行MySQL 8.4非GTID模式下部分数据库主从复制时，以下是详细的操作步骤以及对应的执行位置说明，还有报错处理方法介绍：

操作步骤

1. 备份主库指定数据库（db1、db2）（主服务器上执行）

mkdir -p /backup
chown mysql:mysql /backup
mysqldump -u root -p --single-transaction --master-data=2 --databases db1 db2 --set-gtid-purged=OFF > /backup/partial_dump.sql

• --single-transaction：此参数可避免在备份过程中对数据表进行锁定，保障数据库正常读写不受影响。
• --master-data=2：用于记录主库的binlog位置信息，会以注释形式添加到备份文件中，方便后续配置使用。
• --set-gtid-purged=OFF：鉴于采用的是非GTID模式，设置该参数为OFF可禁用与GTID相关的内容输出，防止后续出现不必要干扰。

2. 停止从库复制（从服务器上执行）

STOP REPLICA;

注意这里使用的是MySQL 8.0及以上版本规范的语法来停止从库的复制进程。

3. 清理从库（可选，从服务器上执行）

DROP DATABASE IF EXISTS db1;
DROP DATABASE IF EXISTS db2;

此操作需谨慎进行，因为执行后会删除对应数据库中的所有数据，要提前确认好或者做好额外备份，避免数据丢失。

4. 传输备份文件（主服务器上执行）

scp /backup/partial_dump.sql 从服务器用户名@从服务器IP:/backup/

执行该命令时，要确保从服务器已开启相应的文件传输服务（如ssh服务），并且接收端的“从服务器用户名”对目标目录/backup/具备写入权限，这样才能成功传输备份文件。

5. 从库恢复备份（从服务器上执行）

mysql -u root -p < /backup/partial_dump.sql

通过此命令，能将接收到的备份文件中的数据库结构与数据完整导入到从库中，为后续配置主从复制奠定数据基础。

6. 配置从库复制（从服务器上执行）

首先，查看binlog位置：

grep -A1 "CHANGE MASTER TO" /backup/partial_dump.sql

通过这条命令，我们可以从备份文件中查找之前记录的主库 binlog 位置信息，这些信息后续会配置到从库的主从复制设置中。
接着，配置主库连接信息：

-- 配置主库连接信息（在从服务器上执行）
CHANGE REPLICA TO MASTER_HOST='192.168.73.110',  -- 主库IP，这里需要替换为实际的主库IP地址MASTER_USER='repluser',        -- 复制用户，要提前在主库创建好用于复制的用户，并赋予相应权限MASTER_PASSWORD='centos',      -- 复制用户密码，确保密码正确且保密MASTER_PORT=3306,              -- 主库端口，通常MySQL默认端口是3306，若有修改则填实际端口MASTER_LOG_FILE='mysql-bin.000003',  -- 从grep结果中获取对应的binlog文件名MASTER_LOG_POS=245,                 -- 从grep结果中获取对应的binlog位置坐标MASTER_RETRY_COUNT=10;             -- 连接重试次数，设置合适的重试次数以应对可能出现的网络等问题导致的连接失败-- 指定复制的数据库（在从服务器上执行）
CHANGE REPLICATION FILTER REPLICATE_DO_DB = (db1, db2);

配置时，务必准确填写各项参数，像主库IP、用于复制的用户及其密码等关键信息都要确保无误，以此保障从库能顺利连接主库进行数据复制，同时通过CHANGE REPLICATION FILTER语句明确指定只对db1和db2这两个数据库进行复制操作。

7. 启动从库复制（从服务器上执行）

START REPLICA;

遵循MySQL 8.0及以上版本的语法规范来启动从库的复制进程。

8. 验证复制状态（从服务器上执行）

SHOW REPLICA STATUS

查看输出结果时，重点留意以下两项是否显示为Yes：

• Replica_IO_Running：若该项为Yes，表明从库的I/O线程运行正常，可从主库读取binlog日志文件。
• Replica_SQL_Running：该项为Yes意味着从库的SQL线程运行正常，能将读取到的binlog内容解析并应用到从库中，保证数据的一致性。

若这两项中任何一项显示为No，就需要进一步排查诸如网络连接、主从库配置参数以及权限设置等方面是否存在问题。

报错处理方法

方法1. 跳过指定数量的事务（从服务器上执行）

mysql>slave stop;
mysql>SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
mysql>slave start

可根据实际情况，按需修改跳过的事务数量，该方法适用于确定某个事务导致复制中断且可跳过此事务的情形。

方法2. 修改配置文件跳过错误（从服务器上执行，需重启MySQL服务）

vi /etc/my.cnf

在[mysqld]配置项下面添加以下内容：

#slave-skip-errors=1062,1053,1146 （跳过指定类型错误，可按实际报错的错误编号填写）
slave-skip-errors=all （跳过所有错误，需谨慎使用，可能会掩盖潜在问题，导致数据不一致等情况）

添加配置后，要重启MySQL服务使配置生效。不过要特别强调，跳过所有错误这种方式属于极端做法，一般建议优先排查清楚错误原因，实在无法解决且明确对数据影响不大时再考虑使用。