[[438893]]

Orchestrator 是一款成熟的 MySQL 高可用中間件。采用 Go 語言編寫，支持拓?fù)浒l(fā)現(xiàn)、集群重塑、拓?fù)浠謴?fù)等功能。

主要功能

拓?fù)浒l(fā)現(xiàn)：Orchestrator 主動(dòng)搜尋并記錄 MySQL 節(jié)點(diǎn)的主從配置、復(fù)制狀態(tài)等基礎(chǔ)信息并進(jìn)行拓?fù)溆成洹＜词拱l(fā)生故障，它依然可以提供出色的可視化拓?fù)鋱D。

集群重塑：Orchestrator 了解復(fù)制規(guī)則。它能準(zhǔn)確識(shí)別復(fù)制類型：Binlog 位點(diǎn)復(fù)制、GTID 復(fù)制、偽 GTID 復(fù)制、Binlog Server。Orchestrator 還提供了復(fù)制檢查功能，保證了副本的移動(dòng)安全可靠。

拓?fù)浠謴?fù)：Orchestrator 定義了 30 種故障模型，根據(jù)集群拓?fù)湫畔⒖删珳?zhǔn)識(shí)別故障類型。針對不同的故障類型還提供了 15 種恢復(fù)執(zhí)行計(jì)劃，大大降低了恢復(fù)失敗的概率。

優(yōu)勢

相較于 MHA 它有以下優(yōu)勢：

• 可視化：Orchestrator 提供了整潔的可視化界面
• 拓?fù)浒l(fā)現(xiàn)：拓?fù)渥詣?dòng)發(fā)現(xiàn)的能力，大大簡化了集群管理
• 高可用：Orchestrator 自身基于 Raft 一致性算法實(shí)現(xiàn)高可用
• 安全：Orchestrator 強(qiáng)大的審計(jì)功能，讓我們的每一步操作都有跡可循
• 精準(zhǔn)：多達(dá) 30 種故障模型，大大降低了誤切的可能性
• 高效：Orchestrator 為我們提供了 200+ 的 api 來幫助我們管理 MySQL
• 快速：3s 發(fā)現(xiàn)故障 7s 完成切換

高可用

Orchestrator 高可用的實(shí)現(xiàn)主要分為兩步：

故障檢測

函數(shù)入口：ContinuousDiscovery --> CheckAndRecover --> GetReplicationAnalysis

故障檢測的工作周期為 1 秒，它的主要工作如上圖所示：

1. 集群拓?fù)湫畔@?。和ㄟ^ select 語句從后端獲取 Binlog 位點(diǎn)、探活是否有效、從庫復(fù)制情況等集群拓?fù)湫畔?
2. 定義故障類型：通過獲取到的集群拓?fù)湫畔⑴卸ü收项愋?
3. 探測潛在故障：除了判定故障類型外還會(huì)探測集群可能存在的潛在故障。Orchestrator 一共定義了 err1236 在內(nèi)的 15 種潛在故障類型;

故障恢復(fù)

函數(shù)入口：ContinuousDiscovery --> CheckAndRecover --> executeCheckAndRecoverFunction

故障恢復(fù)的工作周期也是 1 秒，它的主要工作如下：

1. 獲取恢復(fù)執(zhí)行計(jì)劃：Orchestrator 一共定義了 15 種執(zhí)行計(jì)劃，根據(jù)不同的故障類型它會(huì)選擇不同的執(zhí)行計(jì)劃;
2. leader 節(jié)點(diǎn)檢查：Orchestrator 集群只有 leader 節(jié)點(diǎn)有權(quán)限執(zhí)行恢復(fù)操作;
3. 故障注冊：對于每一個(gè)故障只有注冊成功才能執(zhí)行后續(xù)的恢復(fù)操作;
4. 全局恢復(fù)設(shè)置檢查：檢查是否開啟了全局恢復(fù)禁止，如果有則中斷恢復(fù);
5. 執(zhí)行步驟 1 中獲取的執(zhí)行計(jì)劃;
6. 調(diào)用 PostUnsuccessfulFailoverProcesses/PostFailoverProcesses 鉤子 ;

執(zhí)行計(jì)劃

Orchestrator 定義了 15 種執(zhí)行計(jì)劃，本次詳解故障類型 DeadMaster

故障定義：主節(jié)點(diǎn)無法訪問，且所有從節(jié)點(diǎn)的復(fù)制都處于失敗狀態(tài);

判斷標(biāo)準(zhǔn)：1、主節(jié)點(diǎn)訪問失敗;2、從節(jié)點(diǎn)訪問正常，且所有從節(jié)點(diǎn)復(fù)制都失敗;

DeadMaster 的執(zhí)行計(jì)劃為：checkAndRecoverDeadMaster

函數(shù)入口：CheckAndRecover --> executeCheckAndRecoverFunction --> checkAndRecoverDeadMaster

詳細(xì)流程如上圖：

1. 注冊本次故障恢復(fù);
2. 調(diào)用 PreFailoverProcesses Hook ;
3. 獲取恢復(fù)類型：GTID、偽 GTID、Binlog 位點(diǎn);
4. 集群重塑：選主、集群拓?fù)湔{(diào)整;
5. 給故障節(jié)點(diǎn)打上維護(hù)標(biāo)簽;
6. 切換前地理位置檢測：如果我們做了不允許跨 DC 故障轉(zhuǎn)移的設(shè)置，本次恢復(fù)將中斷;
7. 檢查新主的復(fù)制延時(shí)是否超過閥值，如果超過將中斷本次恢復(fù);
8. 解析本次恢復(fù)，為本次恢復(fù)打上成功或者失敗的標(biāo)簽;
9. 新主執(zhí)行：stop slave; 和 reset slave all;
10. 新主執(zhí)行：set read only false;
11. 嘗試舊主執(zhí)行：set read only true;
12. 在新主執(zhí)行分離操作：在新主上利用 change master to master_host="//host" ... 命令給 master_host 加上注釋標(biāo)簽，防止舊主復(fù)活后新主重新掛載。這一步和第 9 步互斥;
13. 替換集群名;
14. 調(diào)用 PostMasterFailoverProcesses Hook;

集群重塑

執(zhí)行計(jì)劃中最為關(guān)鍵的就是 RegroupReplicasGTID (集群重塑)這一步，接下來我們繼續(xù)分析 Orchestrator 的集群重塑;

集群重塑一共有三個(gè)主要工作：選主、復(fù)制檢查、結(jié)構(gòu)調(diào)整;

選主

• 同 DC、同物理環(huán)境檢查
• 提升權(quán)限檢查：must > prefer
• 副本有效性檢查：檢查副本是否開啟 Binlog、檢查副本是不是偽副本( Binlog Server)
• 提升權(quán)限被禁止檢查：候選副本被禁止參與選主(被禁止包含：PromoteRule 禁止和配置文件中 PromotionIgnoreHostnameFilters 參數(shù)禁止)
• 版本檢查：版本不低于集群中大多數(shù)版本
• Binlog 格式檢查：Binlog 格式不小于集群中的最大 binlog 格式(比較規(guī)則：ROW>MIX>STATEMENT)

復(fù)制檢查

主要是執(zhí)行有效從節(jié)點(diǎn)到新主節(jié)點(diǎn)的復(fù)制可行性檢查，具體如下：

• 檢查新主是否開啟 Binlog 日志;
• 檢查新主是否開啟 log_slave_updates 參數(shù);
• 從節(jié)點(diǎn)和主節(jié)點(diǎn)版本比較：從庫是否比主庫版本小、從庫是否是 Binlog server;
• 從庫在開啟 Binlog 和 log_slave_updates 的情況下檢查從庫的 Binlog 格式是否低于新主;
• 排除被復(fù)制篩選掉的從節(jié)點(diǎn)(VerifyReplicationFilters 參數(shù)控制開關(guān));
• 檢查 sever id 是否相等;
• 檢查 uuid 是否相等且不得為空;
• 檢查是否從庫 sqldelay < 新主 sqldelay 且主庫 sqldelay > ReasonableMaintenanceReplicationLagSeconds 參數(shù);

結(jié)構(gòu)調(diào)整

• 結(jié)構(gòu)調(diào)整主要分為三步：
• StopReplication：1、從節(jié)點(diǎn)有效性檢查;2、執(zhí)行 stop slave;
• ChangeMasterTo: 1、檢查從節(jié)點(diǎn) io 線程和 sql 線程是否停止;2、新主 hostname 解析;3、執(zhí)行 change master to master_host=?, master_port=?;
• StartReplication：執(zhí)行 start salve;

本文轉(zhuǎn)載自微信公眾號(hào)「悅專欄」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系悅專欄公眾號(hào)。