MySQL 8.0.23中復(fù)制架構(gòu)從節(jié)點自動故障轉(zhuǎn)移

作者：佚名 2021-01-28 10:15:09

數(shù)據(jù)庫 MySQL

接觸MGR有一段時間了，MySQL 8.0.23的到來，基于MySQL Group Replicaion（MGR）的高可用架構(gòu)又提供了新的架構(gòu)思路。

災(zāi)備機(jī)房的slave，如何更好的支持主機(jī)房的MGR？

MGR 到底可以壞幾個節(jié)點？

這次我就以上2個問題，和大家簡單聊下MGR的一些思想和功能。

一、MySQL Group Relication 成員數(shù)量的容錯能力

上面的表格相信大家不會陌生了，我經(jīng)常在面試?yán)飼枺?ldquo;4個節(jié)點的MGR，最多壞幾個呢？” ，多數(shù)人回答：“最多壞1個，壞2個就腦裂不能工作了。”

那我們來看看MGR的處理方式，是不是這個答案呢？

1）我們具有一個4節(jié)點MGR

埋一個問題：這個圖一看就是Single模式，但箭頭不是單向，是不是畫錯了？

2）此時，Second-04突然宕機(jī)了，那么MGR集群會成什么樣子呢？

集群此時狀態(tài)會變成：

每個節(jié)點會固定時間交換各自信息。
當(dāng)沒有收到Second-04節(jié)點信息后，其他成員會等待5秒。
這個期間Second-04肯定沒有發(fā)出來消息，于是健康成員認(rèn)為Second-04是可疑狀態(tài)，標(biāo)記UNREACHABLE狀態(tài)。
然后健康成員按照參數(shù)：group_replication_member_expel_timeout，繼續(xù)等待（此時Second-04依然是UNREACHABLE狀態(tài)）。
當(dāng)超過了group_replication_member_expel_timeout時間，健康成員就把Second-04節(jié)點驅(qū)逐出集群了。

那么重點來了，敲黑板

在Second-04，沒有被驅(qū)逐出去時：

此時集群是（4節(jié)點-3健康-1壞）,這個期間如果繼續(xù)壞1個節(jié)點，那么集群變成（4節(jié)點-2健康-2壞），集群沒有滿足多數(shù)原則，每個節(jié)點都無法寫入了（除非人工干預(yù)，強(qiáng)制指定集群成員List）。

在Second-04，被驅(qū)逐出去后：

此時集群是（3節(jié)點-3健康-0壞），4節(jié)點集群退化成3節(jié)點健康集群了，這個時候，集群依然可以繼續(xù)壞一個節(jié)點，變成（3節(jié)點-2健康-1壞）

所以4節(jié)點集群是否可以壞1個還是2個，具體要看集群處理過程哪個階段哦。

PS：

我們說說剛才埋的問題：這個圖一看就是Single模式，但箭頭不是單向，是不是畫錯了？

首先Single模式，Second節(jié)點默認(rèn)是不能寫入的，但只是由于Second節(jié)點的super-read-only開啟了。

將Second節(jié)點super-read-only = 0，Second節(jié)點可以正常寫入，并可以同步其他節(jié)點（Primary和其他Second），傳輸還是基于Paxos協(xié)議的。

跑個火車：Second節(jié)點反向同步其他節(jié)點，是不會經(jīng)過沖突檢測階段（理論效率要高于多寫模式），沒有驗證，大家有興趣可以研究下。

二、 Asynchronous Connection Failover

MySQL 8.0.22,推出了異步復(fù)制連接故障轉(zhuǎn)移，很多朋友都發(fā)文做了介紹，這里我只簡單描述下：

1）同機(jī)房1主1從，異地機(jī)房單獨放一個slave節(jié)點

2）Master 故障，將Slave-01變成Master，Slave-02無法連接原Master

3）如果對Slave-02配置了“異步連接故障轉(zhuǎn)移配置”，那么Slave-02在識別原Master故障后，會自動嘗試按照預(yù)先定義好的配置，與原Slave-01（新Master）建立復(fù)制關(guān)系：

這個功能非常好，引用三方工具（例如MHA的修復(fù)主從關(guān)系）已經(jīng)可以被MySQL原生功能代替了。

但我測試完，又有了幾點疑慮：

1. “異步”復(fù)制故障轉(zhuǎn)移，難道不支持半同步架構(gòu)？不能確保數(shù)據(jù)不丟失，還是無法完全代替MHA啊？

答：其實是支持增強(qiáng)半同步的。

2. 要預(yù)先配置故障轉(zhuǎn)移的Master List，那么A機(jī)房架構(gòu)變更，還要去維護(hù)機(jī)房B的節(jié)點嗎？

答：是的。

3. 如果A機(jī)房是MGR，那么MGR的節(jié)點（master）異常，但服務(wù)沒有關(guān)，可以訪問，機(jī)房B節(jié)點豈不是一直連接著？

答：是的

然后,MySQL 8.0.23發(fā)布了，帶來了此功能的增強(qiáng)：

Slave可以支持MGR集群，并且可以動態(tài)識別MGR成員，來建立Master-Slave關(guān)系了

最后讓我們跑一圈：

1）首先我們有3節(jié)點的MGR集群，版本8.0.22（異步連接故障轉(zhuǎn)移，是作用在Slave的IO Thread上的，所以Slave是8.0.23版本就成）

+----------------------------+-------------+--------------+-------------+---------------------+  
| now(6)                     | member_host | member_state | member_role | VIEW_ID             |  
+----------------------------+-------------+--------------+-------------+---------------------+  
| 2021-01-22 13:41:27.902251 | mysql-01    | ONLINE       | SECONDARY  | 16112906030396799:9 |  
| 2021-01-22 13:41:27.902251 | mysql-02    | ONLINE       | PRIMARY     | 16112906030396799:9 |  
| 2021-01-22 13:41:27.902251 | mysql-03    | ONLINE       | SECONDARY   | 16112906030396799:9 |  
+----------------------------+-------------+--------------+-------------+---------------------+

2）然后我們在獨立Slave節(jié)點，指定Slave上“對Master連接故障轉(zhuǎn)移列表”

SELECT asynchronous_connection_failover_add_managed('ch1', 'GroupReplication', 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1', 'mysql-02', 3306, '', 80, 60);  
簡單解釋下參數(shù)：  
ch1：chanel名稱  
GroupReplication：強(qiáng)制寫死的參數(shù)，目前支持MGR集群  
aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1：MGR組名（參數(shù) group_replication_group_name）  
mysql-02：MGR成員之一  
80：Primary節(jié)點的優(yōu)先級（0-100），多主相同優(yōu)先級則隨機(jī)選擇節(jié)點充當(dāng)master。  
60：Second節(jié)點的優(yōu)先級（0-100），基本就是給Single模式準(zhǔn)備的

3）為Slave指定復(fù)制通道信息

CHANGE REPLICATION SOURCE TO SOURCE_USER='rpl_user', SOURCE_PASSWORD='123456', SOURCE_HOST='mysql-02',SOURCE_PORT=3306,SOURCE_RETRY_COUNT=2,SOURCE_CONNECTION_AUTO_FAILOVER=1,SOURCE_AUTO_POSITION=1 For CHANNEL 'ch1';

4）啟動Slave，并查看“連接的可轉(zhuǎn)移列表”

不開啟io thread，是不會自動識別MGR成員的。并且復(fù)制用戶

rpl_user需要在MGR節(jié)點對performance_schema具有select權(quán)限

start slave;  
SELECT * FROM performance_schema.replication_asynchronous_connection_failover;  
+--------------+----------+------+-------------------+--------+--------------------------------------+  
| CHANNEL_NAME | HOST     | PORT | NETWORK_NAMESPACE | WEIGHT | MANAGED_NAME                         |  
+--------------+----------+------+-------------------+--------+--------------------------------------+  
| ch1          | mysql-01 | 3306 |                   |     60 | aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1 |  
| ch1          | mysql-02 | 3306 |                   |     80 | aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1 |  
| ch1          | mysql-03 | 3306 |                   |     60 | aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1 |  
+--------------+----------+------+-------------------+--------+--------------------------------------+

5）然后我們將mysql-02 stop group_replication(不是關(guān)閉服務(wù))，

Slave列表自動淘汰mysql-02，重新與其他節(jié)點建立連接-- mysql-02(Primary):  
stop group_replication;  
-- Slave:  
SELECT * FROM performance_schema.replication_asynchronous_connection_failover;  
+--------------+----------+------+-------------------+--------+--------------------------------------+  
| CHANNEL_NAME | HOST     | PORT | NETWORK_NAMESPACE | WEIGHT | MANAGED_NAME                         |  
+--------------+----------+------+-------------------+--------+--------------------------------------+  
| ch1          | mysql-01 | 3306 |                   |     80 | aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1 |  
| ch1          | mysql-03 | 3306 |                   |     60 | aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1 |  
+--------------+----------+------+-------------------+--------+--------------------------------------+  
show slave status\G  
*************************** 1. row ***************************  
               Slave_IO_State: Waiting for master to send event  
                  Master_Host: mysql-01  
                  Master_User: rpl_user  
                  Master_Port: 3306  
                Connect_Retry: 60  
              Master_Log_File: mybinlog.000003  
          Read_Master_Log_Pos: 4904  
               Relay_Log_File: mysql-01-relay-bin-ch1.000065  
                Relay_Log_Pos: 439  
        Relay_Master_Log_File: mybinlog.000003  
             Slave_IO_Running: Yes  
            Slave_SQL_Running: Yes  
            ...

至此，配置完成。后面MGR節(jié)點增、減，Slave都可以自動維護(hù)這個列表。不貼其他用例了。

PS:

如果想手工切換Slave已建立的Master節(jié)點（Primary）連接到其他節(jié)點（Second）上，只需要刪除“復(fù)制連接的可轉(zhuǎn)移列表”，重新調(diào)整Second優(yōu)先級加回即可。

-- 刪除配置  
SELECT asynchronous_connection_failover_delete_managed('ch1', 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1');  
-- 重新添加，調(diào)整Second優(yōu)先級高于Primary  
SELECT asynchronous_connection_failover_add_managed('ch1', 'GroupReplication', 'aaaaaa

責(zé)任編輯：龐桂玉來源：老葉茶館

MySQL 架構(gòu)數(shù)據(jù)庫