MySQL⾼可⽤复制管理⼯具——Orchestrator使⽤
背景
在上⼀篇「」中⼤致介绍了的功能、配置和部署，当然最详细的说明可以查阅。本⽂开始对的各⽅⾯进⾏测试和说明。
测试说明
环境介绍
服务器环境：
三台服务器
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搭建的主从感知主库宕机的等待时间过长，需要需
要稍微改下：
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=
set global slave_net_timeout=8;
（全局变量）：MySQL5.7.7之后，默认改成60秒。该参数定义了从库从主库获取数据等待的秒数，超过这个时间从库会主动退出读取，中断连接，并尝试重连。
：复制⼼跳的周期。默认是的⼀半。Master在没有数据的时候，每秒发送⼀个⼼跳包，这样 Slave 就能知道 Master 是不是还正常。
slave_net_timeout是设置在多久没收到数据后认为⽹络超时，之后 Slave 的 IO 线程会重新连接 Master 。结合这两个设置就可以避免由于⽹络问题导致的复制延误。
master_heartbeat_period 单位是秒，可以是个带上⼩数，如 10.5，最⾼精度为 1 毫秒。
重试策略为：
备库过了slave-net-timeout秒还没有收到主库来的数据，它就会开始第⼀次重试。然后每过 master-connect-retry 秒，备库会再次尝试重连主库。直到重试了 master-retry-count 次，它才会放弃重试。如果重试的过程中，连上了主库，那么它认为当前slave-net-timeout 的默认值是60秒， master-connect-retry 默认为60秒， master-retry-count 默认为86400次。也就是说，如果主库⼀分钟都没有任何数据变更发送过来，备库才会尝试重连主库。
这样，主库宕机之后，约8~10秒感知主库异常，开始切换。另外还需要注意的是，orch默认是⽤主机名来进⾏管理的，需要在mysql的配置⽂件⾥添加：report_host和
report_port参数。
数据库环境：
Orchestrator后端数据库：
在启动Orchestrator程序的时候，会⾃动在数据库⾥创建orchestrator数据库，保存orchestrator的⼀些数据信息。
Orchestrator管理的数据库：
在配置⽂件⾥配置的⼀些query参数，需要在每个被管理的⽬标库⾥有meta库来保留⼀些元信息（类似cmdb功能），⽐如⽤pt-heartbeat来验证主从延迟；⽤cluster表来保存别名、数据中⼼等。
如下⾯是测试环境的cluster表信息：
> 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 --config=/f.json http
在web上可以进⾏相关的管理，关于Web上的相关按钮的说明，下⾯会做相关说明：
1. 部分可修改的参数(点击Web上需要被修改实例的任意图标）：
说明
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. 。因为在⼀开始就已经部署了3台，通过⾥的参数进⾏通信。只要有2个节点的正常，就不会影响使⽤，如果出现2个节点的异常，则Failover会失败。2个节点异常的图如下：
图中的各个节点全部显⽰灰⾊，此时Raft算法失效，导致Orch的Failover功能失败。相对⽐MHA的Manager的单点，通过Raft算法解决了本⾝的⾼可⽤性以及解决⽹络隔离问题，特别是跨数据中⼼⽹络异常。这⾥说明下Raft，通过共识算法：
节点能够选择具有仲裁的领导者（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节点或者数据库完全为空的节点，需要从另⼀个活动节点。
的，第⼀种就是上⾯说的通过（推荐），另⼀种是通过。详细信息见。⽂档⾥详细⽐较了两种⾼可⽤性部署⽅法。两种⽅法的图如下：
到这⾥，的基本功能已经实现，包括主动Failover、修改拓扑结构以及Web上的可视化操作。
5. Web上各个按钮的功能说明
①：Home下的status：查看orch的状态：包括运⾏时间、版本、后端数据库以及各个Raft节点的状态。
②：Cluster下的dashboard：查看orch下的所有被管理的MySQL实例。
③：Cluster下的Failure analysis：查看故障分析以及包括记录的故障类型列表。
④：Cluster下的Discover：⽤来发现被管理的MySQL实例。
⑤：Audit下的Failure detection：故障检测信息，包含历史信息。
⑥：Audit下的Recovery：故障恢复信息以及故障确认。
⑦：Audit下的：是⼀个在MySQL主机上运⾏并与orchestrator通信的服务，能够向orch提供操作系统，⽂件系统和LVM信息，以及调⽤某些命令和脚本。
⑧：导航栏⾥的图标，对应左边导航栏的图标：
第1⾏：集别名的查看修改。
第2⾏：pools。
第3⾏：Compact display，紧凑展⽰。
第4⾏：Pool indicator，池指⽰器。
第5⾏：Colorize DC，每个数据中⼼⽤不同颜⾊展⽰。
第6⾏：Anonymize，匿名集中的主机名。
注意：左边导航栏⾥的图标，表⽰实例的概括：实例名、别名、故障检测和恢复等信息。
⑧：导航栏⾥的图标，表⽰是否禁⽌全局恢复。禁⽌掉的话不会进⾏Failover。
⑨：导航栏⾥的图标，表⽰是否开启刷新页⾯（默认60⼀次）。
⑩：导航栏⾥的图标，表⽰MySQL实例迁移模式。
Smart mode：⾃动选择迁移模式，让Orch⾃⼰选择迁移模式。
Classic mode：经典迁移模式，通过binlog和position进⾏迁移。
GTID mode：GTID迁移模式。
Pseudo GTID mode：伪GTID迁移模式。
到此，的基本测试和Web说明已经介绍完毕。和MHA⽐已经有很⼤的体验提升，不仅在Web进⾏部分参数的设置修改，还可以改变复制拓扑，最重要的是解决MHA Manager单点的问题。还有什么理由不替换MHA呢？:)
⼯作流程说明
实现了⾃动Failover，现在来看看⾃动Failover的⼤致流程是怎么样的。
1.
① orchestrator利⽤复制拓扑，先检查主本⾝，并观察其slaves。
②如果orchestrator本⾝连不上主，可以连上该主的从，则通过从去检测，若在从上也看不到主（IO Thread）「2次检查」，判断Master宕机。
该检测⽅法⽐较合理，当从都连不上主了，则复制肯定有出问题，故会进⾏切换。所以在⽣产中⾮常可靠。
检测发⽣故障后并不都会进⾏⾃动恢复，⽐如：禁⽌全局恢复、设置了shutdown time、上次恢复离本次恢复时间在RecoveryPeriodBlockSeconds设置的时间内、失败类型不被认为值得恢复等。检测与恢复⽆关，但始终启⽤。每次检测都会执⾏OnFailureDetectionProcesses Hooks。
：
{
"FailureDetectionPeriodBlockMinutes": 60,
}
Hooks相关参数：
{
"OnFailureDetectionProcesses": [
"echo 'Detected {failureType} on {failureCluster}. Affected replicas: {countReplicas}' >> /tmp/recovery.log"
],
}
MySQL复制相关调整：
slave_net_timeout
MASTER_CONNECT_RETRY
2.
恢复的实例需要⽀持：GTID、伪GTID、开启Binlog。如下：
{
"RecoveryPeriodBlockSeconds": 3600,
"RecoveryIgnoreHostnameFilters": [],
"RecoverMasterClusterFilters": [
"thiscluster",
"thatcluster"
],
"RecoverMasterClusterFilters": ["*"],
"RecoverIntermediateMasterClusterFilters": [
"*"
],
}
{
"ApplyMySQLPromotionAfterMasterFailover": true,
"PreventCrossDataCenterMasterFailover": false,
"FailMasterPromotionIfSQLThreadNotUpToDate": true,
"MasterFailoverLostInstancesDowntimeMinutes": 10,
"DetachLostReplicasAfterMasterFailover": true,
}
Hooks：mysql连接工具
{
"PreGracefulTakeoverProcesses": [
"echo 'Planned takeover about to take place on {failureCluster}. Master will switch to read_only' >> /tmp/recovery.log"
],
"PreFailoverProcesses": [
"echo 'Will recover from {failureType} on {failureCluster}' >> /tmp/recovery.log"
],
"PostFailoverProcesses": [
"echo '(for all types) Recovered from {failureType} on {failureCluster}. Failed: {failedHost}:{failedPort}; Successor: {successorHost}:{successorPort}' >> /tmp/recovery.log"
],
"PostUnsuccessfulFailoverProcesses": [],
"PostMasterFailoverProcesses": [
"echo 'Recovered from {failureType} on {failureCluster}. Failed: {failedHost}: {failedPort}; Promoted: {successorHost}:{successorPort}' >> /tmp/recovery.log"
],
"PostIntermediateMasterFailoverProcesses": [],
"PostGracefulTakeoverProcesses": [
"echo 'Planned takeover complete' >> /tmp/recovery.log"
],
}
具体的参数含义请参考「」。在执⾏故障检测和恢复的时候都可以执⾏外部⾃定义脚本（hooks），来配合使⽤（VIP、Proxy、DNS）。
可以恢复中继主库（DeadIntermediateMaster）和主库：
中继主库：恢复会其同级的节点进⾏做主从。匹配副本按照哪些实例具有log-slave-updates、实例是否延迟、它们是否具有复制过滤器、哪些版本的MySQL等等
主库：恢复可以指定提升特定的从库「提升规则」（register-candidate），提升的从库不⼀定是最新
的，⽽是选择最合适的，设置完提升规则之后，有效期为1个⼩时。
提升规则选项有：
prefer --⽐较喜欢
neutral --中⽴（默认）
prefer_not --⽐较不喜欢
must_not --拒绝
恢复⽀持的类型有：、、、，恢复的时候也可以执⾏相应的。具体的恢复流程可以看的说明。关于可以。
补充：每次恢复除了⾃动的Failover之外，都需要配合执⾏⾃⼰定义的Hooks的脚本来处理外部的⼀些操作：VIP修改、DNS修改、Proxy修改等等。所以这么多Hooks的参数该如何设置呢？哪个参数需要执⾏，哪个参数不需要执⾏，以及Hooks的执⾏顺序是怎么样的？虽然⽂章⾥有介绍，但为了更好的进⾏说明，下⾯进⾏各种恢复场景执⾏Hooks的顺序：
"OnFailureDetectionProcesses": [ #检测故障时执⾏
"echo '② Detected {failureType} on {failureCluster}. Affected replicas: {countSlaves}' >> /tmp/recovery.log"
],
"PreGracefulTakeoverProcesses": [ #在主变为只读之前⽴即执⾏
"echo '① Planned takeover about to take place on {failureCluster}. Master will switch to read_only' >> /tmp/recovery.log"
],
"PreFailoverProcesses": [ #在执⾏恢复操作之前⽴即执⾏
"echo '③ Will recover from {failureType} on {failureCluster}' >> /tmp/recovery.log"
],
"PostMasterFailoverProcesses": [ #在主恢复成功结束时执⾏
"echo '④ Recovered from {failureType} on {failureCluster}. Failed: {failedHost}:{failedPort}; Promote
d: {successorHost}:{successorPort}' >> /tmp/recovery.log"
],
"PostFailoverProcesses": [ #在任何成功恢复结束时执⾏
"echo '⑤ (for all types) Recovered from {failureType} on {failureCluster}. Failed: {failedHost}:{failedPort}; Successor: {successorHost}:{successorPort}' >> /tmp/recovery.log"
],
"PostUnsuccessfulFailoverProcesses": [ #在任何不成功的恢复结束时执⾏
"echo '⑧ >> /tmp/recovery.log'"
],
"PostIntermediateMasterFailoverProcesses": [ #在成功的中间主恢复结束时执⾏
"echo '⑥ Recovered from {failureType} on {failureCluster}. Failed: {failedHost}:{failedPort}; Successor: {successorHost}:{successorPort}' >> /tmp/recovery.log"
],
"PostGracefulTakeoverProcesses": [ #在旧主位于新晋升的主之后执⾏
"echo '⑦ Planned takeover complete' >> /tmp/recovery.log"
],
View Code
主库宕机，⾃动Failover
② Detected UnreachableMaster on test1:3307. Affected replicas: 2
② Detected DeadMaster on test1:3307. Affected replicas: 2
③ Will recover from DeadMaster on test1:3307
④ Recovered from DeadMaster on test1:3307. Failed: test1:3307; Promoted: test2:3307
⑤ (for all types) Recovered from DeadMaster on test1:3307. Failed: test1:3307; Successor: test2:3307
优雅的主从切换：test2:3307优雅的切换到test1:3307，切换之后需要⼿动执⾏start slave
orchestrator-client -c graceful-master-takeover -a test2:3307 -d test1:3307
① Planned takeover about to take place on test2:3307. Master will switch to read_only
② Detected DeadMaster on test2:3307. Affected replicas: 1
③ Will recover from DeadMaster on test2:3307
④ Recovered from DeadMaster on test2:3307. Failed: test2:3307; Promoted: test1:3307
⑤ (for all types) Recovered from DeadMaster on test2:3307. Failed: test2:3307; Successor: test1:3307
⑦ Planned takeover complete
⼿动恢复，当从库进⼊停机或则维护模式，此时主库宕机，不会⾃动Failover，需要⼿动执⾏恢复，指定死掉的主实例：
orchestrator-client -c recover -i test1:3307
② Detected UnreachableMaster on test1:3307. Affected replicas: 2
② Detected DeadMaster on test1:3307. Affected replicas: 2
③ Will recover from DeadMaster on test1:3307
④ Recovered from DeadMaster on test1:3307. Failed: test1:3307; Promoted: test2:3307
⑤ (for all types) Recovered from DeadMaster on test1:3307. Failed: test1:3307; Successor: test2:3307
⼿动强制恢复，不管任何情况，都进⾏恢复：
orchestrator-client -c force-master-failover -i test2:3307
② Detected DeadMaster on test2:3307. Affected replicas: 2
③ Will recover from DeadMaster on test2:3307
② Detected AllMasterSlavesNotReplicating on test2:3307. Affected replicas: 2
④ Recovered from DeadMaster on test2:3307. Failed: test2:3307; Promoted: test1:3307
⑤ (for all types) Recovered from DeadMaster on test2:3307. Failed: test2:3307; Successor: test1:3307
其中上⾯的情况下，⑥和⑧都没执⾏。因为⑥是执⾏中间主库时候执⾏的，没有中间主库（级联复制）可以不⽤设置。⑧是恢复失败的时候执⾏的，上⾯恢复没有出现失败，可以定义⼀些告警提醒。
⽣产环境上部署
在⽣产上部署，可以参考。
1. ⾸先需要确认本⾝⾼可⽤的后端数据库是⽤单个MySQL，MySQL复制还是本⾝的Raft。
2. 运⾏发现服务（web、orchestrator-client）
orchestrator-client -c discover -i this.hostname
3. 确定提升规则（某些服务器更适合被提升）
orchestrator -c register-candidate -i ${::fqdn} --promotion-rule ${promotion_rule}
4. 如果服务器出现问题，将在Web界⾯上的问题下拉列表中显⽰。使⽤则不会在问题列表⾥显⽰，并
且也不会进⾏恢复，处于维护模式。
orchestrator -c begin-downtime -i ${::fqdn} --duration=5m --owner=cron --reason=continuous_downtime"
也可以⽤API：
curl -s "my.orchestrator.service:80/api/begin-downtime/my.hostname/3306/wallace/experimenting+failover/45m"
5. ，如果MySQL没有开启GTID，则可以开启伪GTID实现类似GTID的功能。
6. 保存，元数据⼤部分通过参数的query来获取，⽐如在⾃的表cluster⾥获取集的别名(DetectClusterAliasQuery)、数据中⼼(DetectDataCenterQuery)、域名(DetectClusterDomainQuery)等，以及复制的延迟（pt-heartbeat）、是否半同步(DetectSemiSyncEnforcedQuery)。以及可以通过正则匹配：DataCenterPattern、PhysicalEnvironmentPattern等。
7. 可以给实例打。
命令⾏、API的使⽤
不仅有Web界⾯来进⾏查看和管理，还可以通过命令⾏（）和API（curl）来执⾏更多的管理命令，现在来说明⼏个⽐较常⽤⽅法。
通过help来看下有哪些可以执⾏的命令：./orchestrator-client --help，命令的说明可以看。
Usage: orchestrator-client -c <command> []
Example: orchestrator-client -c which-master -plica
Options:
-h, --help
print this help
-c <command>, --command <command>
indicate the operation to perform (see listing below)
-a <alias>, --alias <alias>
cluster alias
-o <owner>, --owner <owner>
name of owner for downtime/maintenance commands
-r <reason>, --reason <reason>
reason for downtime/maintenance operation
-u <duration>, --duration <duration>
duration for downtime/maintenance operations
-R <promotion rule>, --promotion-rule <promotion rule>
rule for'register-candidate' command
-U <orchestrator_api>, --api <orchestrator_api>
override $orchestrator_api environemtn variable,
indicate where the client should connect to.
-
P <api path>, --path <api path>
With '-c api', indicate the specific API path you wish to call
-b <username:password>, --auth <username:password>
Specify when orchestrator uses basic HTTP auth.
-q <query>, --query <query>
Indicate query for'restart-replica-statements' command
-l <pool name>, --pool <pool name>
pool name for pool related commands
-H <hostname> -h <hostname>
indicate host for resolve and raft operations
help Show available commands
which-api Output the HTTP API to be used
api Invoke any API request; provide --path argument
async-discover Lookup an instance, investigate it asynchronously. Useful for bulk loads
discover Lookup an instance, investigate it
forget Forget about an instance's existence
forget-cluster Forget about a cluster
topology Show an ascii-graph of a replication topology, given a member of that topology
topology-tabulated Show an ascii-graph of a replication topology, given a member of that topology, in tabulated format
clusters List all clusters known to orchestrator
clusters-alias List all clusters known to orchestrator
search Search for instances matching given substring
instance"|"which-instance Output the fully-qualified hostname:port representation of the given instance, or error if unknown
which-master Output the fully-qualified hostname:port representation of a given instance's master
which-replicas Output the fully-qualified hostname:port list of replicas of a given instance
which-broken-replicas Output the fully-qualified hostname:port list of broken replicas of a given instance
which-cluster-instances Output the list of instances participating in same cluster as given instance
which-cluster Output the name of the cluster an instance belongs to, or error if unknown to orchestrator
which-cluster-master Output the name of a writable master in given cluster
all-clusters-masters List of writeable masters, one per cluster
all-instances The complete list of known instances
which-cluster-osc-replicas Output a list of replicas in a cluster, that could serve as a pt-online-schema-change operation control replicas
which-cluster-osc-running-replicas Output a list of healthy, replicating replicas in a cluster, that could serve as a pt-online-schema-change operation control replicas
downtimed List all downtimed instances
dominant-dc Name the data center where most masters are found
submit-masters-to-kv-stores Submit a cluster's master, or all clusters' masters to KV stores
relocate Relocate a replica beneath another instance
relocate-replicas Relocates all or part of the replicas of a given instance under another
instance
match Matches a replica beneath another (destination) instance using Pseudo-GTID
match-up Transport the replica one level up the hierarchy, making it child of its grandparent, using Pseudo-GTID
match-up-replicas Matches replicas of the given instance one level up the topology, making them siblings of given instance, using Pseudo-GTID
move-up Move a replica one level up the topology
move-below Moves a replica beneath its sibling. Both replicas must be actively replicating from same master.
move-equivalent Moves a replica beneath another server, based on previously recorded "equivalence coordinates"
move-up-replicas Moves replicas of the given instance one level up the topology
make-co-master Create a master-master replication. Given instance is a replica which replicates directly from a master.
take-master Turn an instance into a master of its own master; essentially switch the two.
move-gtid Move a replica beneath another instance via GTID
move-replicas-gtid Moves all replicas of a given instance under another (destination) instance using GTID
repoint Make the given instance replicate from another instance without changing the binglog coordinates. Use with care
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论