译者 韩杰 · 沃趣科技高级数据库技术专家
出品 沃趣科技
前 言
拓扑恢复
自动和手动
自动恢复（对意外故障采取措施）。 优雅地、有计划地主从切换。 手动恢复。 手动，强制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的配置。 其他方式。
自动恢复
一种可操作的场景（只有一个主库的情况就不符合）。 未处于downtime的实例。 对于属于某个集群的实例，这个集群通过配置明确启用了恢复。 对于最近尚未恢复的集群中的实例，除非确认了这些最近的恢复。 启用了全局恢复。
优雅的主库提升
使用这个来按计划、有序地替换主库。
指定一台server去提升。 orch会将master设置成read-only。 orch确保指定的服务器追上了复制。 orch将指定的server提升为新的主库。 orch将提升的server设置为可写。
PreGracefulTakeoverProcesses PostGracefulTakeoverProcesses
指定要提升的server（必须是master的直接replica）。 设置拓扑，使得master下只存在一个直接replica（在这种情况下，指定副本的身份不重要，无需提及）。
命令行：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但自动恢复被禁用或者被阻塞的情况下，使用手动恢复方式。
命令行：orchestrator-client -c recover -i dead.instance.com:3306 --debug web api：/api/recover/dead.instance.com/:3306 web界面：实例变成了黑色；点击recovery按钮。
手动，强制故障转移
强制故障转移会忽略orch自己的想法。
命令行：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都不会在小于该阻塞时间段的时间间隔启用自动恢复。
添加提升规则
某个服务器的硬件配置较差。偏向于不提升它为主库。 某个服务器位于远程的数据中心，不想要把它提升为主库。 某个服务器用作备份源，并且始终打开LVM快照。不想要把它提升为主库。 某个服务器配置不错，非常适合作为candidate。偏向于提升它为主库。 某个服务器配置一般，没有特别的偏好。
orchestrator -c register-candidate -i ${::fqdn} --promotion-rule ${promotion_rule}
提升规则有：
prefer neutral prefer_not must_not
*/2 * * * * root "/usr/bin/perl -le 'sleep rand 10' && /usr/bin/orchestrator-client -c register-candidate -i this.hostname.com --promotion-rule prefer"
停机时间（Downtime）
所有的故障/恢复已经分析了。但是，还应该考虑实例的停机状态。某个实例可以通过orchestrator-client -c begin-downtime被停机。自动恢复会跳过停机的服务器。
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主从复制原理，及应用的各种高可用场景。
相关链接
MySQL行级别并行复制能并行应用多少个binlog group？
MySQL高可用工具Orchestrator系列三：探测机制
MySQL高可用工具Orchestrator系列二：复制拓扑的发现
MySQL高可用工具Orchestrator系列一：单节点模式安装
Oracle RAC Cache Fusion系列十八：Oracle RAC Statisticsand Wait Events
更多干货，欢迎来撩~
文章转载自沃趣技术，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
