MySQL高可用工具Orchestrator如何進行拓撲恢復

本篇文章給大家分享的是有關MySQL高可用工具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高可用工具Orchestrator如何進行拓撲恢復，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。