MySQL GTID複製中斷修復過程

slave中出現錯誤：

2020-04-09T07:40:18.719203Z 16 [ERROR] Slave SQL for channel '': Could not execute Write_rows event on table mytestdb.t1; Duplicate entry '6' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysql-bin.000050, end_log_pos 437, Error_code: 1062

2020-04-09T07:40:18.719237Z 16 [Warning] Slave: Duplicate entry '6' for key 'PRIMARY' Error_code: 1062

2020-04-09T07:40:18.719246Z 16 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'mysql-bin.000050' position 194.

這是由於我人為往表中製造了主鍵衝突

檢視slave的gtid資訊:

mysql> show global variables like '%gtid%';

+----------------------------------+---------------------------------------------------------------------------------------+

| Variable_name                    | Value                                                                                 |

+----------------------------------+---------------------------------------------------------------------------------------+

| binlog_gtid_simple_recovery      | ON                                                                                    |

| enforce_gtid_consistency         | ON                                                                                    |

| gtid_executed                    | 2ff0b1ed-5dc8-11ea-9878-000c29872e9a:1-6957,

3853efe2-5dc8-11ea-86cb-000c295618b3:1-2 |

| gtid_executed_compression_period | 1000                                                                                  |

| gtid_mode                        | ON                                                                                    |

| gtid_owned                       |                                                                                       |

| gtid_purged                      | 2ff0b1ed-5dc8-11ea-9878-000c29872e9a:1-2                                              |

| session_track_gtids              | OFF                                                                                   |

+----------------------------------+---------------------------------------------------------------------------------------+

檢視master的gtid資訊：

root@dv 15:40:  : [(none)]>show global variables like '%gtid%';

+----------------------------------+---------------------------------------------+

| Variable_name                    | Value                                       |

+----------------------------------+---------------------------------------------+

| binlog_gtid_simple_recovery      | ON                                          |

| enforce_gtid_consistency         | ON                                          |

| gtid_executed                    | 2ff0b1ed-5dc8-11ea-9878-000c29872e9a:1-6958 |

| gtid_executed_compression_period | 1000                                        |

| gtid_mode                        | ON                                          |

| gtid_owned                       |                                             |

| gtid_purged                      | 2ff0b1ed-5dc8-11ea-9878-000c29872e9a:1-2    |

| session_track_gtids              | OFF                                         |

+----------------------------------+---------------------------------------------+

設定從庫的gtid_next

mysql> SET GTID_NEXT="2ff0b1ed-5dc8-11ea-9878-000c29872e9a:1-6957";

ERROR 1774 (HY000): Malformed GTID specification '2ff0b1ed-5dc8-11ea-9878-000c29872e9a:1-6958'.

mysql> SET GTID_NEXT="2ff0b1ed-5dc8-11ea-9878-000c29872e9a:6957";

Query OK, 0 rows affected (0.00 sec)

mysql> 

mysql> begin;

Query OK, 0 rows affected (0.00 sec)

mysql> commit;

Query OK, 0 rows affected (0.00 sec)

這裡是模擬一個事務，代替出錯的事務

mysql> SET GTID_NEXT="AUTOMATIC"

    -> ;

Query OK, 0 rows affected (0.00 sec)

緊接著start slave即可

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/8520577/viewspace-2685227/，如需轉載，請註明出處，否則將追究法律責任。