溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

MySQL 8.0.23中復制架構從節(jié)點自動故障轉(zhuǎn)移的方法是什么

發(fā)布時間:2021-10-22 09:39:40 來源:億速云 閱讀:216 作者:iii 欄目:數(shù)據(jù)庫

這篇文章主要講解了“MySQL 8.0.23中復制架構從節(jié)點自動故障轉(zhuǎn)移的方法是什么”,文中的講解內(nèi)容簡單清晰,易于學習與理解,下面請大家跟著小編的思路慢慢深入,一起來研究和學習“MySQL 8.0.23中復制架構從節(jié)點自動故障轉(zhuǎn)移的方法是什么”吧!

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

MySQL 8.0.23中復制架構從節(jié)點自動故障轉(zhuǎn)移的方法是什么

上面的表格相信大家不會陌生了,我經(jīng)常在面試里會問:“4個節(jié)點的MGR,最多壞幾個呢?” ,多數(shù)人回答:“最多壞1個,壞2個就腦裂不能工作了。”

MySQL 8.0.23中復制架構從節(jié)點自動故障轉(zhuǎn)移的方法是什么

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

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

MySQL 8.0.23中復制架構從節(jié)點自動故障轉(zhuǎn)移的方法是什么

埋一個問題:這個圖一看就是Single模式,但箭頭不是單向,是不是畫錯了?

2)此時,Second-04突然宕機了,那么MGR集群會成什么樣子呢?

MySQL 8.0.23中復制架構從節(jié)點自動故障轉(zhuǎn)移的方法是什么

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

MySQL 8.0.23中復制架構從節(jié)點自動故障轉(zhuǎn)移的方法是什么

  •  每個節(jié)點會固定時間交換各自信息。

  •  當沒有收到Second-04節(jié)點信息后,其他成員會等待5秒。

  •  這個期間Second-04肯定沒有發(fā)出來消息,于是健康成員認為Second-04是可疑狀態(tài),標記UNREACHABLE狀態(tài)。

  •  然后健康成員按照參數(shù):group_replication_member_expel_timeout,繼續(xù)等待(此時Second-04依然是UNREACHABLE狀態(tài))。

  •  當超過了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é)點都無法寫入了(除非人工干預,強制指定集群成員List)。

MySQL 8.0.23中復制架構從節(jié)點自動故障轉(zhuǎn)移的方法是什么

在Second-04,被驅(qū)逐出去后:

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

MySQL 8.0.23中復制架構從節(jié)點自動故障轉(zhuǎn)移的方法是什么

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

PS:

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

首先Single模式,Second節(jié)點默認是不能寫入的,但只是由于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,推出了異步復制連接故障轉(zhuǎn)移,很多朋友都發(fā)文做了介紹,這里我只簡單描述下:

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

MySQL 8.0.23中復制架構從節(jié)點自動故障轉(zhuǎn)移的方法是什么

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

MySQL 8.0.23中復制架構從節(jié)點自動故障轉(zhuǎn)移的方法是什么

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

MySQL 8.0.23中復制架構從節(jié)點自動故障轉(zhuǎn)移的方法是什么

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

但我測試完,又有了幾點疑慮:

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

答:其實是支持增強半同步的。

2. 要預先配置故障轉(zhuǎn)移的Master List,那么A機房架構變更,還要去維護機房B的節(jié)點嗎?

答:是的。

3. 如果A機房是MGR,那么MGR的節(jié)點(master)異常,但服務沒有關,可以訪問,機房B節(jié)點豈不是一直連接著?

答:是的

然后,MySQL 8.0.23發(fā)布了,帶來了此功能的增強:

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

MySQL 8.0.23中復制架構從節(jié)點自動故障轉(zhuǎ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('ch2', 'GroupReplication', 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1', 'mysql-02', 3306, '', 80, 60);  簡單解釋下參數(shù):  ch2:chanel名稱  GroupReplication:強制寫死的參數(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)先級則隨機選擇節(jié)點充當master。  60:Second節(jié)點的優(yōu)先級(0-100),基本就是給Single模式準備的

3)為Slave指定復制通道信息

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 'ch2';

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

  •  不開啟io thread,是不會自動識別MGR成員的。并且復制用戶

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

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

5)然后我們將mysql-02 stop group_replication(不是關閉服務),

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                         |  +--------------+----------+------+-------------------+--------+--------------------------------------+  | ch2          | mysql-01 | 3306 |                   |     80 | aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1 |  | ch2          | 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-ch2.000065                  Relay_Log_Pos: 439          Relay_Master_Log_File: mybinlog.000003               Slave_IO_Running: Yes              Slave_SQL_Running: Yes              ...

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

PS:

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

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

感謝各位的閱讀,以上就是“MySQL 8.0.23中復制架構從節(jié)點自動故障轉(zhuǎn)移的方法是什么”的內(nèi)容了,經(jīng)過本文的學習后,相信大家對MySQL 8.0.23中復制架構從節(jié)點自動故障轉(zhuǎn)移的方法是什么這一問題有了更深刻的體會,具體使用情況還需要大家實踐驗證。這里是億速云,小編將為大家推送更多相關知識點的文章,歡迎關注!

向AI問一下細節(jié)

免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權內(nèi)容。

AI