本篇文章給大家分享的是有關(guān)MySQL高可用工具Orchestrator如何進行拓撲恢復(fù)，小編覺得挺實用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

瀾滄ssl適用于網(wǎng)站、小程序/APP、API接口等需要進行數(shù)據(jù)傳輸應(yīng)用場景，ssl證書未來市場廣闊！成為創(chuàng)新互聯(lián)的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：18982081108（備注：SSL證書合作）期待與您的合作！

前言

小編講一講orchestrator的拓撲恢復(fù)。

拓撲恢復(fù)

orch能夠從一系列故障場景中進行恢復(fù)。尤其是，它能夠?qū)χ鲙旎蛘咧虚g主庫的故障場景進行恢復(fù)。

自動和手動

orch支持：

• 自動恢復(fù)（對意外故障采取措施）。

• 優(yōu)雅地、有計劃地主從切換。

• 手動恢復(fù)。

• 手動，強制failover。

要求

要運行任何類型的故障轉(zhuǎn)移，拓撲必須支持以下任一種：

• Oracle GTID（master_auto_position=1）

• MariaDB GTID

• Pseudo GTID（偽GTID）

• Binlog Servers

什么是恢復(fù)

恢復(fù)基于故障檢測，并且由一系列事件組成：

• 恢復(fù)前的hooks（hook：外部的執(zhí)行過程或者腳本）。

• 修復(fù)拓撲。

• 恢復(fù)后的hooks。

注意：

• 恢復(fù)前的hooks由用戶自己配置。

  - 順序執(zhí)行。

  - 任何一個hook的失?。ǚ橇阃顺龃a）都將中止故障轉(zhuǎn)移。

• 拓撲修復(fù)是由orch管理的，并且是基于狀態(tài)，而不是基于配置。orch在考慮到現(xiàn)有拓撲、版本、服務(wù)器配置等因素的情況下，會力圖盡力而為。

• 恢復(fù)后的hooks也是由用戶自己配置。

恢復(fù)場景1：中間主庫掛掉

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

• 找到已失效的中間主服務(wù)器的同級，然后將孤立的副本移到所述同級之下。

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

• 重置所有的孤立副本。

• 結(jié)合以上部分做法。

實際的實現(xiàn)方式很大程度上取決于拓撲設(shè)置（哪些實例設(shè)置了log-slave-updates、實例是否有延遲、是否存在復(fù)制過濾、mysql的版本等等）。你的拓撲很有可能至少支持以上一種方式（特別是，匹配副本是一個簡單的解決方案，除非使用了復(fù)制過濾）。

恢復(fù)場景2：主庫掛掉

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

• 有潛在的運行中斷（停電、網(wǎng)絡(luò)），恢復(fù)要盡可能地快。

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

• 拓撲的狀態(tài)可能是用戶希望阻止恢復(fù)。

• 必須進行主服務(wù)發(fā)現(xiàn)：應(yīng)用必須能夠與新的主庫進行通訊（潛在地被告知主庫已經(jīng)更改了）。

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

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

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

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

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

• 使它的同級保持最新狀態(tài)（up to date）。

• 也許，要做一個二階段提升；用戶可能已經(jīng)標(biāo)記了要提升的特定服務(wù)器（參考register-candidate命令）。

• 調(diào)用hooks。

主服務(wù)發(fā)現(xiàn)很大程度上是需要用戶去實現(xiàn)的。常見的解決方案有：

• 基于DNS的發(fā)現(xiàn)；orch需要調(diào)用能修改DNS入口的hook。

• ZooKeeper/Consul KV/etcd/其他基于鍵值的發(fā)現(xiàn)；orch內(nèi)置了對Consul KV的支持，否則外部的hook必須更新k-v存儲系統(tǒng)。

• 基于proxy的發(fā)現(xiàn)；orch會調(diào)用外部的hook去更新proxy的配置，或者更新如上所說的Consul/Zk/etcd，這本身就會觸發(fā)更新proxy的配置。

• 其他方式。

orch嘗試作為一種通用的解決方案，因此，不限制用戶的服務(wù)發(fā)現(xiàn)方法。

自動恢復(fù)

可選。自動恢復(fù)可能會應(yīng)用于所有（"*"）集群或者特定集群。

恢復(fù)是在檢測之后進行的，并且假設(shè)恢復(fù)沒有被阻礙（請參閱下文）。

為了更好的解決方案，將不同的配置應(yīng)用于主恢復(fù)和中間主恢復(fù)。一下是與恢復(fù)相關(guān)的配置的詳細分類。

分析機制始終運行，并定期檢查故障/恢復(fù)情況。它將對以下進行自動恢復(fù)：

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

• 未處于downtime的實例。

• 對于屬于某個集群的實例，這個集群通過配置明確啟用了恢復(fù)。

• 對于最近尚未恢復(fù)的集群中的實例，除非確認了這些最近的恢復(fù)。

• 啟用了全局恢復(fù)。

優(yōu)雅的主庫提升

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

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

在優(yōu)雅的接管中：

• 指定一臺server去提升。

• orch會將master設(shè)置成read-only。

• orch確保指定的服務(wù)器追上了復(fù)制。

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

• orch將提升的server設(shè)置為可寫。

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

除了標(biāo)準(zhǔn)的hooks，orch提供了專門的hooks來運行g(shù)raceful takeover：

• PreGracefulTakeoverProcesses

• PostGracefulTakeoverProcesses

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

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

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

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

通過以下方式調(diào)用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

  優(yōu)雅地提升新主庫（計劃的故障轉(zhuǎn)移），指定要提升的服務(wù)器。

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

  優(yōu)雅地提升新主庫（計劃的故障轉(zhuǎn)移）。未指定服務(wù)器，在master只有一個直接副本時起作用。

• web界面：

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

手動恢復(fù)

當(dāng)實例被識別為fail但自動恢復(fù)被禁用或者被阻塞的情況下，使用手動恢復(fù)方式。

可以通過提供一個失敗的特定實例來讓orch來進行恢復(fù)。該實例必須被識別為failure?？梢詫μ幱赿owntime的實例請求恢復(fù)（因為這是手動恢復(fù)，能夠覆蓋掉自動的配置）。通過以下方式恢復(fù)：

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

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

• web界面：實例變成了黑色；點擊recovery按鈕。

手動恢復(fù)不受參數(shù)RecoveryPeriodBlockSeconds影響，也不受參數(shù)RecoverMasterClusterFilters和RecoverIntermediateMasterClusterFilters的影響。因此，用戶總是可以按需要來進行恢復(fù)。當(dāng)一個數(shù)據(jù)庫實例已經(jīng)有恢復(fù)在運行的時候，這個實例的同一時刻的恢復(fù)才有可能會阻塞。

手動，強制故障轉(zhuǎn)移

強制故障轉(zhuǎn)移會忽略orch自己的想法。

也許，orch不認為某個實例fail了，或者你的應(yīng)用邏輯要求master此刻必須change，或者也許orch對fail的類型不是很確定。你希望此刻就進行故障轉(zhuǎn)移，可以這么做：

• 命令行：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，命令行

通過以下方式審計恢復(fù)情況：

• /web/audit-recovery

• /api/audit-recovery

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

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

• /api/blocked-recoveries: 被阻塞的恢復(fù)。

• /api/ack-recovery/cluster/:clusterHint: 確認給定集群上的恢復(fù)。

• /api/ack-all-recoveries: 確認所有恢復(fù)。

• /api/disable-global-recoveries: 全局開關(guān)以禁用orch運行任何恢復(fù)。

• /api/enable-global-recoveries: 重新啟用恢復(fù)。

• /api/check-global-recoveries: 檢查是否啟用了全局恢復(fù)。

運行手動恢復(fù)：

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

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

• /api/graceful-master-takeover/:clusterHint/:designatedHost/:designatedPort: 優(yōu)雅地提升一個新主（計劃的故障轉(zhuǎn)移）, 指定要提升的服務(wù)器。

• /api/graceful-master-takeover/:clusterHint: 優(yōu)雅地提升一個新主（計劃的故障轉(zhuǎn)移）。未指定服務(wù)器，在master只有一個直接副本時起作用。

• /api/force-master-failover/:clusterHint: 緊急情況下，強制給定集群進行故障轉(zhuǎn)移。

一些相應(yīng)的命令行調(diào)用：

• 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通過引入阻塞時間段來避免發(fā)生震蕩（連鎖故障導(dǎo)致了連續(xù)的中斷和資源消耗）。在任何給定的集群上，除非用戶明確允許，否則orch都不會在小于該阻塞時間段的時間間隔啟用自動恢復(fù)。

阻塞時間段用參數(shù)RecoveryPeriodBlockSeconds表示。它僅用于在同一集群上的恢復(fù)。在不同集群上的并行恢復(fù)是不受影響的。

處于pending狀態(tài)中的恢復(fù)一旦超過了RecoveryPeriodBlockSeconds時間或者已經(jīng)被確認（acknowledged），則阻塞就被解除。

可以通過Web API /界面（查看audit/recovery page）或通過命令行界面（orchestrator-client -c ack-cluster-recoveries -alias somealias）確認恢復(fù)。

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

添加提升規(guī)則

在發(fā)生故障轉(zhuǎn)移時，某些服務(wù)器更適合被提升為主庫，某些服務(wù)器則不適合被提升為主庫。例如：

• 某個服務(wù)器的硬件配置較差。偏向于不提升它為主庫。

• 某個服務(wù)器位于遠程的數(shù)據(jù)中心，不想要把它提升為主庫。

• 某個服務(wù)器用作備份源，并且始終打開LVM快照。不想要把它提升為主庫。

• 某個服務(wù)器配置不錯，非常適合作為candidate。偏向于提升它為主庫。

• 某個服務(wù)器配置一般，沒有特別的偏好。

可以通過以下方式來設(shè)置偏好：

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

提升規(guī)則有：

• prefer

• neutral

• prefer_not

• must_not

提升規(guī)則默認有效期1個小時（參數(shù)：CandidateInstanceExpireMinutes）。這符合orch的動態(tài)特質(zhì)。可以通過設(shè)置cron job的方式來指定提升規(guī)則：

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

此設(shè)置來自生產(chǎn)環(huán)境。這個cron會通過puppet來更新，來表示合適的promotion_rule。某個服務(wù)器可能在某個時刻會是perfer，但5分鐘過后變成了prefer_not。整合你自己的服務(wù)發(fā)現(xiàn)方法、腳本，來提供最新的promotion_rule。

停機時間（Downtime）

所有的故障/恢復(fù)已經(jīng)分析了。但是，還應(yīng)該考慮實例的停機狀態(tài)。某個實例可以通過orchestrator-client -c begin-downtime被停機。自動恢復(fù)會跳過停機的服務(wù)器。

實際上，停機是專門為此目的而創(chuàng)建的，它使DBA可以阻止自動故障轉(zhuǎn)移到特定服務(wù)器。

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

recovery hooks

orch支持hooks——在恢復(fù)過程中調(diào)用的外部腳本。這些是通過shell調(diào)用的命令數(shù)組，尤其是bash。

• OnFailureDetectionProcesses：當(dāng)檢測故障轉(zhuǎn)移現(xiàn)象時執(zhí)行（在決定是否進行故障轉(zhuǎn)移之前）。

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

• PreFailoverProcesses：在orch進行恢復(fù)操作之前立即執(zhí)行。在這個過程中任何的失?。ǚ橇阃顺龃a）都會終止恢復(fù)。提示：這使得有機會根據(jù)系統(tǒng)的某些內(nèi)部狀態(tài)中止恢復(fù)。

• PostMasterFailoverProcesses：在主恢復(fù)成功結(jié)束時執(zhí)行。

• PostIntermediateMasterFailoverProcesses：在中間主恢復(fù)成功結(jié)束時執(zhí)行。

• PostFailoverProcesses：在任何成功的恢復(fù)結(jié)束時執(zhí)行（包括以及補充到PostMasterFailoverProcesses、PostIntermediateMasterFailoverProcesses）。

• PostUnsuccessfulFailoverProcesses：在任何不成功的恢復(fù)結(jié)束時執(zhí)行。

• PostGracefulTakeoverProcesses：在有計劃地、優(yōu)雅地主庫切換的時候會執(zhí)行，在舊主庫位于新主庫之后執(zhí)行。

以上就是MySQL高可用工具Orchestrator如何進行拓撲恢復(fù)，小編相信有部分知識點可能是我們?nèi)粘９ぷ鲿姷交蛴玫降?。希望你能通過這篇文章學(xué)到更多知識。更多詳情敬請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

本文名稱：MySQL高可用工具Orchestrator如何進行拓撲恢復(fù)
瀏覽路徑：http://chinadenli.net/article32/jsicsc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供微信小程序、建站公司、微信公眾號、標(biāo)簽優(yōu)化、手機網(wǎng)站建設(shè)、網(wǎng)站設(shè)計

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)