“1236“12363

故障描述

自己搭建了一套my的主从复制环境，有2个多月没怎么管它，今天上去想要做一个因为主键冲突，导致失败的测试，发现mysql主从复制已经断开了，上去一看报了1236错误，详细错误信息如下所示：

[root@localhost] 16:54:01 [testdb1]>show slave statusG;
*************************** 1. row ***************************
Slave_IO_State:
Master_Host: 192.168.112.131
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: binlog.000019
Read_Master_Log_Pos: 194
Relay_Log_File: my
Relay_Log_Pos: 4
Relay_Master_Log_File: binlog.000019
Slave_IO_Running: No
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 194
Relay_Log_Space: 944
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: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 111213106
Master_UUID: 3ada166e-c4db-11ea-b21d-000c29cc2388
Master_Info_File: my
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp: 200902 16:54:01
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set: 3ada166e-c4db-11ea-b21d-000c29cc2388:1-84762,
3ada166e-c4db-11ea-b21d-000c29cc2389:1-7
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set sec)


Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'，
看这个报错信息，是由于复制需要的binary logs被删除了，所以导致主从复制失败，去主库上查看，日志已经没有了，这也就无法正常启动复制进程了。

解决方案

到这里，有2个解决方案
第一：重新搭建主从复制，在主库上做个全备，在从上库上恢复，然后配置主从复制
第二：由于是测试环境，数据的一致性不太重要，不用主从的复制的数据保持一致了，可以清除已经删除的binary logs日志的gtid信息，重启主从复制。

方法如下所示：
1.在主库上获取gtid_purged信息

[root@localhost] 17:24:12 [(none)]> show global variables like '%gtid%';
+----------------------------------+----------------------------------------------+
| Variable_name | Value |
+----------------------------------+----------------------------------------------+
| binlog_gtid_simple_recovery | ON |
| enforce_gtid_consistency | ON |
| gtid_executed | 3ada166e-c4db-11ea-b21d-000c39cc2398:1-74621 |
| gtid_executed_compression_period | 1000 |
| gtid_mode | ON |
| gtid_owned | |
| gtid_purged | 3ada166e-c4db-11ea-b21d-000c29cc2388:1-84829 |
| session_track_gtids | OFF |
+----------------------------------+----------------------------------------------+
8 rows in set sec)


2.登录从库，停止slave服务，重置slave

[root@localhost] 17:02:31 [testdb1]>stop slave;
Query OK, 0 rows affected sec)

[root@localhost] 17:03:40 [testdb1]>reset slave;
Query OK, 0 rows affected sec)

[root@localhost] 17:03:44 [testdb1]>set @@global.gtid_purged='3ada166e-c4db-11ea-b21d-000c29cc2388:1-84829';
Query OK, 0 rows affected sec)

[root@localhost] 17:03:48 [testdb1]>start slave;
Query OK, 0 rows affected sec)

[root@localhost] 17:03:56 [testdb1]>show slave statusG;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.112.131
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: binlog.000029
Read_Master_Log_Pos: 1881
Relay_Log_File: my
Relay_Log_Pos: 405
Relay_Master_Log_File: binlog.000029
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 1881
Relay_Log_Space: 612
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: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 111213106
Master_UUID: 3ada166e-c4db-11ea-b21d-000c29cc2388
Master_Info_File: my
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400


至此，主从复制已经恢复正常，当然在生产上不建议使用此方法，因为此方法，会导致主从数据不一致，在开发，测试环境是可以用的。

这个Mysql数据库技能你get了吧。