新特性解讀 | MySQL 8.0.16 在組複製中啓用成員自動從新加入

原創做者： 管長龍 譯

---

做者：Ricardo Ferreira 翻譯：管長龍 標籤：Group Replication, High Availability

隨着 MySQL 8.0.16 的發佈，咱們爲 MGR 添加了一些功能，以加強其高可用性。其中一個功能是可以在某些狀況下啓用已離開組的成員自動從新加入，而無需用戶干預。

爲了理解這個功能的好處以及如何使用它，咱們將快速查看它背後的概念以及它首先存在的動機。

介紹

MGR 容許 MySQL 用戶輕鬆管理高可用組，並完成保證系統高可用所需的全部特徵，例如容錯或故障檢測。

MGR 中提供的基本保證之一是該組呈現給用戶的是一個不可分割的總體，這意味着一旦成員加入或離開該組，該更改將當即被其餘成員得知。默認狀況下，組內的數據自己最終是一致的，儘管能夠被修改。爲了實現這種保證，MGR 使用組成員服務，以及經過一致性算法檢測有衝突的事務並停止它們。MGR 的這一方面超出了本文的範圍，與成員自動從新加入功能並不徹底相關，本文不做贅述。

組內新成員必須符合一些條件。其中新成員須要在事務方面遇上組進度（是經過選擇組內一個成員來將已處理的事務流式傳輸給他，在 MGR 中稱爲「捐贈」）。最後，只要在此「分佈式恢復」過程當中沒有遇到任何錯誤，組內新成員將被聲明爲 ONLINE 狀態。

MGR 依靠組通訊層 (GCS) 來管理組。該層實現了用於解決衝突事務的一致性算法，並強制執行一些通訊特性。對於實現前面提到的組的不可分割視圖，這些特性相當重要，如消息的總順序、安全傳遞或視圖同步等。

GCS 須要可以檢測組中哪些成員失效或看起來失效。一旦這些成員被檢測爲失效，就將其從該組中移除，以便保持該組正常使用。爲此 GCS 在每一個成員中引入了一個故障檢測器，用於分析組內交換的消息。若是它在一段時間內沒有收到來自指定成員的消息，則故障檢測器將對該成員產生「懷疑」，並認爲該成員可能已經失效。成員從「懷疑」到真正失效的等待時間是能夠配置的。

 

從新加入成員存在的問題

咱們已經瞭解 MGR 必須爲了高可用提供的策略，以及它如何實現，接下來請看示例：

一個小組由三個成員組成，其中一個成員偶爾會遇到丟失數據包、斷連或者其它致使沒法解決的錯誤狀況的影響組內通訊。還要考慮這些錯誤持續時間超過 group_replication_member_expel_timeout 的值。

其中一個組員發生故障，小組的其餘成員將決定踢出該成員。問題是，一旦該成員從新入組，他將被組驅逐加入失敗，須要經過手動干預。

若是該成員的驅逐超時屬性設置不爲 0，則它將在被驅逐前等待知足該時間量（將超時設置爲 0 意味着他將永遠等待）。超時後成員將被驅逐並從新創建鏈接，而且沒法從新加入舊組，須要再次手動干預。

於此，當存在網絡故障時，顯然須要手動干預。

在 MySQL 8.0.16 中，咱們引入了自動從新加入組的功能，一旦成員被驅逐出組，它就會自動嘗試從新加入該組，直到達到預設的次數爲止。有時每次重試之間至少等待5分鐘。

 

如何啓動自動從新加入？

能夠經過將 group_replication_autorejoin_tries 設置爲所需的重試次數來開啓並使用自動從新加入功能。

SET GLOBAL group_replication_autorejoin_tries = 3

默認值爲 0，表示服務器禁用自動從新加入。

 

如何驗證自動從新加入？

與 MySQL 中的許多功能同樣，自動從新加入過程是能夠監測的。自動從新加入的可檢測性依賴於性能模式基礎架構，階段式收集有關數據。

他們獲取如下信息：

• 事件發生的線程ID（THREAD_ID）

• 活動名稱（EVENT_NAME）

• 起止時間戳以及事件的總持續時間（TIMER_START，TIMER_END 和 TIMER_WAIT）

• 在事件中止以前完成的工做單位和預估工做單位（WORK_COMPLETED，WORK_ESTIMATED）

所以，當自動從新加入過程開始時，它將在 performance schema 中註冊一個 名爲「stage / grouprpl / Undergoing auto-rejoin procedure」的事件。使用表 performance_schema.events_stage_current，  performance_schema.events_stages_summary_global_by_event_name 和performance_schema.events_stages_history_long 咱們能夠觀察到如下內容：

• 是否正在進行自動從新加入程序

• 到目前爲止，已經減小重試的次數

• 直到下一次重試的估計剩餘時間

 

自動從新加入過程狀態

能夠經過過濾包含「auto-rejoin」字符串的活動事件來查找自動從新加入過程狀態（即，是否正在進行）：

SELECT COUNT(*) FROM performance_schema.events_stages_current
WHERE EVENT_NAME LIKE '%auto-rejoin%';
COUNT(*)
1

查詢結果存在，證實服務器上運行了自動從新加入過程。

 

到目前爲止的重試次數

若是正在進行自動從新加入程序，咱們能夠經過選擇階段事件上的工做單元數來檢查到目前爲止嘗試的重試次數：

SELECT WORK_COMPLETED FROM performance_schema.events_stages_current WHERE
EVENT_NAME LIKE '%auto-rejoin%';
WORK_COMPLETED
1

在這個例子中，到目前爲止只有一次嘗試。

 

預計到下次重試的剩餘時間

在每次從新加入嘗試之間，服務器將處於 5 分鐘的可中斷睡眠中。 從新加入嘗試直到成功或失敗之間的時間是沒法估計的。 所以，爲了粗略估計剩餘時間，咱們能夠將到目前爲止嘗試的重試次數乘以 5 分鐘，並減去到目前爲止的階段事件所花費的時間，以估計咱們還須要多長時間：

SELECT (300.0 - ((TIMER_WAIT*10e-12) - 300.0 * num_retries)) AS time_remaining FROM
(SELECT COUNT(*) - 1 AS num_retries FROM
performance_schema.events_stages_current WHERE EVENT_NAME LIKE '%auto-rejoin%') AS T,
performance_schema.events_stages_current WHERE EVENT_NAME LIKE '%auto-rejoin%';
time_remaining
30.0

因此在這個例子中，在下一次從新加入以前還有 30 秒。注意性能模式表中的全部時間記賬都以微秒精度保持，所以咱們將 TIMER_WAIT 縮放爲秒。

 

使用自動從新加入與驅逐超時的權衡

到目前爲止，在這篇文章中咱們只關注自動從新加入。實際上，有兩種不一樣的方法能夠實現離開組的成員的從新加入：

• 設置自動從新加入嘗試次數來實現自動從新加入

• 設置該成員的驅逐超時時間而後配合手動干預

能有延緩刪除組內可疑成員，而且若是配置爲足夠長的驅逐超時時間，則增長了從新創建鏈接的機會，再次與組進行交互。

雖然這兩個功能實現了相同的目標，但它們的工做方式是不一樣的，而且須要權衡。經過使用驅逐超時，您能夠維護組中可疑的成員，其缺點是您沒法添加或刪除成員或選擇新的主機。若是經過使用自動從新加入，該成員將再也不是該組的正常組員，將保持在 superreadonly 模式，直到從新加入該組。但在此期間，從新加入成員的同步舊數據的可能性將增長。自動從新加入過程可監控，而驅逐超時不是真正可監控的。

 

因此，總結一下：

• 驅逐超時的優勢

- 該成員一直在該組內

- 可能更適合足夠小的網絡故障

• 驅逐超時的缺點

- 在懷疑某個成員時，沒法在該組上添加/刪除成員

- 在懷疑某個成員時，沒法選擇新的主機

- 您沒法監控此過程

• 自動從新加入的優勢

- 該組將在沒有從新加入成員的狀況下運行，您能夠添加/刪除成員並選擇新的主機

- 您能夠監控該過程

• 自動從新加入的缺點

- 您增長了從新加入成員上過期讀取的可能性

- 可能不適合足夠小的網絡故障

 

總而言之，我從啓用自動從新加入中得到了什麼？

經過啓用自動從新加入，您能夠減小對MySQL實例的手動干預的須要。您的系統

更加適應瞬間網絡故障，同時知足對容錯性和高可用的保證。

 

摘要

咱們引入了一個名爲 group_replication_autorejoin_tries 的新系統變量，容許用戶設置 MGR 成員在被驅逐或與組的大多數人失去聯繫後嘗試從新加入組的次數。

默認狀況下，此自動從新加入過程處於關閉狀態。它能幫助用戶在面對瞬間網絡故障時避免對 MGR 成員進行手動干預。