MySQL錯誤1236當使用GTID

我想創建一個副本到我的Percona Server和GTID啓用，但得到這個錯誤，當我告訴從屬狀態：MySQL錯誤1236當使用GTID

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.'

通常情況下，我會停止我的奴隸，重置，復位主站（在從站上），並從主站獲取新的GTID_PURGED值。但是這一次，主有一個非常不尋常的值（一個或多個），我不知道如何確定使用哪一個：

mysql> show master status\G 
*************************** 1. row *************************** 
      File: mysqld-bin.000283 
     Position: 316137263 
    Binlog_Do_DB: 
Binlog_Ignore_DB: 
Executed_Gtid_Set: 1570dee1-165b-11e6-a4a2-00e081e93212:1-3537, 
c73f3ee7-e8d4-ee19-6507-f898a9930ccd:1-18609, 
cdb70eaa-f753-ee1b-5c95-ecb8024ae729:1-2357789559:2357789561-2357790104:2357790106-2514115701:2514115703-2514115705:2514115707-2546512667 
1 row in set (0.00 sec)

從與新的備份副本的奴隸，我得到這個：

[email protected]:/var/lib/mysql# cat xtrabackup_binlog_info 
mysqld-bin.000283  294922064  1570dee1-165b-11e6-a4a2-00e081e93212:1-3537, 
c73f3ee7-e8d4-ee19-6507-f898a9930ccd:1-18609, 
cdb70eaa-f753-ee1b-5c95-ecb8024ae729:1-2357789559:2357789561-2357790104:2357790106-2514115701:2514115703-2514115705:2514115707-2546400960

還有一件事，我只是在進行備份之前清除了主服務器上的二進制日誌。自動binlog清除設置爲7天。所以我知道它不是因爲bin日誌已被清除，因爲錯誤提示。

我運行的是Ubuntu 14:04和Percona服務器版本5.6.31-77。

我該如何解決此問題？主人的GTID_PURGED的正確價值是什麼？

來源

2016-07-15 The Georgia

mysql 5.6 GTID複製錯誤和修復程序什麼是GTID？

4c2ad77f-697e-11e3-b2c3-c80aa9f17dc4

這是服務器的128位的識別號（SERVER_UUID）。它確定交易的起源地點。每個服務器都有自己的SERVER_UUID。 GTID解決什麼問題？
可以通過複製服務器唯一地識別事務。使故障轉移過程的自動化更容易。不需要進行計算，檢查二進制日誌等。只需MASTER_AUTO_POSITION = 1。
在應用程序級別，執行WRITE/READ拆分更容易。在MASTER上寫入數據之後，你有一個GTID，所以只需檢查一下GTID是否在用於讀取的SLAVE上執行。
現在，開發新的自動化工具並不是一件痛苦的事情。我該如何實現它？需要在複製鏈的所有服務器
- gtid_mode
三個變量：它可以是ON或OFF（不1或0）。它啓用了服務器上的GTID。
log_bin：啓用二進制日誌。強制創建複製環境。
log-slave-updates：從服務器必須在其自己的二進制日誌中記錄來自主服務器的更改。
enforce-gtid-consistency：無法以事務安全方式記錄的語句被服務器拒絕。 REF：http://dev.mysql.com/doc/refman/5.6/en/replication-gtids-howto.html

複製的錯誤和修正：

「'從二進制日誌讀時的數據從主站得到致命錯誤1236：」從站使用CHANGE MASTER TO MASTER_AUTO_POSITION = 1連接，但主已經清除了包含從站需要的GTID的二進制日誌。「slave_io線程停止運行。

分辨率：考慮以下是主 - 從UUID的

MASTER UUID：4c2ad77f-697e-11e3-b2c3-c80aa9f17dc4

SLAVE UUID：5b37def1-6189-11e3-bee0-e89a8f22a444

步驟：

slave> stop slave;

slave>帶鎖定的平板電腦表;

slave> show master status;

「4c2ad77f-697e-11e3-b2c3-c80aa9f17dc4：1-83345127,5b37def1-6189-11e3-bee0-e89a8f22a444：1-13030：13032-13317：13322-13325：13328-653183：653185-654126：654128 -1400817：1400820-3423394：3423401-5779965'

（HERE 83345127上主站和5779965最後從屬GTID上萬事達執行執行最後GTID）

從屬>重置主;

slave> set global GTID_PURGED ='4c2ad77f-697e-11e3-b2c3-c80aa9f17dc4：1-83345127,5b37def1-6189-11e3-bee0-e89a8f22a444：1-5779965';

slave> start slave;

奴隸>解鎖表;

slave> show slave status;

注意：在此之後，如果它們停止複製，重新啓動從屬鏈路 - 從屬鏈路;

錯誤：'錯誤'表...'不存在'在查詢上。默認數據庫：...查詢：「INSERT INTO或Last_SQL_Error：... .Error‘重複項’跳過從事務處理（slave_sql線程停止運行）注：

SQL_SLAVE_SKIP_COUNTER不再跟隨GTID工作。
我們需要找出導致複製失敗的事務。
- - 從二進制日誌
- - 從SHOW SLAVE STATUS（檢索VS執行）類型的錯誤：（檢查顯示從屬地位的最後一個SQL錯誤）

分辨率：考慮以下是主 - 從UUID的

MASTER UUID：4c2ad77f-697e-11e3-b2c3-c80aa9f17dc4

SLAVE UUID：5b37def1-6189-11e3-bee0-e89a8f22a444

slave> show slave status;

複製'Executed_Gtid_Set'值。 '4c2ad77f-697e-11e3-b2c3-c80aa9f17dc4：1-659731804,5b37def1-6189-11e3-bee0-e89a8f22a444：1-70734947-80436012：80436021-80437839'

-Seems該從屬（以uuid 5b37def1-6189- 11e3-bee0-e89a8f22a444）交易'80437840'在這裏引起問題。

slave> STOP SLAVE;

slave> SET GTID_NEXT =「5b37def1-6189-11e3-bee0-e89a8f22a444：80437840」; （last_executed_slave_gtid_on_master + 1）

slave> BEGIN;承諾;

slave> SET GTID_NEXT =「AUTOMATIC」;

slave> START SLAVE;

slave> show slave status;

它的全部設置！

來源

2017-01-30 05:37:23 Obivan

MySQL錯誤1236當使用GTID

回答

相關問題