首頁 > 文章 > 資料庫 > 一起聊聊MySQL主從延時的處理方案

一起聊聊MySQL主從延時的處理方案

WBOY轉載: 2022-01-17 18:28:382014瀏覽

這篇文章為大家帶來了關於mysql中主從延時處理方案的相關知識，MySQL主從複製，讀寫分離是互聯網常見的資料庫架構，該架構最令人詬病的地方就是，在在資料量較大且發量較大的場景下，主從延時會比較嚴重。希望對大家有幫助。

一起聊聊MySQL主從延時的處理方案

為什麼主從延時這麼大？

#答案：MySQL使用單執行緒重播RelayLog。

該怎麼優化，縮短重播時間？

答案：多執行緒並行重播RelayLog可以縮短時間。

多執行緒並行重播RelayLog有什麼問題？

一起聊聊MySQL主從延時的處理方案

答案：需要考慮如何分割RelayLog，才能讓多個資料庫實例，多個執行緒並行重播RelayLog，不會出現不一致。

為什麼會出現不一致？

答案：如果RelayLog隨機的分配給不同的重播線程，假設RelayLog中有這樣三個序列的修改記錄：

update account set money=100 where uid=58;

update account set money=150 where uid=58;

update account set money=200 where uid=58;

如果單執行緒串列重播：能確保所有從庫與主庫的執行序列一致。

畫外音：最後money都會為200。

如果多執行緒隨機分配重播：多重放執行緒並發執行這3個語句，誰最後執行是不確定的，最終從函式庫資料可能與主函式庫不同。

畫外音：多個從庫可能money為100，150，200不確定。

如何分配，多個從函式庫多執行緒重播，也能得到一致的資料呢？

答案：在相同函式庫上的寫入操作，用相同的執行緒來重播RelayLog；不同函式庫上的寫入操作，可以並發多個執行緒並發來重播RelayLog。

一起聊聊MySQL主從延時的處理方案

如何做到？

答案：設計一個雜湊演算法，hash(db-name) % thread-num，庫名hash之後再模上執行緒數，就能很輕易做到，同一個庫上的寫入操作，被同一個重播執行緒串列執行。

畫外音：不同函式庫上的重放，是並行的，就起到了加速做用。

這個方案有什麼不足之處？

答：很多公司對MySQL的使用是“單庫多表”，如果是這樣的話，仍然只有一個庫，還是不能提高RelayLog的重播速度。

啟示：將「單庫多表」的DB架構模式升級為「多庫多表」的DB架構模式。

畫外音：資料量大並發量大的網路業務場景，「多庫」模式還具備其他許多優勢，例如：

（1）非常方便的實例擴充：DBA很容易將不同的函式庫擴展到不同的實例；

（2）依照業務進行函式庫隔離：業務解耦，進行業務隔離，減少耦合與相互影響；

（3）非常方便微服務拆分：每個服務擁有自己的實例就方便了；

「單庫多表」的場景，多執行緒並行重播RelayLog還能怎麼優化？

答：即使只有一個庫，事務在主庫上也是並發執行的，既然在主庫上可以並行執行，在從庫上也應該能夠並行執行呀？

新想法：將主庫上同時並行執行的事務，分為一組，編一個號，這些事務在從庫上的回放可以並行執行（事務在主庫上的執行都進入到prepare階段，表示事務之間沒有衝突，否則就不可能提交），沒錯，MySQL正是這麼做的。

解法：基於GTID的平行複製。

從MySQL5.7開始，將群組提交的資訊存放在GTID中，使用mysqlbinlog工具，可以看到群組提交內部的資訊：

20181014 23:52 server_id 58 XXX GTID last_committed=0 sequence_numer=1
20181014 23:52 server_id 58 XXX GTID last_committed=0 sequence_numer=2
20181014 23:52 server_id 58 XXX GTID last_committed=0 sequence_numer=3
20181014 23:52 server_id 58 XXX GTID last_committed=0 sequence_numer=4

一起聊聊MySQL主從延時的處理方案