值得關注的MySQL高可用方案
隨著MySQL官方的不斷發力，在基于MySQL復制的基礎上，推出了一系列的高可用方案，例如，主從半同步復制、InnoDB ReplicaSet、組復制（MGR）、InnoDB Cluster，及目前最新的InnoDB ClusterSet。
在這一篇文章里，將向各位讀者介紹各種方案的優缺點，及適用場景。在介紹各種方案之前，讀者首先必須了解MySQL復制功能，MySQL的高可用方案幾乎全部是基于MySQL復制實現的。
MySQL的復制功能（之前叫做Master Slave replication，現在改為 Source Replica replication）。MySQL能夠產生一個二進制日志（binlog），當MySQL開啟該功能后，能夠將MySQL服務器所產生的全部事件記錄在日志內。MySQL的復制功能將binlog傳遞到另外一臺服務器（可以將其稱之為從服務器，Slave或者Replica，發送binlog的服務器稱之為主服務器），從服務器接受到binlog后，將日志記錄的事件進行應用，以此達到兩臺服務器數據一致的目的，因此，實現了復制。主從復制的原理如下圖所示：
方案一——MMM
MMM(Multi-Master Replication Manager)是一組靈活的腳本，用于執行 MySQL 主-主復制配置的監視/故障轉移和管理（任何時候只有一個節點可寫）。
MMM多用于以下2種場景：
兩個節點：
在兩個節點的主-主設置中，MMM使用了五個IP，每個節點只有一個永久IP，2個讀取IP(只讀)和1個寫入IP(更新)。后面三個IP根據節點可用性在節點之間切換。
正常情況下(沒有復制失敗，沒有復制延遲等)主服務器有2個IP(讀取和寫入)，備用服務器- 1個IP(讀取)。在發生故障時，- 寫入和讀取角色都會遷移到工作節點。
兩個主服務器，一個或多個從服務器：
在這個場景中，寫入IP只能在兩臺主服務器之間進行切換，讀取IP可以在主從之間切換。通過MMM方案用戶能實現服務器的故障轉移，從而實現MySQL的高可用。
MMM的主要功能由三個腳本提供: mmm_mond 負責監控工作的守護進程，決定是否將節點進行移除(mmm_mond進行心跳檢測，如果檢測到失敗，則將寫入IP切換到另外一臺主服務器) mmm_agentd 是運行在mysql服務器上的代理守護進程，mmm_control 通過命令行管理mmm_mond進程。
優點：高可用性，擴展性好，出現故障自動切換，對于主主同步，在同一時間只提供一臺數據庫寫操作，保證數據的一致性。當主服務器發生故障后，另一個主服務器立即接管，其他的從服務器能自動切換，不用人工干預。
缺點：監控節點會發生單點故障。并且對主機的數量有要求，至少三個節點。如果需要實現讀寫分離,還需要在前端編寫讀寫分離程序。在讀寫非常繁忙的業務系統下表現不是很 穩定，可能會出現復制延時、切換失效等問題。MMM方案并不太適應于對數據安全性要求很高，并且讀、寫繁忙的環境中。
方案二——MHA
MHA（Master High Availability）由原MySQL團隊（Sun時代）的Yoshinori Matsunobu開發。可以實現故障切換和主從提升功能。在 MySQL 故障切換過程中，MHA 能做到在 0~30 秒之內自動完成數據庫的故障切換操作，并且在進行故障切換的過程中，MHA 能在最大程度上保證數據的一致性，以達到真正意義上的高可用。
MHA由兩部分組成：MHA Manager（管理節點）和 MHA Node（數據節點）。管理節點可以單獨部署在一臺獨立的服務器上管理多個主從集群，也可以部署在一臺 從服務器上。數據節點運行在每臺 MySQL 服務器上。管理節點會定時探測集群中的 主服務器，當 主服務器出現故障時，它可以自動將具有最新數據的從服務器提升為新的主服務器，然后將所有其他的從服務器重新指向新的主服務器。整個故障轉移過程對應用程序完全透明。
MHA的優勢在于可以非常快速地完成故障轉移及提升從服務器角色、主服務崩潰時不會導致數據不一致、用戶無需修改當前 MySQL 設置、不會產生性能損失，并且適用于任何存儲引擎。
MHA曾經非常流行，但隨著MySQL官方的高可用方案不斷推出，作者已經意識到，曾經MHA所解決的問題，已經逐漸被官方的解決方案所代替，因此，從MySQL8.0開始，作者已經不在對MHA進行開發和維護。
加入一條華麗麗的分割線
mysqlmysqlmysqlmysqlmysqlmysqlmysqlmysqlmysqlmysqlmysqlmysqlmysqlmysqlmysqlmysqlmysqlmysqlmysqlmysql以下介紹的方案均為來自MySQL團隊的方案，包括，InnoDB ReplicaSet、組復制（MySQL Group Replication MGR）、InnoDB Cluster，及InnoDB ClusterSet。
方案三——MySQL InnoDB ReplicaSet
MySQL InnoDB ReplicaSet整合了MySQL相關技術，用戶能夠通過MySQL Shell部署和管理 MySQL主從復制。InnoDB ReplicaSet至少由兩臺MySQL服務器實例組成，并提供用戶熟知的MySQL主從復制功能，例如，讀取橫向擴展和數據安全性。
MySQL InnoDB ReplicaSet基于異步的主從復制實現，因此適用于用戶對高可用性要求不高的環境，用戶可以通過MySQL Shell快速搭建及管理主從復制，避免了搭建主從復制時，大量的手動操作。 InnoDB ReplicaSet的架構如下圖所示：
方案四——組復制
組復制是一個MySQL服務器插件，可以創建具有彈性、高可用性和容錯的復制拓撲。組復制基于“Paxos”協議（“Mencius”）實現，支持多點寫入，具有沖突檢測和解決機制，它允許應用程序寫入的數據在同一組內的所有服務器上保持一致。組復制內置的模塊支持跨平臺的分布式恢復，并通過內置的故障轉移機制實現了容錯。組復制插件的架構如下圖所示：
組復制允許用戶從現有的主從復制升級到組復制，可以確保一個高可用的MySQL服務分布在多個實例中，無需人工干預來實現容錯。
組復制能夠確保數據庫服務連續可用，但沒有提供內置方法進行故障轉移或負載均衡。為了實現自動化的故障轉移和負載均衡，用戶可以使用中間件來實現。
方案五——MySQL InnoDB Cluster
MySQL InnoDB Cluster是一套完整部署和管理MySQL的高可用性解決方案，其整合了MySQL的多項技術，以彌補組復制無法提供具有自動化故障轉移功能的中間件，無法自動配置等不足。InnoDB Cluster需要至少三臺MySQL服務器實例組成，并且提供高可用性和擴展功能。
InnoDB Cluster包括如下組件：
- MySQL Shell：MySQL的高級客戶端、管理工具和代碼編輯器。
- MySQL服務器和組復制：使一組MySQL實例能夠提供高可用性。InnoDB Cluster提供了一種替代手動配置，易于使用的編程方式來處理組復制。
- MySQL Router：一種輕量級的中間件，提供負載均衡功能，并可在應用程序和多臺MySQL實例之間提供透明的連接路由。
InnoDB Cluster的整體架構如下圖所示：
方案六——MySQL InnoDB ClusterSet
MySQL InnoDB ClusterSet 通過將主要的InnoDB Cluster與其他位置（例如，不同數據中心）的一個或多個副本鏈接，為 InnoDB Cluster 部署提供容災能力。InnoDB ClusterSet 使用專門的ClusterSet 復制通道，自動管理從主要集群到副本集群的復制。如果主要集群因數據中心損毀或網絡連接丟失變得無法使用，用戶可以激活副本集群以恢復服務的可用性。InnoDB ClusterSet的整體架構如下圖所示：
InnoDB ClusterSet優先考慮可用性而不是一致性，以最大限度地提高系統的容災能力。正常的復制延遲或網絡分區可能意味著在主要集群遇到問題時，部分或全部副本集群與主要集群不完全一致。在這些場景中，如果觸發緊急故障轉移，任何未復制或發送的事務都有丟失的風險，并且只能由用戶進行手動恢復和協調，無法保證在發生緊急故障轉移時會保留數據。
如果用戶無法容忍故障轉移期間事務或數據丟失，則不能使用InnoDB ClusterSet作為系統的解決方案，可以考慮使用一個InnoDB Cluster以及跨多個數據中心部署的成員服務器。
