MySQL主从复制常见的错误有哪些？如何处理？

如何用三分钟学会MySQL知识？来看GreatSQL社区的短视频。大家好，欢迎来到GreatSQL社区的第十五期《用三分钟学会一个MySQL知识》。

MySQL主从复制中常见的错误有哪些？如何处理？

一、1032错误。当从库比主库少数据时，会出现1032错误。这种错误分为 UPDATE 场景和 DELETE 场景。

1. 针对 UPDATE 场景，处理思路是：在从库上补上丢失的数据。

2. 找到停止位置（Relay_Master_Log_File 和 Exec_Master_Log_Pos）。

3. 从主库解析对应位置的 binlog，获取到 UPDATE 相关的数据。

4. 在从库上插入数据。

5. 重启 sql_thread。

针对 DELETE 场景，处理思路是：跳过该事务。

对于非 GTID 环境，可以通过设置 sqlL_slave_skip_counter=1 跳过该事务。

对于 GTID 环境，可以通过注入空事务方式跳过该事务。

具体步骤如下：

1. setgtid_next=xxx。

2. BEGIN COMMIT。

3. set gtid_next="AUTOMATIC"。

二、1062错误。

当从库比主库多数据（主键冲突情况）时，会出现1062错误。

处理思路比较简单，即删除对应的主键冲突数据即可：

1. 删除从库上对应的数据（根据主键）。

2. 重启 sql_thread。

三、1236错误。

当从库需要开始同步的 binlog 位置已经不存在主库上时，会出现1236错误。

该错误出现的情况有三种：

1. GTID 从库需要开始复制的 GTID 要比主库上已经 purged GTID 位置要小。

2. GTID 从库 GTID_SET 比主库上缺失部分，如主库有多个 GTID_SET 而从库只有一个。

3. 非 GTID 环境下，从库去拉 binlog 的时间找不到对应的 binlog，即从库当前的 binlog 比主库最旧的 binlog 之间存在缺失。

对应的处理方式是：

1. 对于 1、3 两种情况，建议直接通过备份的方式重新做主从。

2. 对于第 2 种情况，可以通过 set global gtid_purged='xxx 的方式将差异的 GTID_SET 部分补全。

最后，为了避免这类错误再次发生，有以下几点建议：1.在主库上启用双1模式，即sync_binlog=1和innodb_flush_log_at_trx_commit=1，以确保数据的可靠性。

2.将从库设置为只读模式，super_read_only=1，read_only=1，以避免人为误操作导致数据的修改或删除。

3.在MTS模式下，设置选项replica_preserve_commit_order=1，以尽可能保证从库上事务的一致性。

本期视频到此结束，感谢大家的观看。