MySQL高可用架構案例篇：UCloud最佳實踐

內容來源：2017年7月22日，UCloud高級研發工程師王鬆磊在「餓了麼技術沙龍【第九彈】上海研發中心·運維專場」進行《數據庫高可用架構》演講分享。IT 大咖說（微信id：itdakashuo）做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：3280 | 9分鐘閱讀

嘉賓演講視頻及PPT回顧： suo.im/2obXuQ

摘要

分享UCloud在數據庫高可用上的最佳實踐。首先介紹MYSQL常見的高可用方式，並分析其存在的問題，而後給出UCloud對此的思考和解決方法。

MySQL常見的數據同步方式

MySQL數據同步方式大致分爲兩大類，第一類是使用MySQL傳統的異步或半同步複製協議，比較典型的有MHA+MySQL或者**Proxy+MySQL。第二類是使用分佈式協議，這方面有Group Replication或Galera Cluster+MySQL。

原生的異步或半同步複製協議

首先來看下原生的異步或半同步複製協議。它經過Master的dump線程與Slave的IO線程進行交互，當binglog發生更新時，將Binlog傳輸到Slave,實現Master和Slave的數據同步。

而後還能夠經過使用不一樣的拓撲結構來實現不一樣的功能，如master和多個Slave作數據同步，如多個master相互搭建複製。目前絕大多數的Proxy產品都是使用MySQL的原生複製做爲數據同步方式。

分佈式協議作數據同步

這種是近幾年新興的同步方式，它的分佈式算法是經過選舉的方式，解決在分佈式的系統中如何就某一決議達成一致的問題。

使用分佈式合力作數據同步的方式，在近兩年出現了一系列開源或閉源的產品，如騰訊的phxsql、perconna和mariadbde galera插件、社區版的Group、Tidb等。分佈式協議一般須要至少三節點的MySQL，相比於原生的MySQL複製提供了更可靠的保證數據一致性的方法，可是因爲技術教新（相比於MySQL複製），暫時並無替代原生複製成爲成爲絕大多數MySQL數據庫同步方式。

MySQL雙節點架構

經典的雙節點架構有一個VIP接入某一個Proxy，而後下端接一主一從兩個節點，從節點作一個數據總集的節點，以防止當主節點掛掉後，服務仍然可使用，固然也能夠做爲備份來用。

這種架構使用binglog這種二進制日誌的方式來作主從同步，採用半同步進行複製，Proxy同一時間只接入有一個節點，另外還能夠根據需求選擇是否使用GTID或進行拓撲結構的擴展。

當發生異常狀況，例如Master發生宕機後，Proxy會將業務切換到Slave，宕機恢復後，再將業務回切並進行數據回補，或者使用恢復後的Master做爲新的Slave，從新搭建複製。

MySQL複製常見問題

上圖時序圖能夠從中間分開，左邊是主節點，右邊是從節點。主庫任何的事務結束後都會同步到從庫，保證數據的一致性。

退化爲異步複製

主庫在發送binglog的時候會等待從庫的應答，而沒有接受到應答就會出現超時問題。這就會形成下一個事務到達的時候主庫就不會再應答了，也就咱們說的退化，從半同步複製退化到異步複製。退化以後數據的一致性就會得不到保證。

退化的複製是能夠恢復爲半同步複製的。每一個事務提交時，會在半同步插件記錄當前記錄的binglog的文件名和位置。IO線程在記錄relay log完成後，會將relay log對應的主庫的binglog的文件和位置發送給。Dump線程在接受應答後，會對比Slave發送的應答和半同步插件記錄的內容，若是Slave發送的文件和位置要大於等於半同步插件中記錄的內容，那麼恢復半同步複製。

發生意外宕機

從寫入binglog到通知Dump線程階段若是發生意外宕機就會形成主庫和從庫數據不一致。

這種不一致只是在master完成了，可是沒來得及複製slave的數據庫操做。這些操做在業務看來是執行失敗的數據庫操做。可是在主庫宕機恢復後，這些數據庫操做會被recovery機制做爲成功的數據庫操做來處理，同時binglog是存在的，可是並無複製到slave。

若是發生了業務切換，繼續在slave執行數據庫操做，那麼在一些特性的場景下，若是master立即回覆，可能形成複製失敗的狀況。

非auto_position的Master.info

Master.info記錄的IO線程複製的相關信息，記錄的信息與show slave status顯示的IO線程相關含義相同。用於在MySQL啓動時，裝載複製IO線程的相關信息，保證重啓後複製仍能繼續進行。

對於非auto_position的Master.info在change master時，會記錄主機的IP、端口、用戶名等信息到master.info中，IO線程在記錄relay log後更新master.info中的記錄master的文件和位置。

當意外宕機的時候,可能發生記錄了relay log可是沒有更新master.info的狀況。

非GTID的Relay-log.info

Relay-log.info記錄着SQL線程複製相關信息，記錄的信息與show slave status顯示的SQL線程相關信息含義相同。用於在MySQL啓動時裝載複製的相關信息，保證重啓後複製仍可以繼續進行。

當發生宕機，複製從新啓動後，會存在relay-log.info中記錄的信息要晚於真正執行relay log的狀況。SQL線程啓動時，可能讀取到已經執行過的relay.log。

這是若是開啓了GTID，重複的GTID會被過濾，而沒有開啓，發生重複執行的狀況，可能致使複製錯誤。

重複GTID的忽略

GTID爲全局惟一標示符，與事務一一對應的，master的事務對應的GTID不會由於複製到Slave而發生改變，級master的事務複製到slave，被sql重現後，記入Slave bining中的事務對應的GTID仍然爲master的gtid。

相同的GTID對應的事務不會被重複複製到Slave，slave對於執行過的gtid也不會重複執行。

在重作主從或者誤操做的狀況下，因爲GTID不會重複執行，因此可能會致使master和slave的數據差別。

複製問題的解決方法

退化爲異步複製的解決方案

異步複製階段的宕機問題是主要因素，解決這一問題的主要思路是減小異步複製的存在時間。

能夠採用增長半同步的超時時間，犧牲必定的可用性來保障數據的一致性。也能夠經過增長新複製通道，只記錄文件和位置，而且不退化，只重連，保證複製正常的狀況下一直存在一條半同步複製。增長異步和同步共存的複製方式也是一個方案。

發生意外宕機解決方案

針對這一問題，應該避免進行重複的操做，以及在MySQL-5.6之前的版本使用自增ID。對於recovery機制進行優化，經過配置或者其餘方式鏈接原slave，讀取master宕機時的複製進度。記錄binglog的樹屋，若是沒有同步到Slave，仍然事務回滾，回滾後對binglog作truncate處理，另外還需對刪除的binglog作日誌記錄。

Master.info和Relay_log.log

這裏主要是解決宕機恢復後複製起點問題。建議儘可能使用GTID做爲複製的依據，取代較早的文件和位置，slave宕機恢復後，對relay log、binglog和當前複製的進度作較完善的校檢。

重複GTID的忽略

這方面大可能是人爲形成的。因此建議在重作主從後，作完整的複製進度檢查，增長簡單的審計表，對敏感的操做作記錄，如reset master、change master等，並對比master和slave的敏感操做記錄。