溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
如何解決MySQL中gh-ost改雙主表結構主鍵沖突問題，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。
1)背景：
最近幫業務方排查了兩例主主復制丟數據或者主鍵沖突的問題，DB側的同事也問我這是什么一個原理，在解答他們的同時，順便也把這個問題記錄一下
2)現象：
公司一南北業務采用主主復制，而且該表的主鍵是自增ID，每個主庫的自增ID是錯開的，但是業務的主鍵卻出現了主鍵沖突，開始以為是設置不當，或者認為修改造成，但是翻看歷史記錄，沒人有過操作，而且配置也正確，沒人重啟；在調查binlog中，發現了一個有意思的現象,MySQL的一個主庫binlog中出現了兩條主鍵ID是一樣的binlog，而且是insert產生的binlog，具體現象如下：
17：19分一條
17:22分鐘的一條
開始自己的感覺是懵逼的，怎么主鍵相同，還能插入同一張表？后面猛然一想，這應該是gh-ost改表結構造成的（本公司DBA嚴重不足，部分DB操作只能讓業務運維也承擔一部分了）
3）模擬分析：
前提：假設有兩個雙主，分別叫主庫A與主庫B，上面存在表T，T表只有一個主鍵，在ghost修改之前的表，我們叫T,修改之后的表是T'(T跟T'其實是同一張表，只是產生的時間不同的叫法，方便表示)
①主庫B進行rename table T to T_old，new_t TO T操作，這時候主庫A是T'表了
②同時主庫A插入T表13的數據，但是主庫B還沒收到（延遲關系）
③主庫A的T表被主庫B傳過來的rename table T to T_old，new_t TO T修改，變成了T'；由于T'表在主庫B還沒收到第二步發過來的13，所以主庫A的T'表肯定也沒13這個值
④主庫A在這時又向T'插入13，正在復制給主庫B的T'中（由于延遲，還沒發送到主庫的T'表）
⑤主庫B的T'接收到第二步主庫A插入T的13
⑥第四步主庫A寫入T'的13已經傳到主庫B，發現B主庫的T'表已經有了13（第五步過來的），然后主鍵沖突
到此，主鍵沖突的原因已經找到，這種沖突意味著數據有丟失（此分析需要你對gh-ost的原理有充分的理解）
4）如何避免
在用gh-ost修改表結構的工程中，如果是雙主都有寫入，則必須將寫入切到單邊，然后再進行修改
看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
