常见的主从报错集锦

发布于: 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
用户头像

现在是你们的,未来是我们的 2020.01.11 加入

爱生活,爱DB

评论

发布
暂无评论
常见的主从报错集锦