您的位置:首页 > 数据库 > MySQL

实战:一文带你解决Mysql主从复制日常错误

2021-02-28 22:49 946 查看

使用过Mysql数据库朋友,一定听过读写分离,听的多的,估计耳朵都起茧子了。那么读写分离是怎么实现的呢,最常见的方法就是搭建Mysql的主从复制,主库提供写操作,从库提供读操作,从而达到应用的读写分离。

对于刚入坑开发岗,运维岗的萌新们,一定要弄懂什么是读写分离,读写分离解决什么业务问题,只有彻底弄明白这些之后,才去用读写分离架构。

废话就不多说了,在这里就来说说,主从复制最常见的2种错误
第一种:主键冲突(Error_code: 1062)
第二种:记录丢失,例如update,delete操作,在从库找不到对应记录(Error_code: 1032)

下面来详细模拟一下记录丢失,处理全过程

检查主从复制是否正常

[root@localhost] 11:34:29 [testdb]>show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.0.1
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: binlog.000029
Read_Master_Log_Pos: 3683
Relay_Log_File: mysql-relay-bin.000003
Relay_Log_Pos: 2207
Relay_Master_Log_File: binlog.000029
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

可以看到IO线程和SQL线程运行都是正常的。

创建测试表和记录

[root@localhost] 11:25:48 [testdb]>show create table test1\G;
*************************** 1. row ***************************
Table: test1
Create Table: CREATE TABLE `test1` (
`id` int(11) NOT NULL,
`name1` char(10) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
`name2` char(20) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
1 row in set (0.07 sec)

insert into test1 values(1,'test1','test1');
insert into test1 values(2,'test2','test2');
insert into test1 values(3,'test3','test3');

模拟主从复制由于从库记录缺失,导致主从复制失败

第一步:在从库中删除id=2的记录

[root@localhost] 11:26:41 [testdb]>delete from test1 where id=2;
Query OK, 1 row affected (0.44 sec)

[root@localhost] 11:26:52 [testdb]>select * from test1;
+----+-------+-------+
| id | name1 | name2 |
+----+-------+-------+
|  1 | test1 | test1 |
|  3 | test3 | test3 |
+----+-------+-------+
2 rows in set (0.00 sec)

第二步:在主库上删除id=2的记录

[root@localhost] 11:27:11 [testdb]>delete from test1 where id=2;
Query OK, 1 row affected (0.17 sec)

[root@localhost] 11:27:51 [testdb]>select * from test1;
+----+-------+-------+
| id | name1 | name2 |
+----+-------+-------+
|  1 | test1 | test1 |
|  3 | test3 | test3 |
+----+-------+-------+
2 rows in set (0.00 sec)

在从库上查看主从复制情况

[root@localhost] 11:34:05 [testdb]>show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.0.1
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: binlog.000029
Read_Master_Log_Pos: 3683
Relay_Log_File: mysql-relay-bin.000003
Relay_Log_Pos: 1929
Relay_Master_Log_File: binlog.000029
Slave_IO_Running: Yes
Slave_SQL_Running: No
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 1032
Last_Error: Could not execute Delete_rows event on table testdb.test1; Can't find record in 'test1', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log binlog.000029, end_log_pos 3652
Skip_Counter: 0
Exec_Master_Log_Pos: 3405
Relay_Log_Space: 2414
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 1032
Last_SQL_Error: Could not execute Delete_rows event on table testdb.test1; Can't find record in 'test1', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log binlog.000029, end_log_pos 3652
Replicate_Ignore_Server_Ids:
Master_Server_Id: 111213106
Master_UUID: 3ada166e-c4db-11ea-b21d-000c29cc2388
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State:
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp: 200904 11:33:10
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 3ada166e-c4db-11ea-b21d-000c29cc2388:84830-84835
Executed_Gtid_Set: 3ada166e-c4db-11ea-b21d-000c29cc2388:1-84834,
3ada166e-c4db-11ea-b21d-000c29cc2389:1-4
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)

此时主从的sql线程已经是停止状态,主从复制的数据已经不同步了。复制开始报1032错误了。

要解决1032错误,可以有以下3中方案
方案一:手工将缺失的业务记录在主库上导出,并导入到从库,然后启动从库的sql线程就可以了。慢着,大家有没有注意到一个问题,就是在主库上,到底要导出哪条记录,报错信息里并没有,但是有提示,he event's master log binlog.000029, end_log_pos 3652,所以还需要将binlog日志里的内容解析处理,找到要操作的记录,似乎有些麻烦。不用慌,还有方案二,方案三。

方案二:Mysql数据库提供一个参数slave_skip_errors,这个参数可以跳过指定错误代码的sql语句,例如:slave_skip_errors=1032,可惜,这个参数不能在线修改,修改生效需要重启实例,是不是也太友好。

[root@localhost] 11:28:57 [testdb]>set global slave_skip_errors=1032;
ERROR 1238 (HY000): Variable 'slave_skip_errors' is a read only variable

方案三:使用percona-toolkits工具集中的pt-slave-restart工具,自动跳过主从同步指定的报错代码sql语句,此方法对mysql数据侵入性小,不必重启Mysql实例

[mysql@mysql ~]$ pt-slave-restart --user=root --password=root --socket=/data/mysql/run/3306/mysql.sock --error-numbers=1032

# A software update is available:
2020-09-04T11:32:07 S=/data/mysql/run/3306/mysql.sock,p=...,u=root mysql-relay-bin.000003        1651 1032

当跳过主从同步指定的报错代码sql语句,主从复制恢复之后,间隔64秒,会再次自动检测主从复制是否有1032错误。

其它类似的错误,都可以用以上三种方法方案处理,建议大家使用方案三。

内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: