MySQL高可用工具Orchestrator如何进行拓扑恢复

本篇文章给大家分享的是有关MySQL高可用工具Orchestrator如何进行拓扑恢复，小编觉得挺实用的，因此分享给大家学习，希望大家阅读完这篇文章后可以有所收获，话不多说，跟着小编一起来看看吧。前言小编讲一讲orchestrator的拓扑恢复。orch能够从一系列故障场景中进行恢复。尤其是，它能够对主库或者中间主库的故障场景进行恢复。自动和手动orch支持：自动恢复（对意外故障采取措施）。优雅地、有计划地主从切换。手动恢复。手动，强制failover。要求要运行任何类型的故障转移，拓扑必须支持以下任一种：Oracle GTID（master_auto_position=1）MariaDB GTIDPseudo 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：PreGracefulTakeoverProcessesPostGracefulTakeoverProcesses例如，你可能想在计划的故障转移期间禁用寻呼机。高级的用法是将流量停滞在代理层。在优雅的提升主库中，必须满足以下任一种：指定要提升的server（必须是master的直接replica）。设置拓扑，使得master下只存在一个直接replica（在这种情况下，指定副本的身份不重要，无需提及）。通过以下方式调用graceful takeover：命令行：orchestrator-client -c graceful-master-takeover -alias mycluster -s designated.master.to.promote:3306web 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 –debugweb api：/api/recover/dead.instance.com/:3306web界面：实例变成了黑色；点击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.clusterweb api：/api/force-master-failover/mycluster或者/api/force-master-failover/instance.in.that.cluster/3306web，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:3306orchestrator-client -c graceful-master-takeover -i some.instance.in.somecluster:3306orchestrator-client -c graceful-master-takeover -alias someclusterorchestrator-client -c force-master-takeover -alias someclusterorchestrator-client -c ack-cluster-recoveries -alias someclusterorchestrator-client -c ack-all-recoveriesorchestrator-client -c disable-global-recoveriesorchestrator-client -c enable-global-recoveriesorchestrator-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。偏向于提升它为主库。某个服务器配置一般，没有特别的偏好。可以通过以下方式来设置偏好：preferneutralprefer_notmust_not提升规则默认有效期1个小时（参数：CandidateInstanceExpireMinutes）。这符合orch的动态特质。可以通过设置cron job的方式来指定提升规则：停机时间（Downtime）所有的故障/恢复已经分析了。但是，还应该考虑实例的停机状态。某个实例可以通过orchestrator-client -c begin-downtime被停机。自动恢复会跳过停机的服务器。实际上，停机是专门为此目的而创建的，它使DBA可以阻止自动故障转移到特定服务器。请注意，手动恢复（例如orchestrator-client -c recover）将覆盖停机时间。recovery hooksorch支持hooks——在恢复过程中调用的外部脚本。这些是通过shell调用的命令数组，尤其是bash。OnFailureDetectionProcesses：当检测故障转移现象时执行（在决定是否进行故障转移之前）。PreGracefulTakeoverProcesses：graceful master takeover时执行，在master变成read-only之前立即执行。PreFailoverProcesses：在orch进行恢复操作之前立即执行。在这个过程中任何的失败（非零退出代码）都会终止恢复。提示：这使得有机会根据系统的某些内部状态中止恢复。PostMasterFailoverProcesses：在主恢复成功结束时执行。PostIntermediateMasterFailoverProcesses：在中间主恢复成功结束时执行。PostFailoverProcesses：在任何成功的恢复结束时执行（包括以及补充到PostMasterFailoverProcesses、PostIntermediateMasterFailoverProcesses）。PostUnsuccessfulFailoverProcesses：在任何不成功的恢复结束时执行。PostGracefulTakeoverProcesses：在有计划地、优雅地主库切换的时候会执行，在旧主库位于新主库之后执行。以上就是MySQL高可用工具Orchestrator如何进行拓扑恢复，小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注开发云行业资讯频道。

相关推荐: mysql 启动错误(InnoDB: Operating system error number 13 )

service mysqld status 可以看mysqld状态 service mysqld start 可以启动mysql 出现启动错误可以查看/var/log/mysqld.log 如果错误信息如下 131124 00:00:43 mysqld sta…