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