從庫kill -9重啟之後，複製出現異常：

mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State:
Master_Host: xxx.xxx.xxx.xxx
Master_User: xxxx
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000355
Read_Master_Log_Pos: 215225678
Relay_Log_File: relay-log.001016
Relay_Log_Pos: 4
Relay_Master_Log_File: mysql-bin.000355
Slave_IO_Running: No
Slave_SQL_Running: No
Replicate_Do_DB:
Replicate_Ignore_DB: mysql,information_schema,performance_schema,sys
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: 215225678
Relay_Log_Space: 215226373
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: xxxxx
Master_UUID: 890e600a-e0f2-11e8-826c-0050568157da
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: 181114 14:02:04
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set: 040a3a9f-b937-11e7-a9ca-286ed488c634:1-386444612:386544650-389781411,
3279fdcd-7069-11e6-afde-286ed488e688:912705988-916878942:916878944-918363200:918363202-918373936:929542564-931556374:931556377:931556382:931556384-931556385:931556387-931556388:931556391-931556401:931556410-931556412:931556418:931556420:931556422:931556424-931556426:931556429-931556505:931556507-931556586:931556588-931556592:931556594:931556596-931556623:931556625:931556637:931556639:931556641-931556642:931556644:931556646-931556705:931556715:931556719-931556723:931556730-931556733:931556735-931556736:931556738-931556744:931556746-931556756:931556758-931556760:931556762-931556763:931556767:931556769-931556771:931556773:931556777:931556782-931556783:931556785:931556787-931556790:931556794:931556796:931556798-931556828:931556832-931556839:931556841:931556843-931556844:931556847:931556851:931556853:931556858-931556859:931556861-931556886,
890e600a-e0f2-11e8-826c-0050568157da:1-52297118,
fc821904-b936-11e7-a45f-286ed488c635:15-17
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version

可以看到從庫當前已經應用的gtid為890e600a-e0f2-11e8-826c-0050568157da:1-52297118，而主庫binlog的位置則應用到了mysql-bin.000355的215225678位置。要是問我怎麼那麼多不同的uuid，一看就是個不正經的從庫，鬼知道它經歷了什麼。
可以確定的是，主庫的binlog沒有被清除，因為從庫是kill掉之後馬上拉起來了，主庫也沒執行過purge binary log操作。
那麼根據master file:mysql-bin.000355，pos:215225678到主庫去看個究竟。

at 215225647

#181114 13:29:00 server id xxxx end_log_pos 215225678 CRC32 0xc972a419 Xid = 605179606
COMMIT/!

/;

at 215225678

#181114 13:29:00 server id xxxx end_log_pos 215225743 CRC32 0x55a06777 GTID last_committed=185251 sequence_number=185252
SET @@SESSION.GTID_NEXT= ‘890e600a-e0f2-11e8-826c-0050568157da:59553159’/!/;

發現在pos:215225678之後，GTID_NEXT= ‘890e600a-e0f2-11e8-826c-0050568157da:59553159’
與從庫show slave status中的890e600a-e0f2-11e8-826c-0050568157da:1-52297118明顯出現了斷層，而且還隔得有點遠了。
基本可以判斷，由於kill -9導致從庫記錄的相關gtid資訊出現異常了，那麼如果重新指定正確的gtid呢？
嘗試通過

MYSQL>stop slave;
MYSQL>reset master;
MYSQL>set @@global.gtid_purged=‘040a3a9f-b937-11e7-a9ca-286ed488c634:1-386444612:386544650-389781411,
3279fdcd-7069-11e6-afde-286ed488e688:912705988-916878942:916878944-918363200:918363202-918373936:929542564-931556374:931556377:931556382:931556384-931556385:931556387-931556388:931556391-931556401:931556410-931556412:931556418:931556420:931556422:931556424-931556426:931556429-931556505:931556507-931556586:931556588-931556592:931556594:931556596-931556623:931556625:931556637:931556639:931556641-931556642:931556644:931556646-931556705:931556715:931556719-931556723:931556730-931556733:931556735-931556736:931556738-931556744:931556746-931556756:931556758-931556760:931556762-931556763:931556767:931556769-931556771:931556773:931556777:931556782-931556783:931556785:931556787-931556790:931556794:931556796:931556798-931556828:931556832-931556839:931556841:931556843-931556844:931556847:931556851:931556853:931556858-931556859:931556861-931556886,
890e600a-e0f2-11e8-826c-0050568157da:1-52297118,
fc821904-b936-11e7-a45f-286ed488c635:15-17’； 或
MYSQL>set @@global.gtid_purged=‘890e600a-e0f2-11e8-826c-0050568157da:1-59553158’；
MYSQL>start slave;

啟動後是一樣的報錯。怎麼辦，向命運低頭嗎？低頭是不可能低頭的，頸椎都焊死了。坐不了公交那就打個車吧。
首先確認當前relay log是已經全部應用完了，那麼，用不了gtid高科技，那就用回經典套路吧。
從主庫的binlog內容來看，pos215225678之前的事務已經commit了，也就是從這裡重新開始不需要重做也不需要回滾，那麼可以瀟灑地嘗試一下：

MYSQL>CHANGE MASTER TO
MASTER_HOST=‘xxx.xxx.xxx.xxx’,
MASTER_PORT=3306,
MASTER_USER=‘xxxx’,
MASTER_PASSWORD=‘xxxx’,
master_auto_position=0,
master_log_file=‘mysql-bin.000355’,
master_log_pos=215225678;
MYSQL>start slave

從庫複製恢復正常了。