测试说明
环境介绍
服务器环境：
代码语言：javascript复制三台服务器
1：MySQL实例（3306是orch的后端数据库，3307是MySQL主从架构「开启GTID」）
Master ：192.168.163.131:3307
Slave ：192.168.163.132:3307
Slave ：192.168.163.133:3307
2：hosts（etc/hosts）：
192.168.163.131 test1
192.168.163.132 test2
192.168.163.133 test3这里需要注意的是，orch 检测主库宕机依赖从库的 IO 线程（本身连不上主库后，还会通过从库再去检测主库是否异常），所以默认 change 搭建的主从感知主库宕机的等待时间过长，需要需要稍微改下：
代码语言：javascript复制change master to master_host='192.168.163.131',master_port=3307,master_user='rep',master_password='rep',master_auto_position=1,MASTER_HEARTBEAT_PERIOD=2,MASTER_CONNECT_RETRY=1, MASTER_RETRY_COUNT=86400;set global slave_net_timeout=8;slave_net_timeout（全局变量）：MySQL5.7.7之后，默认改成60秒。该参数定义了从库从主库获取数据等待的秒数，超过这个时间从库会主动退出读取，中断连接，并尝试重连。master_heartbeat_period：复制心跳的周期。默认是 slave_net_timeout 的一半。Master 在没有数据的时候，每 master_heartbeat_period 秒发送一个心跳包，这样 Slave 就能知道 Master 是不是还正常。
slave_net_timeout 是设置在多久没收到数据后认为网络超时，之后 Slave 的 IO 线程会重新连接 Master 。结合这两个设置就可以避免由于网络问题导致的复制延误。master_heartbeat_period 单位是秒，可以是个带上小数，如 10.5，最高精度为 1 毫秒。
代码语言：javascript复制重试策略为：
备库过了slave-net-timeout秒还没有收到主库来的数据，它就会开始第一次重试。然后每过 master-connect-retry 秒，备库会再次尝试重连主库。直到重试了 master-retry-count 次，它才会放弃重试。如果重试的过程中，连上了主库，那么它认为当前主库是好的，又会开始 slave-net-timeout 秒的等待。
slave-net-timeout 的默认值是 60 秒， master-connect-retry 默认为 60 秒， master-retry-count 默认为 86400 次。也就是说，如果主库一分钟都没有任何数据变更发送过来，备库才会尝试重连主库。这样，主库宕机之后，约 8~10 秒感知主库异常，Orchestrator 开始切换。另外还需要注意的是，orch 默认是用主机名来进行管理的，需要在 mysql 的配置文件里添加：report_host 和 report_port 参数。
数据库环境：
代码语言：javascript复制Orchestrator后端数据库：
在启动Orchestrator程序的时候，会自动在数据库里创建orchestrator数据库，保存orchestrator的一些数据信息。
Orchestrator管理的数据库：
在配置文件里配置的一些query参数，需要在每个被管理的目标库里有meta库来保留一些元信息（类似cmdb功能），比如用pt-heartbeat来验证主从延迟；用cluster表来保存别名、数据中心等。如下面是测试环境的 cluster 表信息：
代码语言：javascript复制> CREATE TABLE `cluster` (
`anchor` tinyint(4) NOT NULL,
`cluster_name` varchar(128) CHARACTER SET ascii NOT NULL DEFAULT '',
`cluster_domain` varchar(128) CHARACTER SET ascii NOT NULL DEFAULT '',
`data_center` varchar(128) NOT NULL,
PRIMARY KEY (`anchor`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
>select * from cluster;
-------- -------------- ---------------- -------------
| anchor | cluster_name | cluster_domain | data_center |
-------- -------------- ---------------- -------------
| 1 | test | CaoCao | BJ |
-------- -------------- ---------------- ------------- 测试说明
开启 Orchestrator 进程：
代码语言：javascript复制./orchestrator --config=/etc/orchestrator.conf.json http在浏览器里输入三台主机的任意主机的 IP 加端口（http://192.168.163.131:3000）进入到 Web 管理界面，在 Clusters 导航的 Discover 里输入任意一台被管理 MySQL 实例的信息。添加完成之后，Web 界面效果：
在 web 上可以进行相关的管理，关于 Web 上的相关按钮的说明，下面会做相关说明：
1. 部分可修改的参数 (点击 Web 上需要被修改实例的任意图标）：
说明
代码语言：javascript复制Instance Alias ：实例别名
Last seen : 最后检测时间
Self coordinates ：自身的binlog位点信息
Num replicas ：有几个从库
Server ID ： MySQL server_id
Server UUID ： MySQL UUID
Version ： 版本
Read only ： 是否只读
Has binary logs ：是否开启binlog
Binlog format ：binlog 模式
Logs slave updates ：是否开启log_slave_updates
GTID supported ：是否支持GTID
GTID based replication ：是否是基于GTID的复制
GTID mode ：复制是否开启了GTID
Executed GTID set ：复制中执行过的GTID列表
Uptime ：启动时间
Allow TLS ：是否开启TLS
Cluster ：集群别名
Audit ：审计实例
Agent ：Agent实例说明：上面图中，后面有按钮的都是可以在 Web 上进行修改的功能，如：是否只读，是否开启 GTID 的复制等。其中 Begin Downtime 会将实例标记为已停用，此时如果发生 Failover，该实例不会参与。
2. 任意改变主从的拓扑结构：可以直接在图上拖动变更复制，会自动恢复拓扑关系：
3. 主库挂了之后自动 Failover，如：
图中显示，当主挂掉之后，拓扑结构里自动剔除该主节点，选择一个最合适的从库提升成主库，并修复复制拓扑。在 Failover 过程当中，可以查看 / tmp/recovery.log 文件（配置文件里定死），里面包含了在 Failover 过程中 Hooks 执行的外部脚本，类似 MHA 的 master_ip_failover_script 参数。可以通过外部脚本进行相应的如：VIP 切换、Proxy 修改、DNS 修改、中间件修改、LVS 修改等等，具体的执行脚本可以根据自己的实际情况编写。
4. Orchestrator 高可用。因为在一开始就已经部署了 3 台，通过配置文件里的 Raft 参数进行通信。只要有 2 个节点的 Orchestrator 正常，就不会影响使用，如果出现 2 个节点的 Orchestrator 异常，则 Failover 会失败。2 个节点异常的图如下：
图中的各个节点全部显示灰色，此时 Raft 算法失效，导致 Orch 的 Failover 功能失败。相对比 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。
关于 Raft 更多的信息见：https://github.com/github/orchestrator/blob/master/docs/raft.md
Orchestrator 的高可用有 2 种方式，第一种就是上面说的通过 Raft（推荐），另一种是通过后端数据库的同步。详细信息见文档。文档里详细比较了两种高可用性部署方法。两种方法的图如下：
到这里，Orchestrator 的基本功能已经实现，包括主动 Failover、修改拓扑结构以及 Web 上的可视化操作。
5. Web 上各个按钮的功能说明
①：Home 下的 status：查看 orch 的状态：包括运行时间、版本、后端数据库以及各个 Raft 节点的状态。
②：Cluster 下的 dashboard：查看 orch 下的所有被管理的 MySQL 实例。
③：Cluster 下的 Failure analysis：查看故障分析以及包括记录的故障类型列表。
④：Cluster 下的 Discover：用来发现被管理的 MySQL 实例。
⑤：Audit 下的 Failure detection：故障检测信息，包含历史信息。
⑥：Audit 下的 Recovery：故障恢复信息以及故障确认。
⑦：Audit 下的 Agent：是一个在 MySQL 主机上运行并与 orchestrator 通信的服务，能够向 orch 提供操作系统，文件系统和 LVM 信息，以及调用某些命令和脚本。
⑧：导航栏里的
图标，对应左边导航栏的图标：
第 1 行：集群别名的查看修改。
第 2 行：pools。
第 3 行：Compact display，紧凑展示。
第 5 行：Colorize DC，每个数据中心用不同颜色展示。
第 6 行：Anonymize，匿名集群中的主机名。
注意：左边导航栏里的
图标，表示实例的概括：实例名、别名、故障检测和恢复等信息。
⑧：导航栏里的
图标，表示是否禁止全局恢复。禁止掉的话不会进行 Failover。
⑨：导航栏里的
图标，表示是否开启刷新页面（默认 60 一次）。
⑩：导航栏里的
图标，表示 MySQL 实例迁移模式。
代码语言：javascript复制Smart mode：自动选择迁移模式，让Orch自己选择迁移模式。
Classic mode：经典迁移模式，通过binlog和position进行迁移。
GTID mode：GTID迁移模式。
Pseudo GTID mode：伪GTID迁移模式。到此，Orchestrator 的基本测试和 Web 说明已经介绍完毕。和 MHA 比已经有很大的体验提升，不仅在 Web 进行部分参数的设置修改，还可以改变复制拓扑，最重要的是解决 MHA Manager 单点的问题。还有什么理由不替换 MHA 呢？
