接觸MGR有一段時間了,MySQL 8.0.23的到來,基於MySQL Group Replicaion(MGR)的高可用架構又提供了新的架構思路。
災備機房的slave,如何更好的支持主機房的MGR?
MGR 到底可以壞幾個節點?
這次我就以上2個問題,和大家簡單聊下MGR的一些思想和功能。
一、MySQL Group Relication 成員數量的容錯能力
上面的表格相信大家不會陌生了,我經常在面試裏會問:“4個節點的MGR,最多壞幾個呢?” ,多數人回答:“最多壞1個,壞2個就腦裂不能工作了。”
那我們來看看MGR的處理方式,是不是這個答案呢?
1)我們具有一個4節點MGR
埋一個問題:這個圖一看就是Single模式,但箭頭不是單向,是不是畫錯了?
2)此時,Second-04突然宕機了,那麼MGR集羣會成什麼樣子呢?
集羣此時狀態會變成:
每個節點會固定時間交換各自信息。
當沒有收到Second-04節點信息後,其他成員會等待5秒。
這個期間Second-04肯定沒有發出來消息,於是健康成員認爲Second-04是可疑狀態,標記UNREACHABLE狀態。
然後健康成員按照參數:group_replication_member_expel_timeout,繼續等待(此時Second-04依然是UNREACHABLE狀態)。
當超過了group_replication_member_expel_timeout時間,健康成員就把Second-04節點驅逐出集羣了。
那麼重點來了,敲黑板
在Second-04,沒有被驅逐出去時:
此時集羣是(4節點-3健康-1壞),這個期間如果繼續壞1個節點,那麼集羣變成(4節點-2健康-2壞),集羣沒有滿足多數原則,每個節點都無法寫入了(除非人工干預,強制指定集羣成員List)。
在Second-04,被驅逐出去後:
此時集羣是(3節點-3健康-0壞),4節點集羣退化成3節點健康集羣了,這個時候,集羣依然可以繼續壞一個節點,變成(3節點-2健康-1壞)
所以4節點集羣是否可以壞1個還是2個,具體要看集羣處理過程哪個階段哦。
PS:
我們說說剛纔埋的問題:這個圖一看就是Single模式,但箭頭不是單向,是不是畫錯了?
首先Single模式,Second節點默認是不能寫入的,但只是由於Second節點的super-read-only開啓了。
將Second節點super-read-only = 0,Second節點可以正常寫入,並可以同步其他節點(Primary和其他Second),傳輸還是基於Paxos協議的。
跑個火車:Second節點反向同步其他節點,是不會經過沖突檢測階段(理論效率要高於多寫模式),沒有驗證,大家有興趣可以研究下。
二、 Asynchronous Connection Failover
MySQL 8.0.22,推出了異步複製連接故障轉移,很多朋友都發文做了介紹,這裏我只簡單描述下:
1)同機房1主1從,異地機房單獨放一個slave節點
2)Master 故障,將Slave-01變成Master,Slave-02無法連接原Master
3)如果對Slave-02配置了“異步連接故障轉移配置”,那麼Slave-02在識別原Master故障後,會自動嘗試按照預先定義好的配置,與原Slave-01(新Master)建立複製關係:
這個功能非常好,引用三方工具(例如MHA的修復主從關係)已經可以被MySQL原生功能代替了。
但我測試完,又有了幾點疑慮:
1. “異步”複製故障轉移,難道不支持半同步架構?不能確保數據不丟失,還是無法完全代替MHA啊?
答:其實是支持增強半同步的。
2. 要預先配置故障轉移的Master List,那麼A機房架構變更,還要去維護機房B的節點嗎?
答:是的。
3. 如果A機房是MGR,那麼MGR的節點(master)異常,但服務沒有關,可以訪問,機房B節點豈不是一直連接着?
答:是的
然後,MySQL 8.0.23發佈了,帶來了此功能的增強:
Slave可以支持MGR集羣,並且可以動態識別MGR成員,來建立Master-Slave關係了
最後讓我們跑一圈:
1)首先我們有3節點的MGR集羣,版本8.0.22(異步連接故障轉移,是作用在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節點,指定Slave上“對Master連接故障轉移列表”
SELECT asynchronous_connection_failover_add_managed('ch1', 'GroupReplication', 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1', 'mysql-02', 3306, '', 80, 60);
簡單解釋下參數:
ch1:chanel名稱
GroupReplication:強制寫死的參數,目前支持MGR集羣
aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1:MGR組名(參數 group_replication_group_name)
mysql-02:MGR成員之一
80:Primary節點的優先級(0-100),多主相同優先級則隨機選擇節點充當master。
60:Second節點的優先級(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 'ch1';
4)啓動Slave,並查看“連接的可轉移列表”
不開啓io thread,是不會自動識別MGR成員的。並且複製用戶
rpl_user需要在MGR節點對performance_schema具有select權限
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(不是關閉服務),
Slave列表自動淘汰mysql-02,重新與其他節點建立連接-- 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節點增、減,Slave都可以自動維護這個列表。不貼其他用例了。
PS:
如果想手工切換Slave已建立的Master節點(Primary)連接到其他節點(Second)上,只需要刪除“複製連接的可轉移列表”,重新調整Second優先級加回即可。
-- 刪除配置
SELECT asynchronous_connection_failover_delete_managed('ch1', 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1');
-- 重新添加,調整Second優先級高於Primary
SELECT asynchronous_connection_failover_add_managed('ch1', 'GroupReplication', 'aaaaaaaaaaaa-aaaa-aaaa-aaaaaaaaaaa1', 'mysql-03', 3306, '', 60, 80);
參考連接:
https://mysqlhighavailability.com/automatic-asynchronous-replication-connection-failover/
https://my.oschina.net/u/4591256/blog/4813037
https://dev.mysql.com/doc/refman/8.0/en/replication-functions-source-list.html