一、MySQL復(fù)制的三種模式

MySQL當(dāng)前存在的三種復(fù)制模式有：異步模式、半同步模式和組復(fù)制模式，先了解一下三種模式的工作方式。

1. MySQL Asynchronous Replication(異步復(fù)制)

異步復(fù)制是MySQL最早的也是當(dāng)前使用最多的復(fù)制模式，異步復(fù)制提供了一種簡(jiǎn)單的主-從復(fù)制方法，包含一個(gè)主庫(master)和備庫(一個(gè)，或者多個(gè))之間，主庫執(zhí)行并提交了事務(wù)，在這之后(因此才稱之為異步)，這些事務(wù)才在從庫上重新執(zhí)行一遍(基于statement)或者變更數(shù)據(jù)內(nèi)容(基于row)，主庫不檢測(cè)其從庫上的同步情況。在服務(wù)器負(fù)載高、服務(wù)壓力大的情況下主從產(chǎn)生延遲一直是其詬病。工作流程簡(jiǎn)圖如下：

2. MySQL Semisynchronous Replication(半同步復(fù)制)

MySQL5.5的版本在一步同步的基礎(chǔ)之上，以插件的形式實(shí)現(xiàn)了一個(gè)變種的同步方案，稱之為半同步(semi-sync replication)。這個(gè)插件在源生的異步復(fù)制上，添加了一個(gè)同步的過程：當(dāng)從庫接收到了主庫的變更(即事務(wù))時(shí)，會(huì)通知主庫。主庫上的操作有兩種：接收到這個(gè)通知以后才去commit事務(wù);接受到之后釋放session。這兩種方式是由主庫上的具體配置決定的。當(dāng)主庫收不到從庫的變更通知超時(shí)時(shí)，由半同步復(fù)制自動(dòng)切換到異步同步，這樣就極大了保證了數(shù)據(jù)的一致性(至少一個(gè)從庫)，但是在性能上有所下降，特別是在網(wǎng)絡(luò)不穩(wěn)定的情況下，半同步和同步之間來回切換，對(duì)正常的業(yè)務(wù)是有影響的。其工作流程簡(jiǎn)圖如下：

3. Group Replication(組復(fù)制)

不論是異步復(fù)制還是半同步復(fù)制，都是一個(gè)主下面一個(gè)從或是多個(gè)從的模式，在高并發(fā)下高負(fù)載下，都存在延遲情況，此時(shí)如果主節(jié)點(diǎn)出現(xiàn)異常，那么就會(huì)出現(xiàn)數(shù)據(jù)不一致的情況，數(shù)據(jù)可能會(huì)丟，在金融級(jí)數(shù)據(jù)庫中是不能容忍的。在這種情況下，急需出現(xiàn)一種模式來解決這些問題。在MySQL5.7.17的版本中，帶著這些期待，新的復(fù)制模式組復(fù)制產(chǎn)生并GA了(本文的測(cè)試等數(shù)據(jù)均基于MySQL5.7.17)。

組復(fù)制的工作流程圖如下：

二、組復(fù)制的工作原理

MySQL組復(fù)制是一個(gè)MySQL插件，它建立在現(xiàn)有的MySQL復(fù)制基礎(chǔ)結(jié)構(gòu)上，利用了二進(jìn)制日志，基于行的日志記錄和全局事務(wù)標(biāo)識(shí)符等功能。它集成了當(dāng)前的MySQL框架，如性能模式、插件和服務(wù)基礎(chǔ)設(shè)施等。

組復(fù)制(Group Replication)基于分布式一致性算法(Paxos協(xié)議的變體)實(shí)現(xiàn)，一個(gè)組允許部分節(jié)點(diǎn)掛掉，只要保證絕大多數(shù)節(jié)點(diǎn)仍然存活并且之間的通訊是沒有問題的，那么這個(gè)組對(duì)外仍然能夠提供服務(wù)，它是一種被使用在容錯(cuò)系統(tǒng)中的技術(shù)。Group Replication(復(fù)制組)是由能夠相互通信的多個(gè)服務(wù)器(節(jié)點(diǎn))組成的。在通信層，Group replication實(shí)現(xiàn)了一系列的機(jī)制：比如原子消息(atomic message delivery)和全序化消息(total ordering of messages)。這些原子化，抽象化的機(jī)制，為實(shí)現(xiàn)更先進(jìn)的數(shù)據(jù)庫復(fù)制方案提供了強(qiáng)有力的支持。MySQL Group Replication正是基于這些技術(shù)和概念，實(shí)現(xiàn)了一種多主全更新的復(fù)制協(xié)議。簡(jiǎn)而言之，一個(gè)Group Replication就是一組節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)都可以獨(dú)立執(zhí)行事務(wù)，而讀寫事務(wù)則會(huì)在于group內(nèi)的其他節(jié)點(diǎn)進(jìn)行協(xié)調(diào)之后再commit。因此，當(dāng)一個(gè)事務(wù)準(zhǔn)備提交時(shí)，會(huì)自動(dòng)在group內(nèi)進(jìn)行原子性的廣播，告知其他節(jié)點(diǎn)變更了什么內(nèi)容/執(zhí)行了什么事務(wù)。這種原子廣播的方式，使得這個(gè)事務(wù)在每一個(gè)節(jié)點(diǎn)上都保持著同樣順序。這意味著每一個(gè)節(jié)點(diǎn)都以同樣的順序，接收到了同樣的事務(wù)日志，所以每一個(gè)節(jié)點(diǎn)以同樣的順序重演了這些事務(wù)日志，最終整個(gè)group保持了完全一致的狀態(tài)。然而，不同的節(jié)點(diǎn)上執(zhí)行的事務(wù)之間有可能存在資源爭(zhēng)用。這種現(xiàn)象容易出現(xiàn)在兩個(gè)不同的并發(fā)事務(wù)上。假設(shè)在不同的節(jié)點(diǎn)上有兩個(gè)并發(fā)事務(wù)，更新了同一行數(shù)據(jù)，那么就會(huì)發(fā)生資源爭(zhēng)用。面對(duì)這種情況，Group Replication判定先提交的事務(wù)為有效事務(wù)，會(huì)在整個(gè)group里面重放，后提交的事務(wù)會(huì)直接中斷，或者回滾，***丟棄掉。因此，這也是一個(gè)無共享的復(fù)制方案，每一個(gè)節(jié)點(diǎn)都保存了完整的數(shù)據(jù)副本。

從其工作的原理可以看出，Group Replication基于Paxos協(xié)議的一致性算法校驗(yàn)事務(wù)執(zhí)行是否有沖突，然后順序執(zhí)行事務(wù)，達(dá)到最終的數(shù)據(jù)一致性，也就意味著部分節(jié)點(diǎn)可以存在延遲?？梢栽O(shè)置多主同時(shí)寫入和單主寫入，通過設(shè)置group_replication_single_primary_mode來進(jìn)行控制是多主還是單主，官方推薦單主寫入，允許延遲，但延遲過大，則會(huì)觸發(fā)限流規(guī)則(可配置的)，整個(gè)集群會(huì)變的很慢，性能大打折扣。

三、組復(fù)制的程序結(jié)構(gòu)

在MySQL的底層，GR增加了另外的API層來實(shí)現(xiàn)所需要的功能。程序結(jié)構(gòu)上，GRAPI主要分為三部分：

1:capture 追蹤當(dāng)前正在執(zhí)行的事務(wù)的上下文。

2:applier 執(zhí)行遠(yuǎn)程事務(wù)傳輸?shù)奖镜氐娜罩镜奖镜財(cái)?shù)據(jù)庫。

3:recovery 負(fù)責(zé)分布式環(huán)境下的節(jié)點(diǎn)恢復(fù)，以及相關(guān)的數(shù)據(jù)回追，失敗處理等。

在這幾個(gè)主要API層的下面，是統(tǒng)一的復(fù)制協(xié)議邏輯處理層，這一層主要是統(tǒng)一應(yīng)用層的各種調(diào)用。在更下層，則是通用程度更高的分布式通訊層，處于調(diào)用便利，分布式通訊曾對(duì)上提供使用的API，API的下面，是Paxos實(shí)現(xiàn)的分布式通訊協(xié)議組件，這個(gè)組件與集群中其他節(jié)點(diǎn)一起，形成一個(gè)虛擬概念化的分布式集群。

四、消息壓縮(Message Compression)

這個(gè)壓縮主要是指MySQL的bin-log壓縮，所使用的壓縮算法是LZ4。當(dāng)網(wǎng)絡(luò)帶寬是瓶頸時(shí)，消息壓縮可以在組通信級(jí)別提供高達(dá)30-40%的吞吐量改進(jìn)，這在網(wǎng)絡(luò)傳輸壓力比較大的組中是尤為重要的。LZ4能很好的支持多線程環(huán)境，獲得更高的壓縮和解壓速度。以下是壓縮算法LZ4的壓縮和解壓情況：

壓縮發(fā)生在組通信引擎級(jí)別，之前數(shù)據(jù)被交給組通信線程，所以它發(fā)生在mysql用戶會(huì)話線程的上下文中。事務(wù)有效網(wǎng)絡(luò)負(fù)載可以在被發(fā)送到組之前被壓縮，并且在被接收時(shí)被解壓縮。壓縮是有條件的，并且取決于配置的閾值。默認(rèn)情況下啟用壓縮，此外，它并不要求組中的所有服務(wù)器節(jié)點(diǎn)都啟用壓縮機(jī)制，在接收到消息時(shí)，成員檢查消息信封以驗(yàn)證它是否被壓縮，如果需要，則成員解壓縮該事務(wù)，然后將其傳遞到上層。

默認(rèn)情況下啟用壓縮，閾值為1000000字節(jié)(1MB)。壓縮閾值(以字節(jié)為單位)可以設(shè)置為大于默認(rèn)值。在這種情況下，只有具有大于閾值的有效負(fù)載的事務(wù)被壓縮。下面是如何設(shè)置壓縮閾值的示例。

STOP GROUP_REPLICATION; 
SET GLOBAL group_replication_compression_threshold= 2097152; 
START GROUP_REPLICATION; 

這將壓縮閾值設(shè)置為2MB。如果事務(wù)生成的有效內(nèi)容大于2MB的復(fù)制消息，例如大于2MB的二進(jìn)制日志事務(wù)條目，則會(huì)對(duì)其進(jìn)行壓縮。禁用壓縮設(shè)置閾值為0。注意：修改這個(gè)閾值是需要重啟組復(fù)制的。

消息壓縮流程圖如下：

五、組復(fù)制的要求和限制

1. 限制和要求

• 所有涉及的數(shù)據(jù)都必須發(fā)生在InnoDB存儲(chǔ)引擎的表內(nèi)。
• 所有的表必須有明確的主鍵定義。
• 網(wǎng)絡(luò)地址只支持IPv4。
• 需要低延遲，高帶寬的網(wǎng)絡(luò)。
• 目前集群限制最多允許9個(gè)節(jié)點(diǎn)。
• 必須啟用binlog。
• binlog 格式必須是row格式。
• 必須打開gtid模式。
• 復(fù)制相關(guān)信息必須使用表存儲(chǔ)。
• 事務(wù)寫集合(Transaction write set extraction)必須打開。(這個(gè)目前與savepoint沖突，這也是導(dǎo)致mysqldump無法備份GR實(shí)例的原因)
• log slave updates必須打開。
• binlog的checksum目前不支持。
• 由于事務(wù)寫集合的干擾，無法使用savepoint。
• SERIALIZABLE 隔離級(jí)別目前不支持。
• 對(duì)同一個(gè)對(duì)象，在集群中不同的實(shí)例上，并行地執(zhí)行DDL(哪怕是相互沖突的DDL)是可行的，但會(huì)導(dǎo)致數(shù)據(jù)一致性等方面的錯(cuò)誤，目前階段不支持在多節(jié)點(diǎn)同時(shí)執(zhí)行同一對(duì)象的DDL。
• 外鍵的級(jí)聯(lián)約束操作目前的實(shí)現(xiàn)并不完全支持，不推薦使用。

2. 組復(fù)制的相關(guān)配置

依據(jù)組復(fù)制的要求和限制，以下設(shè)置根據(jù)MySQL組復(fù)制要求配置復(fù)制：

1 
server_id = 1 
gtid_mode = ON 
enforce_gtid_consistency = ON 
master_info_repository = TABLE 
relay_log_info_repository = TABLE 
binlog_checksum = NONE 
log_slave_updates = ON 
log_bin = binlog 
binlog_format = ROW 

此時(shí)my.cnf文件可確保服務(wù)器配置，并指示實(shí)例化一個(gè)給定的配置下的復(fù)制基礎(chǔ)設(shè)施。以下部分配置服務(wù)器的組復(fù)制設(shè)置。具體參數(shù)比較簡(jiǎn)單，不在這里贅述，可參見官方說明：

transaction_write_set_extraction = XXHASH64 
loose-group_replication_group_name =“aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa” 
loose-group_replication_start_on_boot = off 
loose-group_replication_local_address ="127.0.0.1:24901” 
loose-group_replication_group_seeds =“127.0.0.1:24901,127.0.0.1:24902,127.0.0.1:24903” 
loose-group_replication_bootstrap_group = off 

具體的組復(fù)制安裝部署比較簡(jiǎn)單，網(wǎng)上和官方說明都有說明，在這里就不闡述安裝部署這塊了。

六、組復(fù)制的多主和單主模式(Multi-Primary or Single-Primary Mode)

組復(fù)制分為多主和單主兩種模式，默認(rèn)是單主模式，也是官方推薦的組復(fù)制模式。單個(gè)集群中不能同時(shí)使用兩種模式，例如一個(gè)配置在多主模式，而另一個(gè)在單主模式。要在模式之間切換，需要使用不同的操作配置重新啟動(dòng)集群。無論部署模式如何，組復(fù)制不處理客戶端故障切換，它必須由應(yīng)用程序本身、連接器或中間件框架(如代理或路由器)等處理。

1. 單主模式

在此模式下，組具有設(shè)置為讀寫模式的單主實(shí)例，主節(jié)點(diǎn)通常是用于解析組的***個(gè)服務(wù)器，組中的其他其他節(jié)點(diǎn)都自動(dòng)設(shè)置為只讀模式(即，超級(jí)只讀)，所有其他加入的節(jié)點(diǎn)自動(dòng)識(shí)別主節(jié)點(diǎn)并設(shè)置為自己為只讀。

在單主機(jī)模式下，將禁用在多主機(jī)模式下部署的某些檢查，因?yàn)橄到y(tǒng)會(huì)強(qiáng)制每次只有一個(gè)寫入節(jié)點(diǎn)。例如，允許對(duì)具有級(jí)聯(lián)外鍵的表進(jìn)行更改，而在多主模式下不允許。在主節(jié)點(diǎn)故障時(shí)，自動(dòng)選舉機(jī)制選擇下一個(gè)主節(jié)點(diǎn)。通過按字典順序(使用其UUID)并選擇列表中的***個(gè)節(jié)點(diǎn)來排序剩余的節(jié)點(diǎn)來選擇下一個(gè)主節(jié)點(diǎn)。如果主節(jié)點(diǎn)從組中刪除，則執(zhí)行選擇，并從組中的其余節(jié)點(diǎn)中選擇新的主節(jié)點(diǎn)，這個(gè)選擇按照詞典順序排序節(jié)點(diǎn)UUID并選擇***個(gè)來執(zhí)行。一旦選擇了新的主節(jié)點(diǎn)，其他節(jié)點(diǎn)將設(shè)置為從節(jié)點(diǎn)，從節(jié)點(diǎn)為只讀。如下圖：

2. 多主模式

在多主模式下，沒有單個(gè)主模式的概念，也沒有選舉程序，因?yàn)闆]有節(jié)點(diǎn)發(fā)揮任何特殊的作用。加入組時(shí)，所有服務(wù)器都設(shè)置為讀寫模式。

在多主要模式下部署時(shí)，將檢查語句以確保它們與模式兼容。在以多主模式部署組復(fù)制時(shí)進(jìn)行以下檢查：

1:如果事務(wù)在SERIALIZABLE隔離級(jí)別下執(zhí)行，則在將其與組同步時(shí)，它的提交將失敗。

2:如果事務(wù)對(duì)具有級(jí)聯(lián)約束的外鍵執(zhí)行，則事務(wù)在與組同步時(shí)無法提交。

這些檢查可通過設(shè)置選項(xiàng)停用 group_replication_enforce_update_everywhere_checks 到FALSE。當(dāng)在單主要方式部署，該選項(xiàng)必須設(shè)置為 FALSE。如下圖：

七、運(yùn)維相關(guān)問題

1. 故障切換問題

目前MySQL官方?jīng)]有發(fā)布連接組復(fù)制專用的客戶端(如MongoDB連接復(fù)制集的客戶端)，在實(shí)際的應(yīng)用中如果發(fā)生故障，需要客戶端自己來處理。對(duì)于單主模式的話，如果主節(jié)點(diǎn)發(fā)生故障，客戶端需要判斷新的主節(jié)點(diǎn)是誰，然后把寫切換到新的主節(jié)點(diǎn)，基本上和當(dāng)前的異步同步的主從切換一樣，并且新的主節(jié)點(diǎn)是集群自動(dòng)產(chǎn)生，不可控;多主模式需要在客戶端進(jìn)行節(jié)點(diǎn)可用性檢查，當(dāng)其中的一個(gè)寫節(jié)點(diǎn)不可用時(shí)自動(dòng)使用其他可用節(jié)點(diǎn)。

在實(shí)際生產(chǎn)中，綜合兩種組復(fù)制模式的故障切換，可以使用多主模式，指定其中一個(gè)節(jié)點(diǎn)為主節(jié)點(diǎn)，其他節(jié)點(diǎn)置為只讀節(jié)點(diǎn)，這樣主節(jié)點(diǎn)故障時(shí)，新的主節(jié)點(diǎn)可控。

2. 大事務(wù)支持問題

目前版本測(cè)試并發(fā)進(jìn)行大數(shù)據(jù)操作和DDL操作時(shí)，kill掉大事務(wù)，有幾率造成集群不可用;在insert into …….select……limit……這種大事務(wù)支持不好，可能造成集群不用;多主模式進(jìn)行DDL操作需要集群內(nèi)所有節(jié)點(diǎn)都為ONLINE狀態(tài)才可執(zhí)行，處于ERROR和RECOVERING狀態(tài)時(shí)有幾率導(dǎo)致集群堵塞，嚴(yán)重時(shí)集群不可用。

3. 備份問題

在組復(fù)制集群其中的一個(gè)節(jié)點(diǎn)上執(zhí)行數(shù)據(jù)庫備份時(shí)，不管使用mysqldump(這個(gè)不能使用--single-transaction參數(shù)，生產(chǎn)中不建議使用mysqldump備份集群數(shù)據(jù))或是使用xtrabackup的QPS下降40%，并且備份節(jié)點(diǎn)基本停止讀寫。在測(cè)試備份文件導(dǎo)入數(shù)據(jù)時(shí)，多主模式要比單主模式慢。推薦使用組復(fù)制+異步復(fù)制方式，在異步復(fù)制的從節(jié)點(diǎn)上進(jìn)行數(shù)據(jù)庫備份。

4. 二進(jìn)制日志刪除問題

因?yàn)榻M復(fù)制同步還是基于二進(jìn)制日志來進(jìn)行同步的，清理某個(gè)節(jié)點(diǎn)bin-log時(shí)，必須判定這個(gè)日志文件是否還在使用，如果在使用，則絕對(duì)不能刪除，如果刪除，則整個(gè)集群直接ERROR。

5. 同步延遲問題

目前MySQL5.7.17的版本中無法直觀查看節(jié)點(diǎn)同步延遲，也無法獲取延遲多少，不管是時(shí)間或事物數(shù)，這個(gè)打開MySQL的Debug模式，可以獲取到節(jié)點(diǎn)的延遲事務(wù)情況。

組復(fù)制的延遲對(duì)集群是有影響的，一旦出現(xiàn)延遲(默認(rèn)延遲25000個(gè)事務(wù))，則啟動(dòng)流量控制(Flow Control)，每個(gè)周期性能衰減當(dāng)前的10%,直到集群不可用(但集群節(jié)點(diǎn)狀態(tài)為online)，單個(gè)節(jié)點(diǎn)慢整個(gè)集群全慢。

集群中的每個(gè)節(jié)點(diǎn)都會(huì)驗(yàn)證并應(yīng)用該組提交的事務(wù)，有關(guān)校驗(yàn)和應(yīng)用程序過程的統(tǒng)計(jì)信息對(duì)于了解應(yīng)用程序隊(duì)列如何增長(zhǎng)，已找到多少?zèng)_突，檢查了多少事務(wù)，在哪里提交了哪些事務(wù)等等非常有用。表 performance_schema.replication_group_member_stats 提供與事務(wù)認(rèn)證過程的相關(guān)信息，但沒有延遲信息。相關(guān)字段解釋如下：

6. 數(shù)據(jù)一致性問題

不管是多寫還是單寫，都并非是強(qiáng)一致性，均允許有延遲，他在校驗(yàn)完事務(wù)是否沖突后把當(dāng)前廣播到各個(gè)節(jié)點(diǎn)并確定各個(gè)節(jié)點(diǎn)收到事務(wù)后即進(jìn)入下一個(gè)事物的沖突檢測(cè)，此時(shí)每個(gè)節(jié)點(diǎn)只是拿到了所有事務(wù)的執(zhí)行序列，保證了事務(wù)最終順序執(zhí)行，從而保證數(shù)據(jù)的最終一致性，但同一時(shí)刻并非強(qiáng)一致性的。

7. 節(jié)點(diǎn)故障腦裂問題

節(jié)點(diǎn)越多性能損耗越大，三個(gè)節(jié)點(diǎn)比較合適。節(jié)點(diǎn)故障可能有腦裂等問題：如5個(gè)節(jié)點(diǎn)分布在兩個(gè)機(jī)房，機(jī)房間網(wǎng)絡(luò)斷掉分為兩個(gè)部分，2個(gè)集群的機(jī)房不可用，3個(gè)節(jié)點(diǎn)的可用，而三個(gè)節(jié)點(diǎn)的機(jī)房網(wǎng)絡(luò)有問題，此時(shí)如果想使兩個(gè)節(jié)點(diǎn)的機(jī)房可用，需要重新對(duì)兩個(gè)節(jié)點(diǎn)做集群重組，三個(gè)節(jié)點(diǎn)的就無法恢復(fù)到兩個(gè)節(jié)點(diǎn)中去;三節(jié)點(diǎn)中其中一個(gè)節(jié)點(diǎn)宕機(jī)，其他兩個(gè)正常節(jié)點(diǎn)可用，故障節(jié)點(diǎn)重啟沒有加入到集群時(shí)，此時(shí)這個(gè)節(jié)點(diǎn)以單實(shí)例存在可讀寫，此時(shí)會(huì)發(fā)生腦裂。

8. 網(wǎng)絡(luò)延遲問題

測(cè)試過程中使用TC命令來模擬網(wǎng)絡(luò)延遲：

tc qdisc add dev eth0 root netem delay 50ms 10ms 增加網(wǎng)絡(luò)延遲50ms，10ms左右的浮動(dòng)

tc qdisc del dev eth0 root netem delay 50ms 10ms 刪除網(wǎng)絡(luò)延遲

經(jīng)過測(cè)試網(wǎng)絡(luò)延遲對(duì)比組復(fù)制MySQL的QPS：網(wǎng)絡(luò)延遲設(shè)置50ms和正常的對(duì)比，QPS降低至少1/3，甚至1/2，網(wǎng)絡(luò)延遲對(duì)性能影響挺大。以下是測(cè)試情況：

9. 彈性擴(kuò)展問題

MySQL官方網(wǎng)站提到了組復(fù)制的彈性自動(dòng)擴(kuò)展，經(jīng)過實(shí)際測(cè)試，這種擴(kuò)展在生產(chǎn)中是不現(xiàn)實(shí)的。可用于生產(chǎn)的彈性擴(kuò)展要求新加入一個(gè)集群，集群中的數(shù)據(jù)完全由集群來完成自動(dòng)同步，但由于組復(fù)制是基于二進(jìn)制日志來進(jìn)行同步的，生產(chǎn)中是不可能完整保留全部的二進(jìn)制日志，在新加入的節(jié)點(diǎn)需要先備份出集群的全量數(shù)據(jù)，然后根據(jù)同步位置去追事務(wù)達(dá)到數(shù)據(jù)的一致后節(jié)點(diǎn)狀態(tài)online狀態(tài)，其實(shí)和之前異步同步搭建主從一樣。并且官方提示如果恢復(fù)時(shí)的延遲過大，可能也無法正常達(dá)到追到***數(shù)據(jù)的位置。

10. 客戶端連接問題

官方說明中關(guān)于故障處理的時(shí)候有一句話：組復(fù)制不處理客戶端故障切換，它必須由應(yīng)用程序本身，連接器或中間件框架(如代理或路由器)處理。官方一再強(qiáng)調(diào)MySQL組復(fù)制提供了高可用、高彈性、可靠的MySQL服務(wù)，那么官方是否提供一套類似MongoDB復(fù)制集的客戶端組件來支持那?

目前的解決方法就是和異步復(fù)制的切換差不多，使用域名切換或是自己實(shí)現(xiàn)一套高可用的客戶端連接方式。但就目前來說效率***的是結(jié)合自己的業(yè)務(wù)，修改組復(fù)制故障處理的源碼，當(dāng)檢測(cè)到寫節(jié)點(diǎn)故障時(shí)結(jié)合自己的域名切換來處理。但這樣對(duì)DBA來說需要源碼開發(fā)能力，相對(duì)要求比較高。

11. 查找主節(jié)點(diǎn)IP問題

在單主模式下，不能直觀的獲取主庫的IP地址，使用以下命令可以獲取到主節(jié)點(diǎn)的UUID：

mysql> SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME ='group_replication_primary_member'; 
+ -------------------------------------- + 
| VARIABLE_VALUE | 
+ -------------------------------------- + 
| 69e1a3b8-8397-11e6-8e67-bf68cbc061a4 | 
+ -------------------------------------- + 
1行（0,00秒） 

使用SELECT * FROM performance_schema.replication_group_members可以查看到UUID對(duì)應(yīng)到的MEMBER_HOST，而MEMBER_HOST指的是主機(jī)名，需要在MySQL的配置文件中指定report-host為IP地址，這樣就可以兩個(gè)表關(guān)聯(lián)查詢到主庫的IP地址。

八、總結(jié)

從測(cè)試的情況來看，對(duì)大事務(wù)等的支持不夠，運(yùn)維管理方面做的不友好，相關(guān)組復(fù)制的配套監(jiān)控、客戶端等不完善，有一部分問題是可以規(guī)避和曲線解決的，有一部分需要源碼層面的支持;在性能上和PXC對(duì)比，要優(yōu)于PXC，這個(gè)和各自的復(fù)制協(xié)議不同分不開的。

MySQL組復(fù)制提供了高可用、高彈性、可靠的MySQL服務(wù)，旨在打造金融級(jí)MySQL集群。在忽略網(wǎng)絡(luò)延遲的情況，可以輕松的實(shí)現(xiàn)多活和異地調(diào)用就近寫庫，這一點(diǎn)是業(yè)務(wù)上比較期待的。組復(fù)制是MySQL未來的一個(gè)發(fā)展趨勢(shì)，相信在未來的版本中會(huì)更加的完善，期待成熟版本。

參考文檔：http://dev.mysql.com/doc/refman/5.7/en/group-replication.html

【本文為51CTO專欄作者“王偉”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】

戳這里，看該作者更多好文