MySQL的組複製可以配置為單主模型和多主模型兩種工作模式，它們都能保證MySQL的高可用。以下是兩種工作模式的特性簡介：

• 單主模型：從複製組中眾多個MySQL節點中自動選舉一個master節點，只有master節點可以寫，其他節點自動設定為read only。當master節點故障時，會自動選舉一個新的master節點，選舉成功後，它將設定為可寫，其他slave將指向這個新的master。
  
• 多主模型：複製組中的任何一個節點都可以寫，因此沒有master和slave的概念，只要突然故障的節點數量不太多，這個多主模型就能繼續可用。

雖然多主模型的特性很誘人，但缺點是要配置和維護這種模式，必須要深入理解組複製的理論，更重要的是，多主模型限制較多，其一致性、安全性還需要多做測試。

而使用單主模型的組複製就簡單的太多了，唯一需要知道的就是它會自動選舉master節點這個特性，因為它的維護一切都是自動進行的，甚至對於管理人員來說，完全可以不用去了解組複製的理論。

雖然單主模型比多主模型的效能要差，但它沒有資料不一致的危險，加上限制少，配置簡單，基本上沒有額外的學習成本，所以多數情況下都是配置單主模型的組複製，即使是PXC和MariaDB也如此。

1.單主模型組複製的理論基礎

雖說組複製的單主模型很簡單，但有必要了解一點和單主模型有關的理論，儘管不瞭解也沒什麼問題，畢竟一切都是自動的。

如下圖，master節點為s1，其餘為slave節點。

組複製一切正常時，所有的寫操作都路由到s1節點上，所有的讀操作都路由到s2、s3、s4或s5上。當s1節點故障後，組複製自動選舉新的master節點。假如選舉s2為新master成功後，s3、s4和s5將指向s2，寫操作將路由到s2節點上。

至於如何改變客戶端的路由目標，這不是組複製應該考慮的事情，而是客戶端應用程式應該考慮的事情。實際上，更好的方式是使用中介軟體來做資料庫的路由，比如MySQL Router、ProxySQL、amoeba、cobar、mycat。

1.1 如何加入新節點

上面一直說，單主模型是自動選舉主節點的，那麼如何選舉？

首先，在第一個MySQL節點s1啟動時，一般會將其設定為組的引導節點，所謂引導就是在啟動組複製功能時去建立一個複製組。當然，這並非強制要求，也可以設定第二個啟動節點作為組的引導節點。因為組內沒有其他節點，所以這第一個節點會直接選為master節點。

然後，如果有第二個節點要加入組時，新節點需要徵得組的同意，因為目前只有一個節點，所以只需s1節點同意即可。新節點在加入組時，首先會聯絡s1，與s1建立非同步複製

的通道，並從s1節點處獲取s2上目前缺失的資料，等到s1和s2節點上的資料同步後，s2節點就會真正成為組中的新成員。當然，實際過程要比這裡複雜一些，本文不會過多討論。

如果還有新節點(比如s3節點)繼續加入組，s3將從s1或s2中選一個，並與之建立非同步複製的通道，然後獲取缺失的資料，同步結束後，如果s1和s2都同意s3加入，那麼s3將會組中的新成員。其餘節點加入組也依次類推。

有兩點需要注意：

1. 新節點加入組時，如何選擇聯絡物件？

   上面說加入第二個節點s2時會聯絡s1，加入s3時會聯絡s1、s2中的任意一個。實際上，新節點加入組時聯絡的物件，稱為donor，意為資料供應者。新節點會和選中的donor建立非同步複製通道，並從donor處獲取缺失的資料。

   在配置組複製時，需要指定種子節點列表。當新節點加入組時，只會聯絡種子節點，也即是說，只有種子節點列表中的節點才有機會成為donor，沒有在種子節點列表中的節點不會被新節點選中。但建議，將組中所有節點都加入到種子列表中。

   當聯絡第一個donor失敗後，會向後聯絡第二個donor，再失敗將聯絡第三個donor，如果所有種子節點都聯絡失敗，在等待一段時間後再次從頭開始聯絡第一個donor。依此類推，直到加組失敗報錯。

2. 新節點加入組時，需要徵得哪些節點的同意？

   實際上，新節點加組涉及到組的決策：是否允許它加組。在組複製中，所有的決策都需要組中大多數節點達成一致，也即是達到法定票數。所謂大多數節點，指的是N/2+1(N是組中目前節點總數)，例如目前組中有5個節點，則需要3個節點才能達到大多數的要求。

1.2 如何選舉新的master

當主節點s1故障後，組複製的故障探測機制就能發現這個問題並報告給組中其他成員，組中各成員根據收集到的其他成員資訊，會比較各成員的權重值(由變數group_replication_member_weigth控制)，權重值最高的優先成為新的Master。如果有多個節點具有相同的最高權重值，會按字典順序比較它們的server_uuid值，最小的(升序排序，最小值在最前面)優先成為新的master。

但需要注意，變數group_replication_member_weigth是從MySQL 5.7.20開始提供的，在MySQL 5.7.17到5.7.19之間沒有該變數。此時將根據它們的server_uuid值進行排序選舉。具體的規則可自行測試。

1.3 最多允許多少個節點故障

MySQL組複製使用Paxos分散式演算法來提供節點間的分散式協調。正因如此，它要求組中大多數節點線上才能達到法定票數，從而對一個決策做出一致的決定。

大多數指的是N/2+1(N是組中目前節點總數)，例如目前組中有5個節點，則需要3個節點才能達到大多數的要求。所以，允許出現故障的節點數量如下圖：

1.4 單主模型組複製的要求

見：使用MySQL組複製的限制和侷限性

1.5 更多組複製的理論

若想了解更多組複製的理論以及組複製中每一個過程的細節，請參考我另一篇文章(暫未寫)，或者閱讀我對MySQL官方手冊關於組複製的翻譯。

2.配置單主模型

本文配置3個節點的單主模型組複製。配置很簡單，基本上就是在常規復制選項的基礎上多了幾個選項、多了幾步操作。

拓撲圖如下：

具體環境細節如下：

節點名稱	MySQL版本	客戶端介面(eth0)	組內通訊介面(eth0)	資料狀態
s1	MySQL 5.7.22	192.168.100.21	192.168.100.21	全新例項
s2	MySQL 5.7.22	192.168.100.22	192.168.100.21	全新例項
s3	MySQL 5.7.22	192.168.100.23	192.168.100.21	全新例項

發現了每個節點都給了兩個介面嗎？我這裡配置它們都使用同一個介面eth0。其中：

1. 客戶端介面是mysqld向外提供資料庫服務的，對應埠是3306，例如php程式連線MySQL執行一個查詢語句時就使用該地址。
   
2. 組內節點通訊介面用於組內各節點訊息傳遞，組內兩兩節點建立一條訊息傳遞的TCP連線。所以，3個節點需要建立的組內通訊連線為：s1<-->s2、s1<-->s3、s2<-->s3。

請確保這3個節點的主機名不同，且能正確解析為客戶端介面的地址(別搞錯地址了)，因為在連線donor進行資料恢復的時候，是通過主機名進行解析的。所以，所有節點都要先配置好不同的主機名，並修改/etc/hosts檔案。對於克隆出來的實驗主機，這一步驟很關鍵。以centos 7為例：

# s1上：
hostnamectl set-hostname --static s1.longshuai.com
hostnamectl -H [email protected]168.100.22 set-hostname s2.longshuai.com
hostnamectl -H [email protected]168.100.23 set-hostname s3.longshuai.com

# 寫/etc/hosts
# s1上：
cat >>/etc/hosts<<eof
    192.168.100.21 s1.longshuai.com
    192.168.100.22 s2.longshuai.com
    192.168.100.23 s3.longshuai.com
eof
scp /etc/hosts 192.168.100.22:/etc
scp /etc/hosts 192.168.100.23:/etc

2.1 配置組內第一個節點s1

1.先提供配置檔案。

[mysqld]
datadir=/data
socket=/data/mysql.sock

server-id=100                      # 必須
gtid_mode=on                       # 必須
enforce_gtid_consistency=on        # 必須
log-bin=/data/master-bin           # 必須
binlog_format=row                  # 必須
binlog_checksum=none               # 必須
master_info_repository=TABLE       # 必須
relay_log_info_repository=TABLE    # 必須
relay_log=/data/ www.mcyllpt.com/ relay-log          # 必須，如果不給，將採用預設值
log_slave_updates=ON               # 必須
sync-binlog=1                      # 建議
log-error=/data/error.log
pid-file=/data/mysqld.pid

transaction_write_www.yongshiyule178.com set_extraction=XXHASH64         # 必須
loose-group_replication_www.cmeidi.cn/ group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"  # 必須
loose-group_replication_www.baidu620.com start_on_www.c8q.net boot=off        # 建議設定為OFF
loose-group_replication_www.cvatti.cn local_address="192.168.100.21:20001"   # 必須，下一行也必須
loose-group_replication_group_seeds="192.168.100.21:20001,192.168.100.22:20002"

想要使用組複製，要求還是挺多的。分析一下上面的配置選項：

• (1).因為組複製基於GTID，所以必須開啟gtid_mode和enforce_gtid_consistency。
  
• (2).組複製必須開啟二進位制日誌，且必須設定為行格式的二進位制日誌，這樣才能從日誌記錄中收集資訊且保證資料一致性。所以設定log_bin和binlog_format。
  
• (3).由於MySQL對複製事件校驗的設計缺陷，組複製不能對他們校驗，所以設定binlog_checksum=none。
  
• (4).組複製要將master和relay log的元資料寫入到mysql.slave_master_info和mysql.slave_relay_log_info中。
  
• (5).組中的每個節點都保留了完整的資料副本，它是share-nothing的模式。所以所有節點上都必須開啟log_slave_updates，這樣新節點隨便選哪個作為donor都可以進行非同步複製。
  
• (6).sync_binlog是為了保證每次事務提交都立刻將binlog刷盤，保證出現故障也不丟失日誌。
  
• (7).最後的5行是組複製外掛的配置。以loose_開頭表示即使啟動組複製外掛，MySQL也繼續正常允許下去。這個字首是可選的。
  
• (8).倒數第5行表示寫集合以XXHASH64的演算法進行hash。所謂寫集，是對事務中所修改的行進行的唯一標識，在後續檢測併發事務之間是否修改同一行衝突時使用。它基於主鍵生成，所以使用組複製，表中必須要有主鍵。
  

• (9).倒數第4行表示這個複製組的名稱。它必須是一個有效的UUID值。嫌可以直接和上面一樣全寫字母a。在Linux下，可以使用uuidgen工具來生成UUID值。

  [[email protected] ~]# uuidgen
  09c38ef2-7d81-463e-bdb4-9459b2c0e49b

• (10).倒數第3行表示組複製功能不隨MySQL例項啟動而啟動。雖然，可以將組複製外掛和啟動組複製功能的選項寫在配置檔案裡，但強烈建議不要如此，而是每次手動去配置。
  
• (11).倒數第2行表示本機上用於組內各節點之間通訊的地址和埠。
  

• (12).最後一行，設定本組的種子節點。種子節點的意義在前文已經解釋過了。

現在配置檔案已經提供。可以啟動mysql例項了。

[[email protected] ~]# systemctl start mysqld

2.建立複製使用者。

連上s1節點。建立用於複製的使用者。我這裡建立的使用者為repl，密碼為[email protected]!。

mysql> create user [email protected]'192.168.100.%' identified by '[email protected]!';
mysql> grant replication slave on *.* to [email protected]'192.168.100.%';

3.配置節點加組時的通道。這是組複製的一個關鍵。

在新節點加入組時，首先要選擇donor。新節點和donor之間的非同步複製就是通過一個名為group_replication_recovery的通道(通道名固定，不可使用自定義通道)進行資料恢復的，經過資料恢復後，新節點填充了它缺失的那部分資料，這樣就和組內其他節點的資料保持了同步。

這個恢復過程比較複雜，它是一種分散式恢復。本文不介紹這個，在組複製理論詳解中，我將對此做詳細的說明。

執行change master to語句設定恢復通道。

mysql> change master to 
            master_user='repl',
            master_password='[email protected]!'
            for channel 'group_replication_recovery';

這裡的使用者名稱、密碼和通道在組複製中有一個專門的術語：通道憑據(channel credentials)。通道憑據是連線donor的關鍵。

當執行完上面的語句後，就生成了一個該通道的relay log檔案(注意稱呼：該通道的relay log，後面還有另一個通道的relay log)。如下，其中字首"relay-log"是配置檔案中"relay_log"選項配置的值。

[[email protected] ~]# ls -1 /data/*group*
/data/relay-log-group_replication_recovery.000001
/data/relay-log-group_replication_recovery.index

group_replication_recovery通道的relay log用於新節點加入組時，當新節點聯絡上donor後，會從donor處以非同步複製的方式將其binlog複製到這個通道的relay log中，新節點將從這個recovery通道的relay log中恢復資料。

前面配置檔案中已經指定了master和relay log的元資料資訊要記錄到表中，所以這裡可以先檢視下關於relay log的元資料。

mysql> select * from mysql.slave_relay_log_info\G
*************************** 1. row ***************************
  Number_of_lines: 7
   Relay_log_name: /data/relay-log-group_replication_recovery.000001
    Relay_log_pos: 4
  Master_log_name: 
   Master_log_pos: 0
        Sql_delay: 0
Number_of_workers: 0
               Id: 1
     Channel_name: group_replication_recovery

如果要檢視連線master的元資料資訊，則查詢mysql.slave_master_info表。不過現在沒必要查，因為啥都還沒做呢。

4.安裝組複製外掛，並啟動組複製功能。

一切就緒後，可以開啟mysql例項的組複製功能了。

mysql> install plugin group_replication soname 'group_replication.so';

然後開啟組複製功能。

mysql> set @@global.group_replication_bootstrap_group=on;
mysql> start group_replication;
mysql> set @@global.group_replication_bootstrap_group=off;

這裡的過程很重要，需要引起注意。在開啟組複製之前，設定全域性變數group_replication_bootstrap_group為on，這表示稍後啟動的組複製功能將引導組，也就是建立組並配置組，這些都是自動的。配置引導變數為ON後，再開啟組複製外掛功能，也就是啟動組複製。最後將引導變數設回OFF，之所以要設定回OFF，是為了避免下次重啟組複製外掛功能時再次引導建立一個組，這樣會存在兩個名稱相同實際卻不相同的組。

這幾個過程不適合放進配置檔案中，強烈建議手動執行它們的。否則下次重啟mysql例項時，會自動重新引導建立一個組。同理，除了第一個節點，其他節點啟動組複製功能時，不應該引導組，所以只需執行其中的start語句，千萬不能開啟group_replication_bootstrap_group變數引導組。

這裡的幾個過程，應該形成一個習慣，在啟動第一個節點時，這3條語句同時執行，在啟動其他節點時，只執行start語句。

當啟動組複製功能後，將生成另一個通道group_replication_applier的相關檔案。

[[email protected] ~]# ls -1 /data/*group*
/data/relay-log-group_replication_applier.000001
/data/relay-log-group_replication_applier.000002
/data/relay-log-group_replication_applier.index
/data/relay-log-group_replication_recovery.000001
/data/relay-log-group_replication_recovery.index

是否還記得剛才用於恢復的通道group_replication_recovery？這個applier通道是幹什麼的？在組複製中，沒有常規復制的兩個複製執行緒：io執行緒和sql執行緒，取而代之的是receiver、certifier和applier。這裡簡單介紹一下它們的作用：

• receiver的作用類似於io執行緒，用於接收組內個節點之間傳播的訊息和事務。也用於接收外界新發起的事務。
• applier的作用類似於sql執行緒，用於應用relay log中的記錄。不過，組複製的relay log不再是relay log，而是這裡的組複製relay log：relay-log-group_replication_applier.00000N。
  
• certifier的作用在receiver接收到訊息後，驗證是否有併發事務存在衝突問題。衝突檢測通過後，這條訊息就會寫入到組複製的relay log中，等待applier去應用。

5.驗證組中節點並測試插入不滿足組複製要求的資料。

至此，這個節點的組複製已經配置完成了。現在需要檢視這個節點是否成功加入到組中，成功加入組的標誌是被設定為"ONLINE"。只要沒有設定為ONLINE，就表示組中的這個節點是故障的。

檢視的方式是通過查詢performance_schema架構下的replication_group_members表。在這個架構下，有幾張對於維護組複製來說非常重要的表，這裡的replication_group_members是其中一張。關於其他的表，我會在有需要的地方或者其他文章中解釋。

mysql> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+---------------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST         | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+---------------------+-------------+--------------+
| group_replication_applier | a659234f-6aea-11e8-a361-000c29ed4cf4 | xuexi.longshuai.com |        3306 | ONLINE       |
+---------------------------+--------------------------------------+---------------------+-------------+--------------+

如果不方便觀看，換一種顯示方式：

mysql> select * from performance_schema.replication_group_members\G
*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
   MEMBER_ID: a659234f-6aea-11e8-a361-000c29ed4cf4
 MEMBER_HOST: xuexi.longshuai.com
 MEMBER_PORT: 3306
MEMBER_STATE: ONLINE

請注意這裡的每一行，包括member_host，它是對外連線的地址，所以應該設定它的DNS解析為提供MySQL資料庫服務的介面地址。這很重要，如果你不想去修改DNS解析，可以在啟動組複製之前，設定report_host變數為對外的IP地址，或者將其寫入到配置檔案中。

現在，組中的這個節點已經是ONLINE了，表示可以對外提供組複製服務了。

稍後，將向組中加入第二個節點s2和第三個節點s3，但在加入新節點之前，先向s1節點寫入一些資料，順便測試一下開啟組複製後，必須使用InnoDB、表中必須有主鍵的限制。

下面建立4個表：t1和t4是InnoDB表，t3和t4具有主鍵。

create table t1(id int);
create table t2(id int)engine=myisam;
create table t3(id int primary key)engine=myisam;
create table t4(id int primary key);

雖說組複製對這些有限制，但是建立時是不會報錯的。

向這4張表中插入資料：

insert into t1 values(1);
insert into t2 values(1);
insert into t3 values(1);
insert into t4 values(1);

相關推薦