小編的世界優質文選資料

MySQL高可套件：選擇這麼多，該如何選？

字體大小：
2021年8月26日 -
：

碼農老K工具主管,科技領域創作者前面，我們了解了MySQL數據庫的高可用解決方案，並且學習了怎麼根據金融業務的需求，通過無損半同步複制的方式進行三園區的同城容災設計，以及三地五中心的跨城容災設計。 但是當數據庫發生宕機時，MySQL的主從複制並不會自動的切換，這需要高可用套件對數據庫主從進行管理。 高可用套件MySQL的高可用套件用於負責數據庫的Failover操作，也就是當數據庫發生宕機時，MySQL可以剔除原有主機，選出新的主機，然後對外提供服務，保證業務的連續性。 MySQL複制時高可用的技術基礎，用於將數據實時同步到從機。 高可用套件是MySQL高可用實現的解決方案，複制切換新主機。 為了不讓業務感知到數據庫的宕機切換，這裏需要用到VIP(Virtual IP)技術。 其中， VIP不是真實的物理IP，而是可以隨意綁定在任何一台服務器上。 業務訪問數據庫，不是服務器上與網卡綁定的物理IP，而是這台服務器上的VIP。 當數據庫服務器發生宕機時，高可用套件會把VIP插拔到新的服務器上。 數據庫Failover後，業務一九訪問的還是VIP，所以所用VIP可以做到對業務透明。 下面這圖顯示了業務通過VIP進行數據庫的訪問。 通過VIP進行訪問MySQL的主服務器的IP地址為192.168.1.10，兩個從服務器的地址分別為192.168.1.20和192.168.1.30。 上層服務訪問數據庫並沒有直接通過物理IP192.168.1.10，而是訪問VIP 192.168.1.100，這時，如果MySQL主服務器發生宕機，會進行如下處理：VIP遷移發生故障遷移後，由於上層服務器訪問的仍然是VIP 192.168.1.100，所以切換對服務來說是透明的，只是在切換工程中，服務會收到連接數據庫失敗的提示。 但是通過重試機制，當下層數據庫完成切換後，服務就可以繼續使用了。 所以，上層服務一定要做好錯誤重試的邏輯，否則就算啟用了VIP，也無法實現透明的切換。 VIP的局限性，僅限於同機房同網段的IP設定。 如果是我們之前設計的三園區同城跨機房容災架構，VIP就不可用了。 這時就要用名字服務，常見的名字服務就是DNS（Domain Name Service），如下圖所示：通過DNS解析域名從上圖可以看到，這裏將域名m1.xxx.comd對應的IP指向為192.168.1.10，上層業務通過域名進行訪問。 當發生宕機，進行機房級切換後，結果變為：DNS遷移當發生Failover後，高可用套件會把域名指向為新的MySQL主服務器，IP地址為202.177.54.20，這樣也實現了對於上層服務的透明性。 雖然使用域名或其他名字服務可以解決跨機房的切換問題，但引入了新的組件。 新組件的高可用問題也需要特別注意。 在架構設計時，請咨詢公司提供名字服務的小組，和他們一起設計高可用的容災架構。 MySQL常見高可用套件MHA（Master High Availibility）MHA是一款開源的MySQL高可用程序，它為MySQL數據庫主從複制提供了自動主機故障遷移的功能。 MHA由兩大組件組成。 MHA Manager通常部署在一台服務器上，用來判斷多個MySQL高可用組是否可用。 當發現有主服務器發生宕機，就發起Failover操作。 MHA Manager可以看作是Failover的總控服務器。 MHA Node部署在每台MySQL服務器上，MHA Manager通過執行Node節點的腳本完成failover切換操作。 MHA Manager和MHA Node通過SSH的方式進行通信，也就是需要在生產環境中打通MHA Manager到所有MySQL節點的ssh策略，那麼這裏就存在潛在的安全風險。 另外，ssh通信，效率並不是很高。 所以，MHA比較適合用於規模不是特別大的公司，所有MySQL數據庫的服務器數量不操作20台。 MHA.pngOrchestratorOrchestrator也是一款開源的MySQL高可用套件，處理支持failover，還可以完成MySQL數據庫的一些簡單的複制管理操作。 提供了HTTP接口來進行相關數據庫的操作。 Orchestrator.png其實現原理與MHA是一樣的，只是把元數據信息存儲到元數據庫中，並且提供了HTTP接口和命令的訪問方式，使用上更為友好。 但是由於管控節點到下面的MySQL數據庫的管理依然是ssh的方式，依然存在MHA一樣的短板問題，總的來說，關於Orchestrator，依然只建議使用在較小規模的數據庫集群。 數據庫管理平台當然了，雖然MHA和Orchestrator都可以完成MySQL高可用的failover操作，但是，在生產環境中如果需要管理成千乃至上萬的數據庫服務器，由於它們的通信采用ssh的方式，並不能滿足生產上的安全性和性能的要求。 所以，幾乎每家互聯網公司都會自研一個數據庫的管理平台，用於管理公司所有的數據庫集群，以及數據的容災切換工作。 接下來，就帶你了解數據庫管理平台的架構。 dms.png上圖中的數據庫管理平台是用戶操作數據庫的入口。 對數據庫的大部分操作，比如數據庫的初始化、數據查詢、數據備份等操作、後續都能在這個平台完成，不用登錄數據庫服務器，這樣的好處是能大大提升數據庫操作的效率。 數據庫管理平台提供HTTP API的方式，可以前後端分離的方式支持Web、手機等多種訪問方式。 元數據庫用於存儲管理MySQL數據庫所有的節點信息，比如IP地址、端口、域名等。 數據庫管理平台Manager用來實際控制下面的所有MySQL節點，Manager和後端MySQL的通信通過MySQL服務器上部署的agent方式進行。 兩者通過BP協議以grpc的方式通信。 這樣解決了ssh的不安全性和性能問題。 其中，agent用來上報數據庫各節點的狀態給Manager，管理節點Manager通過上報的信息判斷數據庫是否宕機，是否需要進行切換，切換到哪個節點。 上圖的設計，能完成一個比較基本的數據管理平台。 另外，每個公司有自己的一些需求，也可以做到數據庫管理平台中，比如安全要求、審計需求、工單系統等。 所以，有了數據庫管理平台，數據庫的高可用切換、數據庫日常管理和訪問，都可以由平台自動完成。 有了數據庫管理平台，才能真實實現數據庫管理的無人駕駛。 總結MySQL複制技術本身不能實現failover的功能。 所以需要借助MySQL的高可用套件。 采用VIP和名字服務機制，可以實現下層故障遷移的透明性，VIP僅用於同機房同網段，名字服務可用於跨機房的切換。 MHA和Orchestrator都是MySQL的高可用套件，可以完成failover的工作。 但是由於管理節點與MySQL通信采用ssh協議，所以安全性不高，性能一般。 一般建議用在不操作20台數據庫節點的環境中。 對於要管理MySQL數量比較多的場景，推薦自研數據庫平台，這樣能結合自家公司的特性，設計出MySQL數據庫的自動管理平台，這樣才能解放DBA的生產力，投入業務的優化工作中。 
第頁完，請繼續朗讀下一頁。喜歡 小編的世界，請記得按讚、收藏及分享

碼農老K

工具主管,科技領域創作者

前面，我們了解了MySQL數據庫的高可用解決方案，並且學習了怎麼根據金融業務的需求，通過無損半同步複制的方式進行三園區的同城容災設計，以及三地五中心的跨城容災設計。

但是當數據庫發生宕機時，MySQL的主從複制並不會自動的切換，這需要高可用套件對數據庫主從進行管理。

高可用套件

MySQL的高可用套件用於負責數據庫的Failover操作，也就是當數據庫發生宕機時，MySQL可以剔除原有主機，選出新的主機，然後對外提供服務，保證業務的連續性。

MySQL複制時高可用的技術基礎，用於將數據實時同步到從機。高可用套件是MySQL高可用實現的解決方案，複制切換新主機。

為了不讓業務感知到數據庫的宕機切換，這裏需要用到VIP(Virtual IP)技術。其中， VIP不是真實的物理IP，而是可以隨意綁定在任何一台服務器上。

業務訪問數據庫，不是服務器上與網卡綁定的物理IP，而是這台服務器上的VIP。當數據庫服務器發生宕機時，高可用套件會把VIP插拔到新的服務器上。數據庫Failover後，業務一九訪問的還是VIP，所以所用VIP可以做到對業務透明。

下面這圖顯示了業務通過VIP進行數據庫的訪問。

通過VIP進行訪問

MySQL的主服務器的IP地址為192.168.1.10，兩個從服務器的地址分別為192.168.1.20和192.168.1.30。上層服務訪問數據庫並沒有直接通過物理IP192.168.1.10，而是訪問VIP 192.168.1.100，這時，如果MySQL主服務器發生宕機，會進行如下處理：

VIP遷移

發生故障遷移後，由於上層服務器訪問的仍然是VIP 192.168.1.100，所以切換對服務來說是透明的，只是在切換工程中，服務會收到連接數據庫失敗的提示。但是通過重試機制，當下層數據庫完成切換後，服務就可以繼續使用了。所以，上層服務一定要做好錯誤重試的邏輯，否則就算啟用了VIP，也無法實現透明的切換。

VIP的局限性，僅限於同機房同網段的IP設定。如果是我們之前設計的三園區同城跨機房容災架構，VIP就不可用了。這時就要用名字服務，常見的名字服務就是DNS（Domain Name Service），如下圖所示：

通過DNS解析域名

從上圖可以看到，這裏將域名m1.xxx.comd對應的IP指向為192.168.1.10，上層業務通過域名進行訪問。當發生宕機，進行機房級切換後，結果變為：

DNS遷移

當發生Failover後，高可用套件會把域名指向為新的MySQL主服務器，IP地址為202.177.54.20，這樣也實現了對於上層服務的透明性。

雖然使用域名或其他名字服務可以解決跨機房的切換問題，但引入了新的組件。新組件的高可用問題也需要特別注意。在架構設計時，請咨詢公司提供名字服務的小組，和他們一起設計高可用的容災架構。

MySQL常見高可用套件

MHA（Master High Availibility）

MHA是一款開源的MySQL高可用程序，它為MySQL數據庫主從複制提供了自動主機故障遷移的功能。MHA由兩大組件組成。

MHA Manager通常部署在一台服務器上，用來判斷多個MySQL高可用組是否可用。當發現有主服務器發生宕機，就發起Failover操作。MHA Manager可以看作是Failover的總控服務器。MHA Node部署在每台MySQL服務器上，MHA Manager通過執行Node節點的腳本完成failover切換操作。

MHA Manager和MHA Node通過SSH的方式進行通信，也就是需要在生產環境中打通MHA Manager到所有MySQL節點的ssh策略，那麼這裏就存在潛在的安全風險。

另外，ssh通信，效率並不是很高。所以，MHA比較適合用於規模不是特別大的公司，所有MySQL數據庫的服務器數量不操作20台。

MHA.png

Orchestrator

Orchestrator也是一款開源的MySQL高可用套件，處理支持failover，還可以完成MySQL數據庫的一些簡單的複制管理操作。提供了HTTP接口來進行相關數據庫的操作。

Orchestrator.png

其實現原理與MHA是一樣的，只是把元數據信息存儲到元數據庫中，並且提供了HTTP接口和命令的訪問方式，使用上更為友好。但是由於管控節點到下面的MySQL數據庫的管理依然是ssh的方式，依然存在MHA一樣的短板問題，總的來說，關於Orchestrator，依然只建議使用在較小規模的數據庫集群。

數據庫管理平台

當然了，雖然MHA和Orchestrator都可以完成MySQL高可用的failover操作，但是，在生產環境中如果需要管理成千乃至上萬的數據庫服務器，由於它們的通信采用ssh的方式，並不能滿足生產上的安全性和性能的要求。

所以，幾乎每家互聯網公司都會自研一個數據庫的管理平台，用於管理公司所有的數據庫集群，以及數據的容災切換工作。

接下來，就帶你了解數據庫管理平台的架構。

dms.png

上圖中的數據庫管理平台是用戶操作數據庫的入口。對數據庫的大部分操作，比如數據庫的初始化、數據查詢、數據備份等操作、後續都能在這個平台完成，不用登錄數據庫服務器，這樣的好處是能大大提升數據庫操作的效率。

數據庫管理平台提供HTTP API的方式，可以前後端分離的方式支持Web、手機等多種訪問方式。

元數據庫用於存儲管理MySQL數據庫所有的節點信息，比如IP地址、端口、域名等。

數據庫管理平台Manager用來實際控制下面的所有MySQL節點，Manager和後端MySQL的通信通過MySQL服務器上部署的agent方式進行。兩者通過BP協議以grpc的方式通信。這樣解決了ssh的不安全性和性能問題。

其中，agent用來上報數據庫各節點的狀態給Manager，管理節點Manager通過上報的信息判斷數據庫是否宕機，是否需要進行切換，切換到哪個節點。

上圖的設計，能完成一個比較基本的數據管理平台。另外，每個公司有自己的一些需求，也可以做到數據庫管理平台中，比如安全要求、審計需求、工單系統等。

所以，有了數據庫管理平台，數據庫的高可用切換、數據庫日常管理和訪問，都可以由平台自動完成。有了數據庫管理平台，才能真實實現數據庫管理的無人駕駛。

總結

MySQL複制技術本身不能實現failover的功能。所以需要借助MySQL的高可用套件。采用VIP和名字服務機制，可以實現下層故障遷移的透明性，VIP僅用於同機房同網段，名字服務可用於跨機房的切換。MHA和Orchestrator都是MySQL的高可用套件，可以完成failover的工作。但是由於管理節點與MySQL通信采用ssh協議，所以安全性不高，性能一般。一般建議用在不操作20台數據庫節點的環境中。對於要管理MySQL數量比較多的場景，推薦自研數據庫平台，這樣能結合自家公司的特性，設計出MySQL數據庫的自動管理平台，這樣才能解放DBA的生產力，投入業務的優化工作中。