MySQL主从同步报错故障处理集锦

在发生故障切换后，经常遇到的问题就是同步报错，下面列举了几种比较常见的情况以及处理方法、

1.1032记录删除失败

解决方法

Master要删除一条记录，而slave上找不到报错，这种情况主都已经删除了，那么从都可以直接跳过

2.1032更新丢失

解决方法

• 在Master上，用Binlog日志分析下出错的Binlog日志在干什么。

由于线上的数据都是row格式，用mysqlbinlog解析出来后用binlog2sql工具解析出具体的sql

• 在Slave上，查找下更新后的那条记录，应该是不存在的。

mysql> select * from t1 where id=2;
Empty set (0.00 sec)

• 然后再到Master上查看

mysql> select * from t1 where id=2;
+----+------+
| id | name |
+----+------+
|  2 | cjl  | 
+----+------+
1 row in set (0.00 sec)

• 把丢失的数据在Slave上填补，然后跳过报错即可。

mysql> insert into t1 values (2,'cjl');
Query OK, 1 row affected (0.00 sec)
mysql> select * from t1 where id=2;    
+----+------+
| id | name |
+----+------+
|  2 | cjl  | 
+----+------+
1 row in set (0.00 sec)
mysql> stop slave ;set global sql_slave_skip_counter=1;start slave;
Query OK, 0 rows affected (0.01 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
mysql> show slave status\G;
……
 Slave_IO_Running: Yes
 Slave_SQL_Running: Yes
……

3.1062主键重复

解决方法

• 在slave上用desc hcy.t1；看下的表结构：

mysql> desc hcy.t1;
+-------+---------+------+-----+---------+-------+
| Field | Type    | Null | Key | Default | Extra |
+-------+---------+------+-----+---------+-------+
| id    | int(11) | NO   | PRI | 0       |       | 
| name  | char(4) | YES  |     | NULL    |       | 
+-------+---------+------+-----+---------+-------+

• 查看从库ID=2的数据是否跟主库ID=2的数据是否一致。

• 如果一致，则跳过

• 如果不一致，则在从库上删除重复的主键

mysql> delete from t1 where id=2;
Query OK, 1 row affected (0.00 sec)
mysql> start slave;
Query OK, 0 rows affected (0.00 sec)
mysql> show slave status\G;
……
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
……
mysql> select * from t1 where id=2;

4.1236错误,binlog缺失

解决方法

首先停止从库同步

查看主库日志文件和位置

mysql> show master logs;
+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000013 |       154 |
+------------------+-----------+

回从库，使日志文件和位置对应主库

最后，启动从库

start slave;
show slave status\G
Master_Log_File: mysql-bin.000013
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Last_IO_Error:

5.1236错误主库重启

解决方法

• 登录到Master主机，执行命令查看对应的报错日志跟最后的位置

[root@mysqlmaster2 mysql]# mysqlbinlog --no-defaults mysql-bin.001359 >> /tmp/123.log
[root@mysqlmaster2 mysql]# vi /tmp/123.log 
[root@mysqlmaster2 mysql]# tail -f /tmp/123.log 
insert into tb_o2n2 (device_o2_id,type,value,rectime)values(1,"N2",0,"2018-11-05 00:15:31.550817")
/*!*/;
# at 61918946
#181105  0:15:36 server id 2  end_log_pos 61918977 CRC32 0xc9906a5c     Xid = 157867719
COMMIT/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

在Slave上去执行

->stop slave;
    ->···
  -> MASTER_LOG_FILE="mysql-bin.001359",
    -> MASTER_LOG_POS=61918977
  ->···
    ->start slave;

6.1593中继日志损坏

解决方法

• 找到同步的binlog和POS点，然后重新做同步，这样就可以有新的中继日志生成了。

···
Relay_Master_Log_File: mysql-bin.000010
Exec_Master_Log_Pos: 821
···
mysql> stop slave;
Query OK, 0 rows affected (0.01 sec)
mysql> CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000010',MASTER_LOG_POS=821;
Query OK, 0 rows affected (0.01 sec)
mysql> start slave;
Query OK, 0 rows affected (0.00 sec)