常见的主从报错集锦

 关注
发布于: 2020 年 05 月 15 日
﻿
MySQL主从同步报错故障处理集锦在发生故障切换后，经常遇到的问题就是同步报错，下面列举了几种比较常见的情况以及处理方法、
1.1032记录删除失败﻿
解决方法
Master要删除一条记录，而slave上找不到报错，这种情况主都已经删除了，那么从都可以直接跳过
stop slave ;SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; start 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的数据是否一致。
如果一致，则跳过
stop slave ;SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; start slave;
如果不一致，则在从库上删除重复的主键
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缺失﻿
解决方法
首先停止从库同步
stop slave ;
查看主库日志文件和位置
mysql> show master logs;
+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000013 |       154 |
+------------------+-----------+
回从库，使日志文件和位置对应主库
change master to master···
最后，启动从库
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)
﻿
发布于: 2020 年 05 月 15 日阅读数: 74
原文链接:【http://xie.infoq.cn/article/af40aa6ca4d86263fa063025f】。文章转载请联系作者。
一个有志气的DB

 关注
现在是你们的，未来是我们的 2020.01.11 加入
爱生活，爱DB
发布
暂无评论