Orchestrator部署配置

orchestrator部署：

orchestrator-3.0.11.tar.gz                ----服务包
orchestrator-cli-3.0.11-1.x86_64.rpm    ----二进制命令

所有主机节点安装mysql5.7数据库

首先实现mysql的主从关系
orchestrator=192.168.41.128
master=192.168.41.129
slave1=192.168.41.130
slave2=192.168.41.131

修改hosts记录
vim /etc/hosts(所有主机添加)

192.168.41.128    orchestrator.example.com
192.168.41.129    master.example.com 
192.168.41.130    slave1.example.com 
192.168.41.131    slave2.example.com

orchestrator.example.com主机修改

修改mysql5.7初始密码
vim /etc/my.cnf
[mysqld]
skip-grant-tables        ----添加一行

shell>mysql
mysql>use mysql
mysql>update user set authentication_string=PASSWORD('123') where user='root';
mysql>exit

重启mysql数据库
vim /etc/my.cnf 
[mysqld]

#skip-grant-tables        ----注释掉

新修改密码即刻过期，需要重新设置密码
mysql> set PASSWORD='123456'；

[root@orchestrator ~]# mysql -uroot -p123456
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 93
Server version: 5.7.22 MySQL Community Server (GPL)

Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>create database orchestrator;                                        -----创建orchestrator软件使用数据库
mysql> create user orchestrator@'localhost' identified by '123';        -----创建授权用户
mysql> create user orchestrator@'orchestrator.example.com' identified by '123';
mysql> GRANT ALL ON orchestrator.* TO orchestrator@'localhost' ;            ----授权
mysql> GRANT ALL ON orchestrator.* TO orchestrator@'orchestrator.example.com';
mysql>exit

安装orchestrator软件

rpm -ivh orchestrator-cli-3.0.11-1.x86_64.rpm            ----获取二进制命令

tar xf orchestrator-3.0.11.tar.gz -C /usr/local 

[root@orchestrator ~]# cp /usr/local/orchestrator-3.0.11/conf/orchestrator-sample.conf.json /etc/orchestrator.conf.json 
[root@orchestrator ~]# vim /etc/orchestrator.conf.json
  2   "Debug": true,                ----开启测试信息
  3   "EnableSyslog": false,        ----关闭日志（测试环境之后可以关闭测试信息，开启系统日志）
  4   "ListenAddress": ":3000",        ----监听地址与端口
  5   "MySQLTopologyUser": "orchestrator",        ----后台数据库连接用户（在主库数据库中创建）
  6   "MySQLTopologyPassword": "123456",        ----后台用户密码
 13   "MySQLOrchestratorHost": "192.168.41.128",        ----软件监听主机地址
 14   "MySQLOrchestratorPort": 3306,                    ----端口
 15   "MySQLOrchestratorDatabase": "orchestrator",        ----所属库
 16   "MySQLOrchestratorUser": "orchestrator",            ----登录用户
 17   "MySQLOrchestratorPassword": "123",                ----密码
 
 
 master.example.com主机 设置：
 vim /etc/my.cnf
 [mysqld]
 server_id=1
 log-bin=binlog
 
 创建同步账号：
 [root@master ~]# 
[root@master ~]# mysql -uroot -p123456
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 27
Server version: 5.7.22-log MySQL Community Server (GPL)

Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> create user slave@'192.168.41.%' identified by '123';            ----创建主从同步用户
mysql> GRANT ALL ON *.* TO slave@'192.168.41.130' ;
mysql> create user orchestrator@'192.168.41.128' identified by '123456';        ----创建orchestrator软件授权用户
mysql> grant all on *.* to orchestrator@'192.168.41.128';

导出数据库
mysqldump -uroot -p123456 --all-databases --master-data=2 > /root/mysql_all.sql

scp /root@/mysql_all.sql [email protected]:/root

slave1.example.com 主机配置
vim /etc/my.cnf
[mysqld]
server_id=2

mysql -uroot -p123456 < /root/mysql_all.sql

mysql -uroot -p123456
mysql>change master to \
     >MASTER_HOST='192.168.41.129',
     >MASTER_USER='slave',
     >MASTER_PASSWORD='123',
     >MASTER_LOG_FILE='binlog_00001',
     >MASTER_LOG_POS=772;
     
mysql> start slave;
mysql> show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.41.129
                  Master_User: slave
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: binlog.000001
          Read_Master_Log_Pos: 2461
               Relay_Log_File: slave1-relay-bin.000004
                Relay_Log_Pos: 317
        Relay_Master_Log_File: binlog.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
            
            
实现主从同步之后，在orchestrator主机上启动服务，并且发现后台数据库

[root@orchestrator ~]# orchestrator http &

[root@orchestrator ~]# netstat -tnpl |grep :300
tcp6       0      0 :::3000                 :::*                    LISTEN      6084/orchestrator 
命令行发现：

orchestrator -c discover -i 192.168.41.129
orchestrator -c discover -i 192.168.41.130
orchestrator -c clusters        ----查看集群

或者图形界面发现

    Cluster ---> Discover ----> host:port
    
    
    登录测试：
    http://192.168.41.128:3000
 
[root@orchestrator orchestrator-3.0.11]# orchestrator -c help
Available commands (-c):
Smart relocation:
    relocate                                Relocate a replica beneath another instance
    relocate-below                          Synonym to 'relocate', will be deprecated
    relocate-replicas                       Relocates all or part of the replicas of a given instance under another instance
    regroup-replicas                        Given an instance, pick one of its replicas and make it local master of its siblings
Classic file:pos relocation:
    move-up                                 Move a replica one level up the topology
    move-up-replicas                        Moves replicas of the given instance 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"
    repoint                                 Make the given instance replicate from another instance without changing the binglog coordinates. Use with care
    repoint-replicas                        Repoint all replicas of given instance to replicate back from the instance. Use with care
    take-siblings                           Turn all siblings of a replica into its sub-replicas.
    take-master                             Turn an instance into a master of its own master; essentially switch the two.
    make-co-master                          Create a master-master replication. Given instance is a replica which replicates directly from a master.
    get-candidate-replica                   Information command suggesting the most up-to-date replica of a given instance that is good for promotion
Binlog server relocation:
    regroup-replicas-bls                    Regroup Binlog Server replicas of a given instance
GTID relocation:
    move-gtid                               Move a replica beneath another instance.
    move-replicas-gtid                      Moves all replicas of a given instance under another (destination) instance using GTID
    regroup-replicas-gtid                   Given an instance, pick one of its replica and make it local master of its siblings, using GTID.
Pseudo-GTID relocation:
    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
    rematch                                 Reconnect a replica onto its master, via PSeudo-GTID.
    match-replicas                          Matches all replicas of a given instance under another (destination) instance 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
    regroup-replicas-pgtid                  Given an instance, pick one of its replica and make it local master of its siblings, using Pseudo-GTID.
Replication, general:
    enable-gtid                             If possible, turn on GTID replication
    disable-gtid                            Turn off GTID replication, back to file:pos replication
    reset-master-gtid-remove-own-uuid       Reset master on instance, remove GTID entries generated by instance
    skip-query                              Skip a single statement on a replica; either when running with GTID or without
    stop-slave                              Issue a STOP SLAVE on an instance
    start-slave                             Issue a START SLAVE on an instance
    restart-slave                           STOP and START SLAVE on an instance
    reset-slave                             Issues a RESET SLAVE command; use with care
    detach-replica                          Stops replication and modifies binlog position into an impossible, yet reversible, value.
    reattach-replica                        Undo a detach-replica operation
    detach-replica-master-host              Stops replication and modifies Master_Host into an impossible, yet reversible, value.
    reattach-replica-master-host            Undo a detach-replica-master-host operation
    master-pos-wait                         Wait until replica reaches given replication coordinates (--binlog=file:pos)
    enable-semi-sync-master                 Enable semi-sync replication (master-side)
    disable-semi-sync-master                Disable semi-sync replication (master-side)
    enable-semi-sync-replica                Enable semi-sync replication (replica-side)
    disable-semi-sync-replica               Disable semi-sync replication (replica-side)
    restart-slave-statements                Get a list of statements to execute to stop then restore replica to same execution state. Provide --statement for injected statement
Instance:
    set-read-only                           Turn an instance read-only, via SET GLOBAL read_only := 1
    set-writeable                           Turn an instance writeable, via SET GLOBAL read_only := 0
Binary logs:
    flush-binary-logs                       Flush binary logs on an instance
    purge-binary-logs                       Purge binary logs of an instance
    last-pseudo-gtid                        Find latest Pseudo-GTID entry in instance's binary logs
    last-executed-relay-entry               Find coordinates of last executed relay log entry
    correlate-relaylog-pos                  Given an instance (-i) and relaylog coordinates (--binlog=file:pos), find the correlated coordinates in another instance's relay logs (-d)
    find-binlog-entry                       Get binlog file:pos of entry given by --pattern (exact full match, not a regular expression) in a given instance
    correlate-binlog-pos                    Given an instance (-i) and binlog coordinates (--binlog=file:pos), find the correlated coordinates in another instance (-d)
Pools:
    submit-pool-instances                   Submit a pool name with a list of instances in that pool
    cluster-pool-instances                  List all pools and their associated instances
    which-heuristic-cluster-pool-instances  List instances of a given cluster which are in either any pool or in a specific pool
Information:
    find                                    Find instances whose hostname matches given regex pattern
    search                                  Search instances by name, version, version comment, port
    clusters                                List all clusters known to orchestrator
    clusters-alias                          List all clusters known to orchestrator
    all-clusters-masters                    List of writeable masters, one per 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
    all-instances                           The complete list of known instances
    which-instance                          Output the fully-qualified hostname:port representation of the given instance, or error if unknown
    which-cluster                           Output the name of the cluster an instance belongs to, or error if unknown to orchestrator
    which-cluster-domain                    Output the domain name of the cluster an instance belongs to, or error if unknown to orchestrator
    which-heuristic-domain-instance         Returns the instance associated as the cluster's writer with a cluster's domain name.
    which-cluster-master                    Output the name of the master in a given cluster
    which-cluster-instances                 Output the list of instances participating in same cluster as given instance
    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-gh-ost-replicas           Output a list of replicas in a cluster, that could serve as a gh-ost working server
    which-master                            Output the fully-qualified hostname:port representation of a given instance's master
    which-downtimed-instances               List instances currently downtimed, potentially filtered by cluster
    which-replicas                          Output the fully-qualified hostname:port list of replicas of a given instance
    which-lost-in-recovery                  List instances marked as downtimed for being lost in a recovery process
    instance-status                         Output short status on a given instance
    get-cluster-heuristic-lag               For a given cluster (indicated by an instance or alias), output a heuristic "representative" lag of that cluster
Key-value:
    submit-masters-to-kv-stores             Submit master of a specific cluster, or all masters of all clusters to key-value stores
Instance management:
    discover                                Lookup an instance, investigate it
    forget                                  Forget about an instance's existence
    begin-maintenance                       Request a maintenance lock on an instance
    end-maintenance                         Remove maintenance lock from an instance
    in-maintenance                          Check whether instance is under maintenance
    begin-downtime                          Mark an instance as downtimed
    end-downtime                            Indicate an instance is no longer downtimed
Recovery:
    recover                                 Do auto-recovery given a dead instance
    recover-lite                            Do auto-recovery given a dead instance. Orchestrator chooses the best course of actionwithout executing external processes
    force-master-failover                   Forcibly discard master and initiate a failover, even if orchestrator doesn't see a problem. This command lets orchestrator choose the replacement master
    force-master-takeover                   Forcibly discard master and promote another (direct child) instance instead, even if everything is running well
    graceful-master-takeover                Gracefully promote a new master. Either indicate identity of new master via '-d designated.instance.com' or setup replication tree to have a single direct replica to the master.
    replication-analysis                    Request an analysis of potential crash incidents in all known topologies
    ack-all-recoveries                      Acknowledge all recoveries; this unblocks pending future recoveries
    ack-cluster-recoveries                  Acknowledge recoveries for a given cluster; this unblocks pending future recoveries
    ack-instance-recoveries                 Acknowledge recoveries for a given instance; this unblocks pending future recoveries
Instance, meta:
    register-candidate                      Indicate that a specific instance is a preferred candidate for master promotion
    register-hostname-unresolve             Assigns the given instance a virtual (aka "unresolved") name
    deregister-hostname-unresolve           Explicitly deregister/dosassociate a hostname with an "unresolved" name
    set-heuristic-domain-instance           Associate domain name of given cluster with what seems to be the writer master for that cluster
Meta:
    snapshot-topologies                     Take a snapshot of existing topologies.
    continuous                              Enter continuous mode, and actively poll for instances, diagnose problems, do maintenance
    active-nodes                            List currently active orchestrator nodes
    access-token                            Get a HTTP access token
    resolve                                 Resolve given hostname
    reset-hostname-resolve-cache            Clear the hostname resolve cache
    dump-config                             Print out configuration in JSON format
    show-resolve-hosts                      Show the content of the hostname_resolve table. Generally used for debugging
    show-unresolve-hosts                    Show the content of the hostname_unresolve table. Generally used for debugging
Meta, internal:
    redeploy-internal-db                    Force internal schema migration to current backend structure
Internal:
    internal-suggest-promoted-replacement   Internal only, used to test promotion logic in CI
Agent:
    custom-command                          Execute a custom command on the agent as defined in the agent conf
:
    disable-global-recoveries               Disallow orchestrator from performing recoveries globally
    enable-global-recoveries                Allow orchestrator to perform recoveries globally
    check-global-recoveries                 Show the global recovery configuration
    bulk-instances                          Return a list of sorted instance names known to orchestrator
    bulk-promotion-rules                    Return a list of promotion rules known to orchestrator
Run 'orchestrator help ' for detailed help on given command, e.g. 'orchestrator help relocate'

Usage for most commands:
    orchestrator -c [-i [,]* ] [-d ] [--verbose|--debug]

Debug （bool），设置调试模式（类似于--debug选项）
ListenAddress （字符串），要监听的主机和端口（默认":3000"）。您可以通过限制连接到本地计算机"127.0.0.1:3000"
MySQLTopologyUser （字符串），复制拓扑服务器（主服务器和从服务器）的凭据
MySQLTopologyPassword （字符串），复制拓扑服务器（主服务器和从服务器）的凭据
MySQLTopologyCredentialsConfigFile（字符串），作为替代提供MySQLTopologyUser，MySQLTopologyPassword在文件的名称my.cnf样格式，其中凭证存储。
MySQLTopologyMaxPoolConnections （int），任何拓扑实例上的最大并发连接数
MySQLOrchestratorHost （字符串），后端MySQL服务器的主机名
MySQLOrchestratorPort （uint），后端MySQL服务器的端口
MySQLOrchestratorDatabase （字符串），后端MySQL服务器模式的名称
MySQLOrchestratorUser （字符串），后端MySQL服务器的凭据
MySQLOrchestratorPassword （字符串），后端MySQL服务器的凭据
MySQLOrchestratorCredentialsConfigFile （字符串），作为替代提供MySQLOrchestratorUser，MySQLOrchestratorPassword在文件的名称my.cnf样格式，其中凭证存储。
MySQLConnectTimeoutSeconds （int），连接中止前的秒数（驱动程序端）
MySQLHostnameResolveMethod（字符串），解决如何到达MySQL实例的方法。这比HostnameResolveMethod对于每个实例具有VIP的主机上的多个实例等复杂设置更加强大且非常理想。默认为none但可以设置为@@report_host
DefaultInstancePort（int），如果未在命令行上指定端口（默认值为此默认值3306）
SkipOrchestratorDatabaseUpdate （bool），如果为false，orchestrator将尝试创建和更新后端数据库中的所有表; 如果为true，则跳过此选项。跳过命令行调用并启用http或偶尔的调用，或者只是在升级后才有意义
SlaveLagQuery （字符串），自定义查询以检查slave lg（例如心跳表）。如果没有提供，Seconds_Behind_Master则使用slave 。
SlaveStartPostWaitMilliseconds （int），START SLAVE重新读取实例之前等待的时间（给奴隶机会连接到主人）
DiscoverByShowSlaveHosts （布尔），SHOW SLAVE HOSTS之前尝试过SHOW PROCESSLIST
InstancePollSeconds （uint），实例读取之间的秒数
UnseenInstanceForgetHours （uint），忘记看不见的实例的小时数
DiscoveryPollSeconds （uint），自动/连续发现实例在轮询之间的休眠时间
InstanceBulkOperationsWaitTimeoutSeconds （uint），在执行批量（多个实例）操作时等待单个实例的时间
ActiveNodeExpireSeconds （uint），在尝试接管活动节点之前等待活动节点发送keepalive的最长时间。
HostnameResolveMethod    （字符串），主机名解析方法的类型（"none"或者"cname"）
ExpiryHostnameResolvesMinutes    （int），主机名解析到期之前的分钟数（主机名解析缓存最多此分钟数）
RejectHostnameResolvePattern （字符串），解析主机名的Regexp模式，不接受（不缓存，不写入db）。这样做是为了避免因网络故障而存储错误的结果。
ReasonableReplicationLagSeconds （int），高于此值被认为是一个问题
VerifyReplicationFilters （bool），在批准拓扑重构之前包括复制过滤器检查（例如，orchestrator不允许在过滤后的非过滤器下放置非过滤器）
MaintenanceOwner （字符串），（默认）维护所有者的名称，如果没有提供则使用
ReasonableMaintenanceReplicationLagSeconds （int），在此值之上移动并向下移动被阻止
MaintenanceExpireMinutes （int），维护标志被认为是陈旧并被清除的分钟数
MaintenancePurgeDays （int），从数据库中清除维护条目的天数
AuditLogFile （字符串），审计操作的日志文件名。空的时候禁用。
AuditPageSize （int），审计页面中的条目数
RemoveTextFromHostnameDisplay（字符串），用于去除集群/集群页面上的主机名的文本。保存像素（例如mycompany.com）
ReadOnly    （bool）当"true"没有允许写操作（例如停止奴隶，重建奴隶，发现）时
AuthenticationMethod （字符串），身份验证的类型。空（无认证，默认）"basic"，"multi"或"proxy"。见安全部分。
AuthUserHeader （字符串），HTTP头的名称包含验证用户时AuthenticationMethod是"proxy"
PowerAuthUsers （字符串列表），用户被视为超级用户（允许操纵拓扑）; 适用于"proxy" AuthenticationMethod。
HTTPAuthUser （字符串），HTTP基本身份验证的用户名（空白禁用身份验证）
HTTPAuthPassword （字符串），HTTP基本身份验证的密码
ClusterNameToAlias （字符串到字符串映射），将正则表达式匹配的集群名称与人类友好别名之间的映射。然后，在Clusters菜单和Clusters Dashboard页面中显示人性化的别名。
DetectClusterAliasQuery（字符串），可选查询（在拓扑实例上执行），返回集群的别名。查询将仅在集群主机上执行（但直到拓扑的主机被重新调用后，它才可以在其他/所有从机上执行）。如果提供，必须返回一行，一列。这取代了ClusterNameToAlias。
DataCenterPattern （字符串），具有一个组的Regexp模式，从主机名中提取数据中心名称
PhysicalEnvironmentPattern （字符串），具有一个组的正则表达式模式，从主机名中提取物理环境信息（例如，数据中心和prod / dev env的组合）
DenyAutoPromotionHostnamePattern （字符串），Orchestrator不会自动提升名称匹配patterb的主机（通过-c recovery;例如，避免使用dev专用计算机）
ServeAgentsHttp （bool），orchestrator应该接受代理注册并提供与代理相关的请求（请参阅代理商）
AgentsUseSSL (bool), Whentrue`chechestrator将使用SSL侦听代理端口以及通过SSL连接到代理（请参阅SSL和TLS）
AgentsUseMutualTLS (bool), Whentrue`使用相互TLS服务器与代理通信
`AgentSSLSkipVerify（bool），当为代理使用SSL时，我们是否应该忽略SSL认证错误
AgentSSLPrivateKeyFile (string), Name of Agent SSL private key file, applies only whenAgentsUseSSL =true`
AgentSSLCertFile (string), Name of Agent SSL certification file, applies only whenAgentsUseSSL =true`
AgentSSLCAFile (string), Name of the Agent Certificate Authority file, applies only whenAgentsUseSSL =true`
`AgentSSLValidOUs（[] string），使用相互TLS与代理进行通信时的有效组织单位
`UseSSL（bool），在服务器Web端口上使用SSL（参见SSL和TLS）
UseMutualTLS (bool), Whentrue`对服务器的Web和API连接使用相互TLS
`SSLSkipVerify（bool），使用SSL时，我们应该忽略SSL认证错误
SSLPrivateKeyFile (string), Name of SSL private key file, applies only whenUseSSL =true`
SSLCertFile (string), Name of SSL certification file, applies only whenUseSSL =true`
SSLCAFile (string), Name of the Certificate Authority file, applies only whenUseSSL =true`
`SSLValidOUs（[] string），使用相互TLS时的有效组织单位
StatusEndpoint (string), Override the status endpoint. Defaults to/ API / status`
`StatusSimpleHealth（bool），如果为true，则调用状态端点将使用简化的运行状况检查
`StatusOUVerify（bool），如果为true，尝试在Mutual TLS打开时验证OU。默认为false
HttpTimeoutSeconds （int），HTTP GET请求超时（连接到orchestrator-agent时）
AgentPollMinutes （uint），orchestrator联系代理以进行简要状态更新的时间间隔
UnseenAgentForgetHours （uint），忘记代理人之后没有联系的时间
StaleSeedFailMinutes （uint），没有状态更新的种子被认为失败的时间
PseudoGTIDPattern （字符串），在二进制日志中查找的模式，用于创建唯一条目（伪GTID）。为空时，禁用基于伪GTID的重构。
PseudoGTIDMonotonicHint （字符串），Pseudo-GTID条目中的可选子字符串，表示Pseudo-GTID条目预计会单调递增
DetectPseudoGTIDQuery （字符串），可选查询，用于权威地确定是否在实例上启用了伪gtid
BinlogEventsChunkSize（int），SHOW BINLOG|RELAYLOG EVENTS LIMIT ?,X语句的块大小（X）。较小意味着更少的锁定和更多的工作要做。建议：10000由于锁定问题，保持或低于此值。
BufferBinlogEvents （bool），我们应该使用缓冲读取SHOW BINLOG|RELAYLOG EVENTS- 更快地释放数据库锁（推荐）。
RecoveryPeriodBlockSeconds （int），实例的恢复保持“活动”的时间，以避免在smae实例上进行并发恢复以及扑动
RecoveryIgnoreHostnameFilters （[] string），恢复分析将完全忽略与给定模式匹配的主机
RecoverMasterClusterFilters（[] string），只对匹配这些正则表达式模式的集群进行主恢复（当然.*模式匹配所有内容）
RecoverIntermediateMasterClusterFilters（[] string），只对匹配这些正则表达式模式的集群进行中间主恢复（当然.*模式匹配所有内容）
请参阅master分支中的示例配置文件。

最小配置使用
大多数上述配置变量具有良好的默认值，或者可能不适用于所有用例。这是您必须拥有和可能想拥有的东西的友好细分。

证书：必须
"MySQLTopologyUser": "orchestrator",
"MySQLTopologyPassword": "orch_topology_password",
或者，使用：

"MySQLTopologyCredentialsConfigFile": "/path/to/.my-orchestrator.cnf",
/path/to/.my-orchestrator.cnf 格式预计为：

[client]
user=orchestrator
password=orch_topology_password
此外，后端数据库的必备凭据：

"MySQLOrchestratorHost": "backend.orchestrator.db.mycompany.com",
"MySQLOrchestratorPort": 3306,
"MySQLOrchestratorDatabase": "orchestrator",
"MySQLOrchestratorUser": "orchestrator_server",
"MySQLOrchestratorPassword": "thepassword",
或者，对于用户和密码，使用：

"MySQLOrchestratorCredentialsConfigFile": "/path/to/.my-orchestrator-srv.cnf",
安全：希望拥有
见安全部分。

更好的信息：希望拥有
使用心跳机制（与pt-heartbeat一样），并配置：

  "SlaveLagQuery": "select slave_lag_seconds from heartbeat_table",
如果在同一主机上有多个实例，则必须使用report_host和配置MySQL服务器report_port并添加：

  "DiscoverByShowSlaveHosts": true,
除了后端数据库表之外，还要对日志文件进行审计操作：

  "AuditLogFile": "/var/log/orchestrator-audit.log",
如果您的主机名遵循严格的约定，并且您能够从FQDN检测数据中心，或者您能够从FQDN检测环境设置（prod？dev？），请使用（和修改）：

  "DataCenterPattern": "[.]([^.]+)[.][^.]+[.]mycompany[.]com",
  "PhysicalEnvironmentPattern": "[.][^.]+[.]([^.]+)[.]mycompany[.]com",
orchestrator通过其主机的主机名和端口识别集群。但是，您也可以为群集分配别名。这使得一些CLI commadns更简单，一些网页更好。如果可以通过SQL查询别名，请配置（和修改）：

  "DetectClusterAliasQuery": "SELECT SUBSTRING_INDEX(@@hostname, '-', 1)",
大多数服务器的FQDN都可能以.mycomany.com:3306。这会在网页上浪费很多像素。您可以通过以下方式省略这些：

  "RemoveTextFromHostnameDisplay": ".mycompany.com:3306",
伪GTID：想拥有
好吧，我建议你想要伪GTID。如果您同意，那么您必须注入Pseudo GTISD查询，并且必须配置（和修改）：

  "PseudoGTIDPattern": "drop view if exists .*?`_pseudo_gtid_hint__",
参见伪GTID讨论。

最好还可以通过SQL查询Pseudo-GTID存在。为此，配置（和修改）：

  "DetectPseudoGTIDQuery": "select count(*) as pseudo_gtid_exists from meta.pseudo_gtid_status where anchor = 1 and time_generated > now() - interval 2 day",
当你在它的时候，让你的Pseudo-GTID条目单调增加，并提供一些提示，例如（修改值）：

   "PseudoGTIDMonotonicHint": "asc:",
拓扑恢复：如果您想拥有自己的数据库，希望拥有
当启用PseudoGTID时，orchestrator可以从死中间主站（重新连接孤立的从站到拓扑）或死主机（自动升级最佳候选从站）进行自动恢复。

默认情况下，这是禁用的。您可以指定要为其启用两者的集群模式。当然，.*匹配一切：

"RecoverMasterClusterFilters": [
      "myoltp"
],
"RecoverIntermediateMasterClusterFilters": [
      "myoltp",
      "myolap",
],
orchestrator恢复拓扑结构，但作为通用工具，它无法理解MySQL拓扑管理的外部上下文，例如DNS，代理等。它允许挂钩在执行操作之前和执行操作之后在故障转移检测时调用。您可能需要配置以下内容：

"OnFailureDetectionProcesses": [
  "echo 'Detected {failureType} on {failureCluster}. Affected slaves: {countSlaves}'
],
"PreFailoverProcesses": [
  "echo 'Will recover from {failureType} on {failureCluster}'
],
"PostFailoverProcesses": [
  "echo 'Recovered from {failureType} on {failureCluster}. Failed: {failedHost}:{failedPort}; Successor: {successorHost}:{successorPort}'
],
"PostUnsuccessfulFailoverProcesses": [
  "echo 'There was a problem recovering from {failureType} on {failureCluster}. Failed: {failedHost}:{failedPort}'
],
"PostMasterFailoverProcesses": [
  "echo 'Recovered from {failureType} on {failureCluster}. Failed: {failedHost}:{failedPort}; Promoted: {successorHost}:{successorPort}'
],
"PostIntermediateMasterFailoverProcesses": [
  "echo 'Recovered from {failureType} on {failureCluster}. Failed: {failedHost}:{failedPort}; Successor: {successorHost}:{successorPort}'
]
伪GTID
伪GTID是将唯一条目注入二进制日志的方法，这样它们可用于在没有直接连接的情况下匹配/同步从站，或者主站损坏/死亡的从站。

Orchestrator在适用的情况下利用伪GTID，并允许从属的复杂重新匹配，包括对从属设备的半自动故障转移以及其兄弟姐妹作为其从属设备的移动。

要启用Pseudo GTID，您需要：

经常在二进制日志中注入唯一的条目
配置orchestrator以识别此类条目
Optionaly提示协调器此类条目按升序排列
在二进制日志中注入条目是发布语句的问题。根据您是否使用基于语句复制或基于行的复制，这样的说法可能是ISNERT，CREATE或其他。请参考以下博客文章： 伪GTID， 伪GTID，基于行的复制， 使用伪GTID重构复制拓扑以 获取更多详细信息。

以下是GTID的可注射注入和随附的协调器配置的三个示例：

伪GTID通过创建或替换视图
 如果不存在，则创建数据库  ; 
drop event如果存在meta。create_pseudo_gtid_view_event ; 
分隔符;; 
如果不存在，则创建事件元。create_pseudo_gtid_view_event 上时间表每隔10秒后开始播放CURRENT_TIMESTAMP 上完成保存
  使能
  不要开始集 @pseudo_gtid：= UUID（）;
      设置 @_create_statement：= concat（'创建或替换视图meta.pseudo_gtid_view作为选择' ''

  
  
  
    
      ，@pseudo_gtid，' \' as pseudo_gtid_unique_val from dual '）; 
      PREPARE st FROM @_create_statement; 
      执行st; 
      DEALLOCATE PREPARE st; 
    结束
;; 

分隔符; set global event_scheduler：= 1 ;

 
和匹配的配置条目：

{
     “ PseudoGTIDPattern ”：“创建或替换。*？查看`pseudo_gtid_view` AS select ” 
}
上述方法的优点是它不仅显示在二进制/中继日志中（这是单一要求），而且还通过SELECT查询提供信息。

上述缺点是元数据锁定。在非常繁忙的服务器上，该CREATE/REPLACE语句可以保存表缓存或其他锁。我们在奴隶身上看到过这种失速复制。

如果存在，则通过DROP VIEW伪GTID
 如果不存在，则创建数据库  ; 
使用meta; 
drop event如果存在，则为create_pseudo_gtid_event; 
delimiter $$ 
create event如果不存在则
  create_pseudo_gtid_event 按计划每隔5秒启动current_timestamp on completion保存
  enable 
  do begin set @pseudo_gtid_hint：= uuid（）;
      设置 @_create_statement：= concat（' drop '，' view if if exists`meta``_pseudo_gtid_ '，' hint__

  
  
    
      '，@pseudo_gtid_hint， ' ` '）; 
      PREPARE st FROM @_create_statement; 
      执行st; 
      DEALLOCATE PREPARE st; 
    结束
$$

分隔符; set global event_scheduler： = 1 ;

 
和匹配的配置条目：

{
   “ PseudoGTIDPattern ”：“ drop view如果存在。*？`_ _pseudo_gtid_hint__ ” 
}
以上尝试删除实际上不存在的视图。该声明在现实中没有任何作用，但通过复制流传播。与前面的示例相反，它不会使用过多的锁定。

这种方法的缺点是它只显示在二进制日志中，并且没有数据可见性（不能 SELECT看到伪GTID状态）。

伪GTID通过DROP VIEW如果存在并插入...在重复键更新
第三种方法通过实际调用两个语句来添加前一个方法。一个（DDL）将在二进制/中继日志中可见。另一个（DML）将影响数据。

 如果不存在，则创建数据库  ; 
使用meta; create table if not exists pseudo_gtid_status（
  anchor                       int unsigned not null，
  originating_mysql_host       varchar（128）charset ascii not null，
  originating_mysql_port       int unsigned not null，
  originating_server_id        int unsigned not null，
  time_generated               timestamp not null default current_timestamp

   ，
  pseudo_gtid_uri              varchar（255）charset ascii not null，
  pseudo_gtid_hint             varchar（255）charset ascii not null，
   PRIMARY KEY（anchor）
）; 

drop event如果存在，则为create_pseudo_gtid_event; 
delimiter $$ 
create event如果不存在则
  create_pseudo_gtid_event 按计划每隔5秒启动current_timestamp on completion保存
  enable 
  do begin 
      DECLARE lock_result INT ;
  
  
    
      DECLARE CONTINUE HANDLER，用于SQLEXCEPTION BEGIN END; 设置 @pseudo_gtid_hint：= uuid（）;
      设置 @_create_statement：= concat（' drop '，' view if if exists`meta``_pseudo_gtid_ '，' hint __ '，@ false_gtid_hint，' ` '）; 
      PREPARE st FROM @_create_statement; 
      执行st; 
      DEALLOCATE PREPARE st; / *！50600       SET innodb_lock_wait_timeout = 1; * / SET

      

      

      
      lock_result = GET_LOCK（' pseudo_gtid_status '，0）; 
      IF lock_result =  1然后
         设置 @serverid：= @@ server_id;
        设置 @hostname：= @@ hostname;
        设置 @port：= @@ port;
        设置 @now：= now（）;
        设置 @rand：= floor（rand（）*（1  <<  32））;
        设置 @pseudo_gtid：= concat（' pseudo-gtid：// '， @ hostname， '：'，@ port， ' / '，@ serverid， ' / '， date（@now）， ' / '， time（@now）， ' / '， @rand）;
        插入 pseudo_gtid_status（
             anchor，
             originating_mysql_host，
             originating_mysql_port，
             originating_server_id，
             time_generated，
             pseudo_gtid_uri，
             pseudo_gtid_hint
          ）值（1，@hostname，@port，@serverid，@now，@pseudo_gtid，@pseudo_gtid_hint）
             上重复键更新 
                originating_mysql_host = 值（originating_mysql_host），
                originating_mysql_port = 值（originating_mysql_port），
                originating_server_id = 值（originating_server_id），
                time_generated = values（time_generated），
                 pseudo_gtid_uri = values（pseudo_gtid_uri），
                 pseudo_gtid_hint =
                  values（pseudo_gtid_hint）
        ; SET lock_result = RELEASE_LOCK（' pseudo_gtid_status '）; 
      万一; 
    结束
$$ 
分隔符; set global event_scheduler：= 1 ;
        

 
和匹配的配置条目：

{
   “ PseudoGTIDPattern ”：“ drop view if if exists。*？`_pseudo_gtid_hint __ ”，
   “ DetectPseudoGTIDQuery ”：“ select meta（*）as pseudo_gtid_exists from meta.pseudo_gtid_status where anchor = 1 and time_generated> now（） -  interval 2 day ” 
}
请注意，我们引入了DetectPseudoGTIDQuery配置，它允许orchestrator实际检查最近是否注入了Pseudo-GTID。

在根据上述程序您可能会注意到显著代码开销（DECLATE CONTINUE HANDLER，GET_LOCK，...）。这种代码开销使得一种安全机制可以避免INSERT在服务器遇到某些锁定问题时堆积语句。回想一下，事件调度程序重复发出代码，即使先前的执行尚未终止。此保护层将支持在每次执行时注入Pseudo-GTID，但一次只允许一个INSERT语句。这来自经验，相信它。

通过DROP VIEW升序伪GTID如果存在并插入...在重复键更新
与上面类似，但是伪GTID条目以递增的词汇顺序注入。这允许协调器在主机的二进制日志上搜索给定的伪GTID条目时执行进一步的优化。

 如果不存在，则创建数据库  ; 
使用meta; create table if not exists pseudo_gtid_status（
  anchor                       int unsigned not null，
  originating_mysql_host       varchar（128）charset ascii not null，
  originating_mysql_port       int unsigned not null，
  originating_server_id        int unsigned not null，
  time_generated               timestamp not null default current_timestamp

   ，
  pseudo_gtid_uri              varchar（255）charset ascii not null，
  pseudo_gtid_hint             varchar（255）charset ascii not null，
   PRIMARY KEY（anchor）
）; 

drop event如果存在，则为create_pseudo_gtid_event; 
delimiter $$ 
create event如果不存在则
  create_pseudo_gtid_event 按计划每隔5秒启动current_timestamp on completion保存
  enable 
  do begin 
      DECLARE lock_result INT ;
  
  
    
      DECLARE CONTINUE HANDLER，用于SQLEXCEPTION BEGIN END; set @connection_id：= connection_id（）;
      设置 @now：= now（）;
      设置 @rand：= floor（rand（）*（1 << 32））;
      set @pseudo_gtid_hint：= concat_ws（'：'，lpad（hex（unix_timestamp（@now）），8，' 0 '），lpad（hex（@connection_id），16，' 0 '），lpad（hex（@rand） ），8

        ，' 0 '））;
      设置 @_create_statement：= concat（' drop '，' view if if exists`meta``_pseudo_gtid_ '，' hint__asc：'，@ false_gtid_hint，' ` '）; 
      PREPARE st FROM @_create_statement; 
      执行st; 
      DEALLOCATE PREPARE st; / *！50600       SET innodb_lock_wait_timeout = 1; * / SET lock_result = GET_LOCK（' pseudo_gtid_status '，0）;

      IF lock_result =  1然后
        设置 @serverid：= @@ server_id;
        设置 @hostname：= @@ hostname;
        设置 @port：= @@ port;
        设置 @pseudo_gtid：= concat（' pseudo-gtid：// '，@ hostname，'：'，@ port，' / '，@ serverid，' / '，date（@now），' / '，time（@now），' / '，@ =）;
        在重复密钥更新 
                originating_mysql_host = values（originating_mysql_host）上插入 pseudo_gtid_status（
             anchor，
             originating_mysql_host，
             originating_mysql_port，
             originating_server_id，
             time_generated，
             pseudo_gtid_uri，
             pseudo_gtid_hint 
          ）值（1，@ hostname，@ port，@ serverid，@ now，@pseudo_gtid，@pseudo_gtid_hint
             ） ，
                originating_mysql_port
             =  values（originating_mysql_port），
                originating_server_id =  values（originating_server_id），
                time_generated =  values（time_generated），
                 pseudo_gtid_uri =  values（pseudo_gtid_uri），
                 pseudo_gtid_hint =  values（pseudo_gtid_hint）
        ; SET lock_result = RELEASE_LOCK（' pseudo_gtid_status '）; 
      万一; 
    结束
$$ 
分隔符; 设置全局event_scheduler：= 1
        

 ;
和匹配的配置条目：

{
   “ PseudoGTIDPattern ”：“ drop view if if exists。*？`_pseudo_gtid_hint__ ”，
   “ DetectPseudoGTIDQuery ”：“ select meta（*）as pseudo_gtid_exists from meta.pseudo_gtid_status where anchor = 1 and time_generated> now（） -  interval 2 day ”，
   “ PseudoGTIDMonotonicHint “：” asc：“，
}
请注意，该@pseudo_gtid_hint值由UTC时间戳（以十六进制编码）后跟其他值（connection_id，random）组成。这使得条目按词汇顺序增加。

所述PseudoGTIDMonotonicHint配置变量告诉协调器，如果它发现的值（asc:在伪GTID条目文本），则它是被信任的，所述条目中注入作为monotonicly的一部分增加伪GTID条目。这将对主机的二进制日志进行搜索优化。

orchestrator的作者使用最后一种方法注入。

使用伪GTID
如果PseudoGTIDPattern配置变量非空，orchestrator将仅启用Pseudo-GTID模式，但只能在运行时验证其正确性。

如果您的模式不正确（因此，协调器无法在二进制日志中找到模式），您将无法通过Pseudo-GTID移动拓扑中的从属，并且您只能在尝试时找到它。

如果使用orchestrator管理多个拓扑，则需要对所有人使用相同的Pseudo GTID注入方法，因为只有一个PseudoGTIDPattern值。

要通过Pseudo-GTID机制移动从属设备，请单击导航栏上的经典模式绿色按钮并将其转换为 伪GTID模式。拖动从属更改的规则：任何其SQL线程与IO线程最新的对象（由win-glass图标描述）都有资格进行拖动。此时，可以将这样的从属设备放在可访问的兄弟或祖先（包括其自己的主/父）上。

拓扑恢复
orchestrator检测故障情况，并在这种情况下可选择恢复。

此时恢复需要GTID，伪GTID或Binlog服务器。

失败/恢复方案
DeadMaster
DeadMasterAndSlaves
DeadMasterAndSomeSlaves
DeadMasterWithoutSlaves
UnreachableMaster
AllMasterSlavesNotReplicating
AllMasterSlavesNotReplicatingOrDead
DeadCoMaster
DeadCoMasterAndSomeSlaves
DeadIntermediateMaster
DeadIntermediateMasterWithSingleSlaveFailingToConnect
DeadIntermediateMasterWithSingleSlave
DeadIntermediateMasterAndSomeSlaves
AllIntermediateMasterSlavesFailingToConnectOrDead
AllIntermediateMasterSlavesNotReplicating
UnreachableIntermediateMaster
BinlogServerFailingToConnectToMaster
简要地看一些例子，这里是协调者如何得出失败的结论：

DeadMaster：
掌握MySQL访问失败
所有主人的奴隶都没有复制
这使得潜在的恢复过程成为可能

DeadMasterAndSomeSlaves：
掌握MySQL访问失败
它的一些奴隶也无法到达
其余的奴隶都没有复制
这使得潜在的恢复过程成为可能

UnreachableMaster：
掌握MySQL访问失败
但它复制了奴隶。
这不会带来恢复过程。但是，为了改进分析，协调器会发出紧急重新读取的奴隶，以确定他们是否真的对主人感到满意（在这种情况下，由于网络故障，orchestrator可能无法看到它）或实际上正在花时间弄清楚他们没有复制。

DeadIntermediateMaster：
无法访问中间主站（带从站的从站）
它的所有从属都没有复制
这使得潜在的恢复过程成为可能

目前的故障/恢复方案是什么？
上面的一些分析导致恢复过程（取决于配置），而有些则没有。您可以通过以下方式查看最新分析：

命令行： orchestrator -c replication-analysis
Web API： /api/replication-analysis
网页：/web/clusters-analysis/页面（Clusters- > Failure analysis）。这提供了一个不完整的问题列表，只突出了可操作的问题。
请注意，恢复与单个从机的死亡无关，因为它意味着不需要对拓扑进行必要的更改。

什么在复苏？
一个“简单”的恢复案例是一个DeadIntermediateMaster。它的从属是孤立的，但是当使用GTID或Pseudo-GTID时，它们仍然可以重新连接到拓扑。我们可能会选择：

找到死去的中级主人的兄弟姐妹，并在所述兄弟姐妹下面移动孤儿
从孤立的奴隶中推广奴隶，使其成为其兄弟姐妹的中间主人，然后将提升的奴隶连接到拓扑
重新安置所有孤儿奴隶
结合以上部分
确切的实现在很大程度上取决于拓扑设置（哪些实例具有log-slave-updates？实例是否滞后？它们是否具有复制过滤器？哪些版本的MySQL？等等）。非常（很可能）您的拓扑将至少支持上述其中一个（特别是，匹配从站是一个简单的解决方案，除非复制过滤器到位）。

一个“非常简单”的恢复案例就是一个案例DeadMaster。orchestrator将尝试：

找到最先进的奴隶
推广它，奴役其兄弟姐妹
让兄弟姐妹保持最新状态
检查是否有预定义的“候选奴隶”
通过以前选择的奴隶来促进这一点
并且...呼吁挂钩（进一步阅读）
上述成功取决于有多少奴隶log-slave-updates，以及未配置的奴隶是否比其他奴隶更新或更新。当您的所有实例都log-slave-updates出现问题时，大大简化了问题。当然，所有其他限制都适用（版本，binlog格式，复制过滤器） - 并且orchestrator将尝试找到一个好的解决方案。

这种DeadMaster情况并不简单，因为您的应用程序必须知道主服务器已经死亡而另一个应用程序取而代之。这严格在协调者的范围之外; 但是orchestrator支持挂钩：在恢复之前/之后调用的外部进程列表。这些将做任何需要的更改：删除“只读”标志，更改DNS记录等。它在你身上。

钩子将在下面详细描述。

与所有操作一样，主要步骤和决策都经过审核（请参阅参考资料/api/audit），当然也会记录下来。topology_recovery 如果您希望以自己的方式获取信息，后端将保留恢复操作的状态。

手动恢复
您可以选择通过提供失败的特定实例来要求协调器恢复故障。必须将此实例识别为具有故障情形（参见上文）。可以请求恢复已停用的实例（因为这是手动恢复，它会覆盖自动假设）。恢复途径：

命令行： orchestrator -c recover -i dead.instance.com:3306 --debug
Web API： /api/recover/dead.instance.com/:3306
Web：实例为黑色; 单击Recover按钮
手动恢复不会阻塞RecoveryPeriodBlockSeconds（请参阅下一节中的更多内容）。他们也覆盖 RecoverMasterClusterFilters和RecoverIntermediateMasterClusterFilters。手动恢复只会阻止手动恢复操作的同一实例上已经运行（且不完整）的恢复。

自动恢复
默认情况下，关闭可以对特定群集应用自动恢复。为了获得更高的分辨率，不同的配置适用于主恢复和中间主恢复。下面是与恢复相关的配置的详细分类。

分析机制始终运行，并定期检查故障/恢复方案。它将自动恢复：

一种可行的场景（duh）
对于未停顿的实例
对于属于通过配置明确启用恢复的群集的实例
对于最近未恢复的群集中的实例，除非确认此类最近的恢复
阻止，确认，反扑
制作最后一个子弹以避免恢复过程的抖动。每个恢复过程都经过审核和记录，并且两个恢复不能在同一个实例上运行，除非经过最少量的时间（表示为RecoveryPeriodBlockSeconds）。

此外，在短于（这当然是比前一个更强的条件）的间隔中，不会对同一群集执行两个自动恢复RecoveryPeriodBlockSeconds。要检测的第一个恢复获胜，而其他恢复则被阻止。

没有什么可以阻止在不同群集上运行的并发恢复。

待处理的恢复一旦RecoveryPeriodBlockSeconds通过或已确认此类恢复就会被解除阻止。可以通过Web API /接口（请参阅审计/恢复页面）或通过命令行界面（请参阅-c ack-instance-recoveries或-c ack-cluster-recoveries）确认恢复。

细心的读者可能会混淆一点作为对于两个不同的命令的原因：ack-instance-recoveries和ack-cluster-recoveries，或用于与“相同的群集”上“相同的实例”的不同的讨论。恢复可以不被承认。虽然它尚未被承认且仍然是最近的，但不会发生自动恢复。但是，如果已经过了足够的时间，那么即使作为协调者，恢复仍然是未被确认的，这是完全有效的继续恢复新的故障情景。因此，可以在同一实例或同一群集上具有多个未确认的恢复。在将来，我们可能会改变行为（基于配置），从而放宽对相同集群的恢复的约束。因此，我们为“相同实例”与“相同群集”>保持单独的代码和分析

与所有操作一样，恢复过程会对实例进行“维护”锁定，并且无法重构已在维护中的实例。此外，它将在实例上放置一个恢复锁。这可以防止所有尝试恢复相同故障情况的多个客户端。

停机
分析所有故障/恢复方案。但是也要考虑实例的停机状态。如果实例已停用（通过orchestrator -c begin-downtime），则会在分析摘要中注明。在考虑自动恢复时，忽略了停用的服务器。为此目的明确创建了停机时间：允许DBA抑制自动故障转移。

恢复挂钩
orchestrator支持钩子 - 通过恢复过程调用的外部脚本。这些是通过shell调用的命令数组，特别是bash。钩子是：

OnFailureDetectionProcesses：在检测到故障/恢复已知方案时调用。即使决定是否应该采取行动，这些脚本也称为befroe。
PreFailoverProcesses：在决定对场景采取行动后调用。执行顺序是顺序的。任何进程的失败（非零退出状态）都会中止恢复操作。这是你决定是否继续恢复的机会。
PostIntermediateMasterFailoverProcesses：恢复中间主站故障后运行的特定命令。执行顺序是顺序的。失败被忽略（恢复是根据协调器完成的）。
PostMasterFailoverProcesses：恢复主故障后要运行的特定命令。执行顺序是顺序的。失败被忽略（恢复是根据协调器完成的）。
PostFailoverProcesses：恢复任何类型（并遵循特定PostIntermediateMasterFailoverProcesses 或PostMasterFailoverProcesses命令）后运行的命令。失败被忽略。
PostUnsuccessfulFailoverProcesses：当恢复操作导致错误时运行的命令，因此没有已知的后继实例
恢复配置
详细说明与恢复相关的配置：

RecoveryPeriodBlockSeconds：对同一实例或相同的群集2回收率之间秒最小量（默认值：3600）
RecoveryIgnoreHostnameFilters：恢复分析将完全忽略与给定模式匹配的主机（例如，可能是测试服务器，拓扑中的开发机器）
RecoverMasterClusterFilters：主故障转移的自动恢复中包含的群集名称，别名或模式的列表。举个例子：
  "RecoverMasterClusterFilters": [
    "myoltp", // cluster name includes this string
    "meta[0-9]+", // cluster name matches this regex
    "alias=olap", // cluster alias is exactly "olap"
    "alias~=shard[0-9]+" // cluster alias matches this pattern
  ]
RecoverIntermediateMasterClusterFilters：用于中间主故障转移的自动恢复中包含的群集名称，别名或模式的列表。格式如上。请注意，".*"模式匹配所有内容。

PromotionIgnoreHostnameFilters：orchestrator不会选择匹配给定正则表达式模式的实例进行升级（例如，这些实例可能是测试服务器，拓扑中的dev机器）

FailureDetectionPeriodBlockMinutes：检测不一定会导致恢复（例如，实例可能会被停用）。此变量指示调用之间的最小时间间隔OnFailureDetectionProcesses。

RecoveryPollSeconds：orchestrator重新检查崩溃方案的轮询间隔（默认值：10s）

DetachLostSlavesAfterMasterFailover：在主升级的情况下，并假设某些从属无法进入重构拓扑，orchestrator是否应强制发出detach-slave命令以确保它们在将来不会意外恢复复制。

MasterFailoverLostInstancesDowntimeMinutes：当非零时，并且在主升级之后，orchestrator会在给定的分钟数内停止丢失奴隶和死亡主人。

PostponeSlaveRecoveryOnLagMinutes：一些恢复操作可以推到最后的步骤; 这样可以更快地应用更紧急的操作（例如更改DNS条目）。MASTER_DELAY由于二进制日志穷举搜索（GTID和伪GTID），修复在恢复时滞后的从属（由于配置或仅仅因为它们很忙）可能需要相当长的时间。该变量定义了一个阈值，高于该阈值时，滞后从属的重新布线被推到最后一刻。

ApplyMySQLPromotionAfterMasterFailover：主升级后，orchestrator应该自行清除read_only标志并强行分离复制？（默认值：false）

代理
您可以选择在MySQL主机上安装orchestrator-agent。 orchestrator-agent是一种向您的orchestrator服务器注册并 通过Web API 接受orchestrator请求的服务。

支持的请求与常规，操作系统和LVM操作有关，例如：

在主机上停止/启动MySQL服务
获取MySQL OS信息，例如数据目录，端口，磁盘空间使用情况
执行各种LVM操作，例如查找LVM快照，安装/卸载快照
在主机之间传输数据（例如，通过netcat）
orchestrator-agent是在Outbrain开发的，用于Outbrain的特定要求，而不是一般的解决方案。因此，它支持Outbrain架构所需的那些操作。例如，我们依靠LVM快照进行备份; 我们使用目录服务来注册可用的快照; 我们是DC感知的，并且喜欢通过远程备份进行本地备份。

尽管如此，至少orchestrator-agent应该吸引大多数人。它在某种程度上是可配置的（目录服务命令是可配置的 - 编写您自己的bash代码;数据传输命令是可配置的 - netcat用您自己的首选方法替换，等等）。

orchestrator-agent向orchestrator公开的信息和API 允许orchestrator通过从新近可用的快照获取数据来协调和操作新机器或损坏机器的种子。此外，它允许协调 器自动建议给定MySQL机器的数据源，方法是查找实际具有最新快照的主机，最好是在同一数据中心。

对于安全措施，代理需要令牌来操作除最简单请求之外的所有请求。此令牌由代理随机生成，并与协调器协商。Orchestrator不公开代理的令牌（现在需要完成一些工作来阻止错误消息上的令牌）。

支持的拓扑和版本
orchestrator支持以下设置：

普通的MySQL复制; 在经典的一个，根据日志文件的位置+
GTID复制。Oracle GTID和MariaDB GTID都受支持。
基于语句的复制（SBR）
基于行的复制（RBR）
半同步复制
单主（又称标准）复制
Master-Master（圆圈中的两个节点）复制
5.7启用按顺序复制时的并行复制（请参阅slave_preserve_commit_order）。
以下设置不受支持：

Master-master ...-主环（循环）复制，环中有3个或更多节点。
5.6并行（每个模式的线程）复制
多主复制（一个从多个主站复制的从站）
钨复制器
另请注意：

两个主节点支持主 - 主（环）复制。不支持环中三个或更多主节点的拓扑。

Galera / XtraDB群集复制不受严格支持：orchestrator无法识别Galera拓扑中的co-masters是否相关。每个这样的主人都会将协调器看作是其独特拓扑的头部。

支持在同一主机上具有多个MySQL实例的复制拓扑。例如，orchestrator的测试环境由四个实例组成，所有实例都运行在同一台机器上，由MySQLSandbox提供。但是，MySQL缺乏从站和主站之间的信息共享，因此协调器无法从上到下分析拓扑，因为主站不知道其从站正在侦听哪些端口。默认假设是从属设备正在侦听与其主设备相同的端口。在一台机器上（以及在同一网络上）有多个实例，这是不可能的。在这种情况下，您必须配置MySQL实例 report_host和report_port（读取更多）参数，并设置orchestrator的配置参数DiscoverByShowSlaveHosts为true。

风险
大多数时候，orchestrator只从拓扑中读取状态。默认配置是每分钟轮询一次实例。这非常放松，你可以比这更加紧张。但请注意，orchestrator会打开与所有服务器的连接（通常会重用它们）。

修改实例时会开始实际风险。即在拓扑周围移动从站。Orchestrator尽力：

确保只将实例移动到有效复制的位置（例如，您没有将5.5服务器放在5.6服务器下面）
确保在正确的时间移动实例（即实例和受影响的服务器没有严重滞后，以便及时强制执行操作）。
正确算法：在正确的时间停止从动装置，将其向前滚动到正确的位置，CHANGE MASTER到达正确的位置和位置。
以上所有内容均经过测试，并已在我们的生产拓扑中付诸实践。在整个生产过程中，我们没有目睹错误估计或错误保护。

当orchestrator在整个移动过程中遇到错误时，它会尽力回滚。然而，诸如新主控在移动过程中崩溃的极端情况可能会使拓扑结构不稳定（尽管同样的实例可能会在移动之前崩溃并留下任何不稳定的拓扑结构）。或者有人手动篡改复制，即使orchestrator正在移动奴隶。重点是 - 奇怪和邪恶的东西可能发生，并且奴隶有失去其位置与其主人的风险。

现在你有点害怕了，现在是时候反思了：当你用手在拓扑中手动导航你的奴隶时，你的手颤抖多少？我们怀疑所提供的自动化协调器使得一个更安全的管理机制比我们得到与我们握手。

另外，请阅读许可证，特别是“没有任何形式的保证或条件”部分。

陷阱
默认情况下，orchestrator仅每分钟轮询一次服务器（可通过配置InstancePollSeconds）。这意味着您看到的任何状态实质上都是一种估计。不同的实例在不同的时间进行轮询。例如，您在群集页面上看到的状态 不一定反映给定的时间点，而是最后一分钟（或您使用的任何轮询间隔）的不同时间点的组合。

该problems下拉到右侧也asynchonously执行。因此，您可能会在两个不同的状态中在两个位置（一次在cluster页面中，一次在problems下拉列表中）中看到相同的实例。

如果要获取最新的实例状态，请使用实例设置对话框中的“刷新”按钮。

类似地，在Long Queries页面上，所呈现的查询对于最后一分钟（或其他InstancePollSeconds设置）的时间点是真实的 。因此，当您查看此页面时，列出的查询可能已经完成。如果您选择单击该Kill query按钮，请注意您可能实际上正在查杀另一个 查询，在同一连接上执行后续现在已完成列出的长时间运行查询。

协调器需要几分钟才能完全检测到集群的拓扑。时间取决于拓扑的深度（如果您有从属从属时间增加）。这是因为协调器独立地轮询实例，并且在下一次轮询时，拓扑的洞察必须从主设备传播到从设备。

具体来说，如果您故障转移到新的主服务器，您可能会发现几分钟内拓扑似乎是空的。这可能发生，因为用于将自己标识为属于现在正在销毁的某个拓扑的实例。这是自我修复的。刷新并查看Clusters菜单以查看新创建的群集（新主服务器之后的名称）。

在运行种子时不要重新启动orchestrator（仅适用于使用orchestrator-agent）

否则，协调器是非侵入式和自我修复的。您可以随时重新启动它。