【沃趣科技】MySQL高可用工具Orchestrator系列四：拓撲恢復

沃趣科技作為國內領先的資料庫雲平臺解決方案提供商，一直致力於企業級資料庫雲平臺產品的研發，為使用者提供高效能、高可用、可擴充套件的的資料庫雲環境及不同業務場景需求的資料庫平臺，滿足客戶對極致效能、資料安全、容災備份、業務永續等需求。沃趣科技憑藉專業的團隊，優質的產品，前沿的技術，貼心的服務贏得了客戶的信任與尊重，也獲得了市場的認同。

————————————————————————————

前言

上篇文章講了orchestrator的探測機制。本篇文章翻譯自orchestrator官方文件，講一講orchestrator的拓撲恢復。

拓撲恢復

orch能夠從一系列故障場景中進行恢復。尤其是，它能夠對主庫或者中間主庫的故障場景進行恢復。

自動和手動

orch支援：

• 自動恢復（對意外故障採取措施）。

• 優雅地、有計劃地主從切換。

• 手動恢復。

• 手動，強制failover。

要求

要執行任何型別的故障轉移，拓撲必須支援以下任一種：

• Oracle GTID（master_auto_position=1）

• MariaDB GTID

• Pseudo GTID（偽GTID）

• Binlog Servers

什麼是恢復

恢復基於故障檢測，並且由一系列事件組成：

• 恢復前的hooks（hook：外部的執行過程或者指令碼）。

• 修復拓撲。

• 恢復後的hooks。

注意：

• 恢復前的hooks由使用者自己配置。

  - 順序執行。

  - 任何一個hook的失敗（非零退出碼）都將中止故障轉移。

• 拓撲修復是由orch管理的，並且是基於狀態，而不是基於配置。orch在考慮到現有拓撲、版本、伺服器配置等因素的情況下，會力圖盡力而為。

• 恢復後的hooks也是由使用者自己配置。

恢復場景1：中間主庫掛掉

一個簡單的恢復案例是DeadIntermediateMaster。它的replicas被孤立了，但是當使用了GTID或者Pseudo GTID的情況下，replicas仍然能夠被重連到拓撲中。我們可能會選擇這樣做：

• 找到已失效的中間主伺服器的同級，然後將孤立的副本移到所述同級之下。

• 從孤立的副本中提升某個副本，使得這個副本成為同級的中間主庫，然後將這個副本連線到拓撲。

• 重置所有的孤立副本。

• 結合以上部分做法。

實際的實現方式很大程度上取決於拓撲設定（哪些例項設定了log-slave-updates、例項是否有延遲、是否存在複製過濾、mysql的版本等等）。你的拓撲很有可能至少支援以上一種方式（特別是，匹配副本是一個簡單的解決方案，除非使用了複製過濾）。

恢復場景2：主庫掛掉

從掛掉的主庫恢復是一個更為複雜的操作，有很多種原因：

• 有潛在的執行中斷（停電、網路），恢復要儘可能地快。

• 在恢復過程中，有些servers可能會丟失。orch需要確定會是哪個。

• 拓撲的狀態可能是使用者希望阻止恢復。

• 必須進行主服務發現：應用必須能夠與新的主庫進行通訊（潛在地被告知主庫已經更改了）。

• 需要找到最合適的replica，將其提升為主庫。

  - 一個天真的方法是選擇最新的副本，但這不一定總是正確的選擇。

  - 最新的副本不一定有必要的配置來作為其他replica的主庫（比如：binlog format、mysql版本、複製過濾器等）。盲目地提升最新的副本為主庫，可能會失去副本冗餘的能力。

  - orch會嘗試提升保留最大服務容量的副本為主庫。

• 提升所述副本，接管它的同級。

• 使它的同級保持最新狀態（up to date）。

• 也許，要做一個二階段提升；使用者可能已經標記了要提升的特定伺服器（參考register-candidate命令）。

• 呼叫hooks。

主服務發現很大程度上是需要使用者去實現的。常見的解決方案有：

• 基於DNS的發現；orch需要呼叫能修改DNS入口的hook。

• ZooKeeper/Consul KV/etcd/其他基於鍵值的發現；orch內建了對Consul KV的支援，否則外部的hook必須更新k-v儲存系統。

• 基於proxy的發現；orch會呼叫外部的hook去更新proxy的配置，或者更新如上所說的Consul/Zk/etcd，這本身就會觸發更新proxy的配置。

• 其他方式。

orch嘗試作為一種通用的解決方案，因此，不限制使用者的服務發現方法。

自動恢復

可選。自動恢復可能會應用於所有（"*"）叢集或者特定叢集。

恢復是在檢測之後進行的，並且假設恢復沒有被阻礙（請參閱下文）。

為了更好的解決方案，將不同的配置應用於主恢復和中間主恢復。一下是與恢復相關的配置的詳細分類。

分析機制始終執行，並定期檢查故障/恢復情況。它將對以下進行自動恢復：

• 一種可操作的場景（只有一個主庫的情況就不符合）。

• 未處於downtime的例項。

• 對於屬於某個叢集的例項，這個叢集透過配置明確啟用了恢復。

• 對於最近尚未恢復的叢集中的例項，除非確認了這些最近的恢復。

• 啟用了全域性恢復。

優雅的主庫提升

使用這個來按計劃、有序地替換主庫。

通常，出於升級，主機維護等，會要將主庫替換成另一臺。這就是優雅的提升主庫。

在優雅的接管中：

• 指定一臺server去提升。

• orch會將master設定成read-only。

• orch確保指定的伺服器追上了複製。

• orch將指定的server提升為新的主庫。

• orch將提升的server設定為可寫。

該操作會花費幾秒鐘的時間，在此期間應用看到的主庫是read-only。

除了標準的hooks，orch提供了專門的hooks來執行graceful takeover：

• PreGracefulTakeoverProcesses

• PostGracefulTakeoverProcesses

例如，你可能想在計劃的故障轉移期間禁用尋呼機。高階的用法是將流量停滯在代理層。

在優雅的提升主庫中，必須滿足以下任一種：

• 指定要提升的server（必須是master的直接replica）。

• 設定拓撲，使得master下只存在一個直接replica（在這種情況下，指定副本的身份不重要，無需提及）。

透過以下方式呼叫graceful takeover：

• 命令列：orchestrator-client -c graceful-master-takeover -alias mycluster -s designated.master.to.promote:3306

• web api：

  - /api/graceful-master-takeover/:clusterHint/:designatedHost/:designatedPort

  優雅地提升新主庫（計劃的故障轉移），指定要提升的伺服器。

  - /api/graceful-master-takeover/:clusterHint

  優雅地提升新主庫（計劃的故障轉移）。未指定伺服器，在master只有一個直接副本時起作用。

• web介面：

  - 將master的直接副本拖拽到master框的左半邊。

手動恢復

當例項被識別為fail但自動恢復被禁用或者被阻塞的情況下，使用手動恢復方式。

可以透過提供一個失敗的特定例項來讓orch來進行恢復。該例項必須被識別為failure。可以對處於downtime的例項請求恢復（因為這是手動恢復，能夠覆蓋掉自動的配置）。透過以下方式恢復：

• 命令列：orchestrator-client -c recover -i dead.instance.com:3306 --debug

• web api：/api/recover/dead.instance.com/:3306

• web介面：例項變成了黑色；點選recovery按鈕。

手動恢復不受引數RecoveryPeriodBlockSeconds影響，也不受引數RecoverMasterClusterFilters和RecoverIntermediateMasterClusterFilters的影響。因此，使用者總是可以按需要來進行恢復。當一個資料庫例項已經有恢復在執行的時候，這個例項的同一時刻的恢復才有可能會阻塞。

手動，強制故障轉移

強制故障轉移會忽略orch自己的想法。

也許，orch不認為某個例項fail了，或者你的應用邏輯要求master此刻必須change，或者也許orch對fail的型別不是很確定。你希望此刻就進行故障轉移，可以這麼做：

• 命令列：orchestrator-client -c force-master-failover --alias mycluster

  或者orchestrator-client -c force-master-failover -i instance.in.that.cluster

• web api：/api/force-master-failover/mycluster

  或者/api/force-master-failover/instance.in.that.cluster/3306

web，api，命令列

透過以下方式審計恢復情況：

• /web/audit-recovery

• /api/audit-recovery

• /api/audit-recovery-steps/:uid

透過以下方式進行審計和控制：

• /api/blocked-recoveries: 被阻塞的恢復。

• /api/ack-recovery/cluster/:clusterHint: 確認給定叢集上的恢復。

• /api/ack-all-recoveries: 確認所有恢復。

• /api/disable-global-recoveries: 全域性開關以禁用orch執行任何恢復。

• /api/enable-global-recoveries: 重新啟用恢復。

• /api/check-global-recoveries: 檢查是否啟用了全域性恢復。

執行手動恢復：

• /api/recover/:host/:port: 恢復指定主機，假定orch認同發生了故障。

• /api/recover-lite/:host/:port: 和上面相同，不使用外部hooks （對測試有用）。

• /api/graceful-master-takeover/:clusterHint/:designatedHost/:designatedPort: 優雅地提升一個新主（計劃的故障轉移）, 指定要提升的伺服器。

• /api/graceful-master-takeover/:clusterHint: 優雅地提升一個新主（計劃的故障轉移）。未指定伺服器，在master只有一個直接副本時起作用。

• /api/force-master-failover/:clusterHint: 緊急情況下，強制給定叢集進行故障轉移。

一些相應的命令列呼叫：

• orchestrator-client -c recover -i some.instance:3306

• orchestrator-client -c graceful-master-takeover -i some.instance.in.somecluster:3306

• orchestrator-client -c graceful-master-takeover -alias somecluster

• orchestrator-client -c force-master-takeover -alias somecluster

• orchestrator-client -c ack-cluster-recoveries -alias somecluster

• orchestrator-client -c ack-all-recoveries

• orchestrator-client -c disable-global-recoveries

• orchestrator-client -c enable-global-recoveries

• orchestrator-client -c check-global-recoveries

阻塞，確認，防震盪

orch透過引入阻塞時間段來避免發生震盪（連鎖故障導致了連續的中斷和資源消耗）。在任何給定的叢集上，除非使用者明確允許，否則orch都不會在小於該阻塞時間段的時間間隔啟用自動恢復。

阻塞時間段用引數RecoveryPeriodBlockSeconds表示。它僅用於在同一叢集上的恢復。在不同叢集上的並行恢復是不受影響的。

處於pending狀態中的恢復一旦超過了RecoveryPeriodBlockSeconds時間或者已經被確認（acknowledged），則阻塞就被解除。

可以透過Web API /介面（檢視audit/recovery page）或透過命令列介面（orchestrator-client -c ack-cluster-recoveries -alias somealias）確認恢復。

請注意，手動恢復（例如orchestrator-client -c recover或orchstrator-client -c force-master-failover）會忽略阻塞時間段。

新增提升規則

在發生故障轉移時，某些伺服器更適合被提升為主庫，某些伺服器則不適合被提升為主庫。例如：

• 某個伺服器的硬體配置較差。偏向於不提升它為主庫。

• 某個伺服器位於遠端的資料中心，不想要把它提升為主庫。

• 某個伺服器用作備份源，並且始終開啟LVM快照。不想要把它提升為主庫。

• 某個伺服器配置不錯，非常適合作為candidate。偏向於提升它為主庫。

• 某個伺服器配置一般，沒有特別的偏好。

可以透過以下方式來設定偏好：

orchestrator -c register-candidate -i ${::fqdn} --promotion-rule ${promotion_rule}

提升規則有：

• prefer

• neutral

• prefer_not

• must_not

提升規則預設有效期1個小時（引數：CandidateInstanceExpireMinutes）。這符合orch的動態特質。可以透過設定cron job的方式來指定提升規則：

*/2 * * * * root "/usr/bin/perl -le 'sleep rand 10' && /usr/bin/orchestrator-client -c register-candidate -i this.hostname.com --promotion-rule prefer"

此設定來自生產環境。這個cron會透過puppet來更新，來表示合適的promotion_rule。某個伺服器可能在某個時刻會是perfer，但5分鐘過後變成了prefer_not。整合你自己的服務發現方法、指令碼，來提供最新的promotion_rule。

停機時間（Downtime）

所有的故障/恢復已經分析了。但是，還應該考慮例項的停機狀態。某個例項可以透過orchestrator-client -c begin-downtime被停機。自動恢復會跳過停機的伺服器。

實際上，停機是專門為此目的而建立的，它使DBA可以阻止自動故障轉移到特定伺服器。

請注意，手動恢復（例如orchestrator-client -c recover）將覆蓋停機時間。

recovery hooks

orch支援hooks——在恢復過程中呼叫的外部指令碼。這些是透過shell呼叫的命令陣列，尤其是bash。

• OnFailureDetectionProcesses：當檢測故障轉移現象時執行（在決定是否進行故障轉移之前）。

• PreGracefulTakeoverProcesses：graceful master takeover時執行，在master變成read-only之前立即執行。

• PreFailoverProcesses：在orch進行恢復操作之前立即執行。在這個過程中任何的失敗（非零退出程式碼）都會終止恢復。提示：這使得有機會根據系統的某些內部狀態中止恢復。

• PostMasterFailoverProcesses：在主恢復成功結束時執行。

• PostIntermediateMasterFailoverProcesses：在中間主恢復成功結束時執行。

• PostFailoverProcesses：在任何成功的恢復結束時執行（包括以及補充到PostMasterFailoverProcesses、PostIntermediateMasterFailoverProcesses）。

• PostUnsuccessfulFailoverProcesses：在任何不成功的恢復結束時執行。

• PostGracefulTakeoverProcesses：在有計劃地、優雅地主庫切換的時候會執行，在舊主庫位於新主庫之後執行。

原文：

 

|  譯者簡介

韓傑  沃趣科技高階資料庫工程師

專注MySQL資料庫三年，精通MySQL體系結構，資料庫最佳化，trouble shooting。服務過多家銀行客戶，熟悉銀行業務及系統下資料庫不同架構使用場景。熟悉MySQL主從複製原理，及應用的各種高可用場景。