MySQL高可用工具Orchestrator如何進(jìn)行拓?fù)浠謴?fù)

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

前言

小編講一講orchestrator的拓?fù)浠謴?fù)。

拓?fù)浠謴?fù)

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

自動(dòng)和手動(dòng)

orch支持：

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

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

• 手動(dòng)恢復(fù)。

• 手動(dòng)，強(qiáng)制failover。

要求

要運(yùn)行任何類型的故障轉(zhuǎn)移，拓?fù)浔仨氈С忠韵氯我环N：

• Oracle GTID（master_auto_position=1）

• MariaDB GTID

• Pseudo GTID（偽GTID）

• Binlog Servers

什么是恢復(fù)

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

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

• 修復(fù)拓?fù)洹?/p>

• 恢復(fù)后的hooks。

注意：

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

  - 順序執(zhí)行。

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

• 拓?fù)湫迯?fù)是由orch管理的，并且是基于狀態(tài)，而不是基于配置。orch在考慮到現(xiàn)有拓?fù)?、版本?a title="服務(wù)器" target="_blank" href="http://kemok4.com/">服務(wù)器配置等因素的情況下，會(huì)力圖盡力而為。

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

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

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

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

• 從孤立的副本中提升某個(gè)副本，使得這個(gè)副本成為同級(jí)的中間主庫，然后將這個(gè)副本連接到拓?fù)洹?/p>

• 重置所有的孤立副本。

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

實(shí)際的實(shí)現(xiàn)方式很大程度上取決于拓?fù)湓O(shè)置（哪些實(shí)例設(shè)置了log-slave-updates、實(shí)例是否有延遲、是否存在復(fù)制過濾、mysql的版本等等）。你的拓?fù)浜苡锌赡苤辽僦С忠陨弦环N方式（特別是，匹配副本是一個(gè)簡單的解決方案，除非使用了復(fù)制過濾）。

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

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

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

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

• 拓?fù)涞臓顟B(tài)可能是用戶希望阻止恢復(fù)。

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

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

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

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

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

• 提升所述副本，接管它的同級(jí)。

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

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

• 調(diào)用hooks。

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

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

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

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

• 其他方式。

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

自動(dòng)恢復(fù)

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

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

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

分析機(jī)制始終運(yùn)行，并定期檢查故障/恢復(fù)情況。它將對(duì)以下進(jìn)行自動(dòng)恢復(fù)：

• 一種可操作的場(chǎng)景（只有一個(gè)主庫的情況就不符合）。

• 未處于downtime的實(shí)例。

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

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

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

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

使用這個(gè)來按計(jì)劃、有序地替換主庫。

通常，出于升級(jí)，主機(jī)維護(hù)等，會(huì)要將主庫替換成另一臺(tái)。這就是優(yōu)雅的提升主庫。

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

• 指定一臺(tái)server去提升。

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

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

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

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

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

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

• PreGracefulTakeoverProcesses

• PostGracefulTakeoverProcesses

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

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

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

• 設(shè)置拓?fù)?，使得master下只存在一個(gè)直接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)雅地提升新主庫（計(jì)劃的故障轉(zhuǎn)移），指定要提升的服務(wù)器。

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

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

• web界面：

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

手動(dòng)恢復(fù)

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

可以通過提供一個(gè)失敗的特定實(shí)例來讓orch來進(jìn)行恢復(fù)。該實(shí)例必須被識(shí)別為failure?？梢詫?duì)處于downtime的實(shí)例請(qǐng)求恢復(fù)（因?yàn)檫@是手動(dòng)恢復(fù)，能夠覆蓋掉自動(dòng)的配置）。通過以下方式恢復(fù)：

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

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

• web界面：實(shí)例變成了黑色；點(diǎn)擊recovery按鈕。

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

手動(dòng)，強(qiáng)制故障轉(zhuǎn)移

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

也許，orch不認(rèn)為某個(gè)實(shí)例fail了，或者你的應(yīng)用邏輯要求master此刻必須change，或者也許orch對(duì)fail的類型不是很確定。你希望此刻就進(jìn)行故障轉(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，命令行

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

• /web/audit-recovery

• /api/audit-recovery

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

通過以下方式進(jìn)行審計(jì)和控制：

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

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

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

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

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

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

運(yùn)行手動(dòng)恢復(fù)：

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

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

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

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

• /api/force-master-failover/:clusterHint: 緊急情況下，強(qiáng)制給定集群進(jìn)行故障轉(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

阻塞，確認(rèn)，防震蕩

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

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

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

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

請(qǐng)注意，手動(dòng)恢復(fù)（例如orchestrator-client -c recover或orchstrator-client -c force-master-failover）會(huì)忽略阻塞時(shí)間段。

添加提升規(guī)則

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

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

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

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

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

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

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

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

提升規(guī)則有：

• prefer

• neutral

• prefer_not

• must_not

提升規(guī)則默認(rèn)有效期1個(gè)小時(shí)（參數(shù)：CandidateInstanceExpireMinutes）。這符合orch的動(dòng)態(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)境。這個(gè)cron會(huì)通過puppet來更新，來表示合適的promotion_rule。某個(gè)服務(wù)器可能在某個(gè)時(shí)刻會(huì)是perfer，但5分鐘過后變成了prefer_not。整合你自己的服務(wù)發(fā)現(xiàn)方法、腳本，來提供最新的promotion_rule。

停機(jī)時(shí)間（Downtime）

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

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

請(qǐng)注意，手動(dòng)恢復(fù)（例如orchestrator-client -c recover）將覆蓋停機(jī)時(shí)間。

recovery hooks

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

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

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

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

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

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

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

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

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

以上就是MySQL高可用工具Orchestrator如何進(jìn)行拓?fù)浠謴?fù)，小編相信有部分知識(shí)點(diǎn)可能是我們?nèi)粘９ぷ鲿?huì)見到或用到的。希望你能通過這篇文章學(xué)到更多知識(shí)。更多詳情敬請(qǐng)關(guān)注億速云行業(yè)資訊頻道。