日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

RELATEED CONSULTING
相關咨詢
選擇下列產(chǎn)品馬上在線溝通
服務時間:8:30-17:00
你可能遇到了下面的問題
關閉右側工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
值得關注的MySQL高可用方案

隨著MySQL官方的不斷發(fā)力,在基于MySQL復制的基礎上,推出了一系列的高可用方案,例如,主從半同步復制、InnoDB ReplicaSet、組復制(MGR)、InnoDB Cluster,及目前最新的InnoDB ClusterSet。

在這一篇文章里,將向各位讀者介紹各種方案的優(yōu)缺點,及適用場景。在介紹各種方案之前,讀者首先必須了解MySQL復制功能,MySQL的高可用方案幾乎全部是基于MySQL復制實現(xiàn)的。

MySQL的復制功能(之前叫做Master Slave replication,現(xiàn)在改為 Source Replica replication)。MySQL能夠產(chǎn)生一個二進制日志(binlog),當MySQL開啟該功能后,能夠將MySQL服務器所產(chǎn)生的全部事件記錄在日志內。MySQL的復制功能將binlog傳遞到另外一臺服務器(可以將其稱之為從服務器,Slave或者Replica,發(fā)送binlog的服務器稱之為主服務器),從服務器接受到binlog后,將日志記錄的事件進行應用,以此達到兩臺服務器數(shù)據(jù)一致的目的,因此,實現(xiàn)了復制。主從復制的原理如下圖所示:

方案一——MMM

MMM(Multi-Master Replication Manager)是一組靈活的腳本,用于執(zhí)行 MySQL 主-主復制配置的監(jiān)視/故障轉移和管理(任何時候只有一個節(jié)點可寫)。

MMM多用于以下2種場景:

兩個節(jié)點:

在兩個節(jié)點的主-主設置中,MMM使用了五個IP,每個節(jié)點只有一個永久IP,2個讀取IP(只讀)和1個寫入IP(更新)。后面三個IP根據(jù)節(jié)點可用性在節(jié)點之間切換。

正常情況下(沒有復制失敗,沒有復制延遲等)主服務器有2個IP(讀取和寫入),備用服務器- 1個IP(讀取)。在發(fā)生故障時,- 寫入和讀取角色都會遷移到工作節(jié)點。

兩個主服務器,一個或多個從服務器:

在這個場景中,寫入IP只能在兩臺主服務器之間進行切換,讀取IP可以在主從之間切換。通過MMM方案用戶能實現(xiàn)服務器的故障轉移,從而實現(xiàn)MySQL的高可用。

MMM的主要功能由三個腳本提供: mmm_mond 負責監(jiān)控工作的守護進程,決定是否將節(jié)點進行移除(mmm_mond進行心跳檢測,如果檢測到失敗,則將寫入IP切換到另外一臺主服務器) mmm_agentd 是運行在mysql服務器上的代理守護進程,mmm_control 通過命令行管理mmm_mond進程。

優(yōu)點:高可用性,擴展性好,出現(xiàn)故障自動切換,對于主主同步,在同一時間只提供一臺數(shù)據(jù)庫寫操作,保證數(shù)據(jù)的一致性。當主服務器發(fā)生故障后,另一個主服務器立即接管,其他的從服務器能自動切換,不用人工干預。 

缺點:監(jiān)控節(jié)點會發(fā)生單點故障。并且對主機的數(shù)量有要求,至少三個節(jié)點。如果需要實現(xiàn)讀寫分離,還需要在前端編寫讀寫分離程序。在讀寫非常繁忙的業(yè)務系統(tǒng)下表現(xiàn)不是很 穩(wěn)定,可能會出現(xiàn)復制延時、切換失效等問題。MMM方案并不太適應于對數(shù)據(jù)安全性要求很高,并且讀、寫繁忙的環(huán)境中。

方案二——MHA

MHA(Master High Availability)由原MySQL團隊(Sun時代)的Yoshinori Matsunobu開發(fā)??梢詫崿F(xiàn)故障切換和主從提升功能。在 MySQL 故障切換過程中,MHA 能做到在 0~30 秒之內自動完成數(shù)據(jù)庫的故障切換操作,并且在進行故障切換的過程中,MHA 能在最大程度上保證數(shù)據(jù)的一致性,以達到真正意義上的高可用。

MHA由兩部分組成:MHA Manager(管理節(jié)點)和 MHA Node(數(shù)據(jù)節(jié)點)。管理節(jié)點可以單獨部署在一臺獨立的服務器上管理多個主從集群,也可以部署在一臺 從服務器上。數(shù)據(jù)節(jié)點運行在每臺 MySQL 服務器上。管理節(jié)點會定時探測集群中的 主服務器,當 主服務器出現(xiàn)故障時,它可以自動將具有最新數(shù)據(jù)的從服務器提升為新的主服務器,然后將所有其他的從服務器重新指向新的主服務器。整個故障轉移過程對應用程序完全透明。

MHA的優(yōu)勢在于可以非??焖俚赝瓿晒收限D移及提升從服務器角色、主服務崩潰時不會導致數(shù)據(jù)不一致、用戶無需修改當前 MySQL 設置、不會產(chǎn)生性能損失,并且適用于任何存儲引擎。

MHA曾經(jīng)非常流行,但隨著MySQL官方的高可用方案不斷推出,作者已經(jīng)意識到,曾經(jīng)MHA所解決的問題,已經(jīng)逐漸被官方的解決方案所代替,因此,從MySQL8.0開始,作者已經(jīng)不在對MHA進行開發(fā)和維護。

加入一條華麗麗的分割線

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主從復制功能,例如,讀取橫向擴展和數(shù)據(jù)安全性。

MySQL InnoDB ReplicaSet基于異步的主從復制實現(xiàn),因此適用于用戶對高可用性要求不高的環(huán)境,用戶可以通過MySQL Shell快速搭建及管理主從復制,避免了搭建主從復制時,大量的手動操作。 InnoDB ReplicaSet的架構如下圖所示:

方案四——組復制

組復制是一個MySQL服務器插件,可以創(chuàng)建具有彈性、高可用性和容錯的復制拓撲。組復制基于“Paxos”協(xié)議(“Mencius”)實現(xiàn),支持多點寫入,具有沖突檢測和解決機制,它允許應用程序寫入的數(shù)據(jù)在同一組內的所有服務器上保持一致。組復制內置的模塊支持跨平臺的分布式恢復,并通過內置的故障轉移機制實現(xiàn)了容錯。組復制插件的架構如下圖所示:

組復制允許用戶從現(xiàn)有的主從復制升級到組復制,可以確保一個高可用的MySQL服務分布在多個實例中,無需人工干預來實現(xiàn)容錯。

組復制能夠確保數(shù)據(jù)庫服務連續(xù)可用,但沒有提供內置方法進行故障轉移或負載均衡。為了實現(xiàn)自動化的故障轉移和負載均衡,用戶可以使用中間件來實現(xiàn)。

方案五——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與其他位置(例如,不同數(shù)據(jù)中心)的一個或多個副本鏈接,為 InnoDB Cluster 部署提供容災能力。InnoDB ClusterSet 使用專門的ClusterSet 復制通道,自動管理從主要集群到副本集群的復制。如果主要集群因數(shù)據(jù)中心損毀或網(wǎng)絡連接丟失變得無法使用,用戶可以激活副本集群以恢復服務的可用性。InnoDB ClusterSet的整體架構如下圖所示:

InnoDB ClusterSet優(yōu)先考慮可用性而不是一致性,以最大限度地提高系統(tǒng)的容災能力。正常的復制延遲或網(wǎng)絡分區(qū)可能意味著在主要集群遇到問題時,部分或全部副本集群與主要集群不完全一致。在這些場景中,如果觸發(fā)緊急故障轉移,任何未復制或發(fā)送的事務都有丟失的風險,并且只能由用戶進行手動恢復和協(xié)調,無法保證在發(fā)生緊急故障轉移時會保留數(shù)據(jù)。

如果用戶無法容忍故障轉移期間事務或數(shù)據(jù)丟失,則不能使用InnoDB ClusterSet作為系統(tǒng)的解決方案,可以考慮使用一個InnoDB Cluster以及跨多個數(shù)據(jù)中心部署的成員服務器。


分享文章:值得關注的MySQL高可用方案
URL鏈接:http://m.5511xx.com/article/dheispj.html