一文看懂MySQL复制拓扑管理工具Orchestrator--高可用机制

波波说运维 07-27 151

前言：

眼前小伙伴们对“mysql拓扑图”都比较注意，各位老铁们都需要剖析一些“mysql拓扑图”的相关内容。那么小编也在网络上网罗了一些有关“mysql拓扑图””的相关内容，希望你们能喜欢，小伙伴们快快来了解一下吧！

概述

Orchestrator是一款开源的MySQL复制拓扑管理工具，采用go语言编写，支持MySQL主从复制拓扑关系的调整、支持MySQL主库故障自动切换、手动主从切换等功能。

Orchestrator后台依赖于MySQL或者SQLite存储元数据，能够提供Web界面展示MySQL集群的拓扑关系及实例状态，通过Web界面可更改MySQL实例的部分配置信息，同时也提供命令行和api接口，以便更加灵活的自动化运维管理。

相比于MHA，Orchestrator更加偏重于复制拓扑关系的管理，能够实现MySQL任一复制拓扑关系的调整，并在此基础上，实现MySQL高可用，另外Orchestrator自身可以部署多个节点，通过raft分布式一致性协议，保证自身的高可用。

今天主要介绍一下orachestrator的高可用机制。

一、Orchestrator 高可用

Orchestrator多节点部署，通过raft一致性协议实现自身高可用。

相对比MHA的Manager的单点，ORCHESTRATOR通过Raft算法解决了本身的高可用性以及解决网络隔离问题，特别是跨数据中心网络异常。这里说明下Raft，通过共识算法：

Orchestrator节点能够选择具有仲裁的领导者（leader）。如有3个orch节点，其中一个可以成为leader（3节点仲裁大小为2，5节点仲裁大小为3）。只允许leader进行修改，每个MySQL拓扑服务器将由三个不同的orchestrator节点独立访问，在正常情况下，三个节点将看到或多或少相同的拓扑图，但他们每个都会独立分析写入其自己的专用后端数据库服务器：

① 所有更改都必须通过leader。

② 在启用raft模式上禁止使用orchestrator客户端。

③ 在启用raft模式上使用orchestrator-client，orchestrator-client可以安装在没有orchestrator上的服务器。

④ 单个orchestrator节点的故障不会影响orchestrator的可用性。在3节点设置上，最多一个服务器可能会失败。在5节点设置上，2个节点可能会失败。

⑤ Orchestrator节点异常关闭，然后再启动。它将重新加入Raft组，并接收遗漏的任何事件,只要有足够的Raft记录。

⑥ 要加入比日志保留允许的更长/更远的orchestrator节点或者数据库完全为空的节点，需要从另一个活动节点克隆后端DB。

二、高可用实验

例如在如下3台机器部署Orchestrator节点：

172.26.151.69172.26.151.94172.26.151.95

1、在每个节点上修改orchestrator.conf.json配置文件：

注意：RaftBind配置为当前节点ip

2、在每个节点上启动orchestrator服务：