MySQL級聯複製中資料同步

    最近開發的同事反饋了一個問題，說有一臺北京節點的MySQL資料庫資料延遲太大，想讓我們幫忙看看怎麼解決。

    這個問題一下子讓我想起了之前“水深火熱”的日子，因為這是一套MySQL級聯複製的環境。這麼做的目的也是為了能夠方便資料查詢和統計任務，看起來雖好，但是老是有一些不可控因素。

   北美使用AWS在北美，都是實時的業務資料，考慮了災備和讀寫分離使用了一主一從的架構，新加坡節點2是一箇中繼節點，也使用了AWS，可以看到新加坡節點是北美節點的從庫，但是北京的主庫。 北京節點是一個IDC裝置。就這樣一個級聯複製的環境就跑起來了。

由於新加坡的節點網路延遲太大，而且很不穩定，之前的一部分業務最後就索性遷移到香港的雲服務上了。剩下的這部分業務穩定執行了一段時間，但是最近經常發現資料延遲很大，這個問題又提上了日程。

我們經過討論，開發同事建議，索性直接連北美節點吧，我這邊簡單做了測試，網速其實還是要好一點。所以改進後的架構如下：

但是這裡就面臨一個問題，怎麼去無縫的把節點的資料順利切換過去。發現這個問題變得有些糾結了，因為新加坡的節點目前和北京節點是有延遲，直接切換過去肯定不行，而且偏移量在不同的節點都有不小的差別。怎麼調和呢。

每當到這個時候我就想起了MySQL非常經典的架構圖。

碰到實際的問題再來看的時候發現有很多地方就需要加深理解了。

單純使用偏移量，我和同事在紙上分析和討論，感謝總是有一些不確定的地方。這讓我就非常懷念起了5.6推出的GTID，這個特性在這個問題前真是太有用了。GTID的統一格式是由source_id加transaction_id構成。這個source_id就是UUID,是一個唯一性標示，在讀寫分離，一主多從的環境，還有當下的級聯複製的環境中尤其有用，因為是全域性事務的概念，所以不會出現重複的情況，這一點和Oracle裡物理一致性的SCN很有相似的味道。

在這個問題中，如果能夠啟用GTID,那麼北美節點的UUID在北京節點還是一個唯一性的標示，能夠正確的標識和應用事務資訊。

但是當前的環境是5.5版本，很遺憾使用不了，那麼一種折中的辦法就是停止新加坡的節點，然後讓北京節點去追平資料，然後以這個為基準，讓北京節點繼續從北美的slave節點繼續抓取增量的資料變化。

整個過程就會使用change master的方式來完成了。