认识和学习orchestrator之基本使用篇

介绍

orchestrator目前GitHub上star 4.5k+，非常适用于有多个数据中心MySQL集群的管理。该工具使用起来很简单，但能用好却不容易，其配置参数将近200个，后端存储表47张，下面将介绍orchestrator以及它的使用方法。

orchestrator是什么

2.1

功能

其是一个管理MySQL复制拓扑的高可用、管理、可视化的工具。会定时采集探测到的各个实例的元数据信息，并将其存储在后端的DB库中。后端库支持的DB类型有SQLite和MySQL两种。

相比较于MHA等常用管理工具，其支持高可用部署，并对故障进行一个完整的探测分析后才会做相应的故障转移，探测更精准、全面。

依赖于采集的各个实例的元数据信息，其具有如下功能和特色：

发现实例

通过指定复制集集群里任意一个节点实例，其可以主动遍历该复制集的拓扑结构，还能读取MySQL的相关信息，如复制信息、配置、状态信息等；

重构拓扑结构

对已经发现的复制集集群，其可以通过命令、图形化的拖拽等方式，对现有复制集的关系进行重构；

故障恢复

orchestrator通过一个整体的方式来探测Master或者中间库的故障，支持优雅切换、自动故障切换、手动强制切换等多种故障切换方式；

2.2 部署架构

测试环境中，使用单点即可。orchestrator本身基于 Raft 实现高可用，避免了单点故障问题。部署架构支持单点、半高可用、高可用等多种方式。关于部署架构，后面会单独介绍下。

生产推荐的部署架构

共享后端库架构

raft部署架构

相关配置

3.1

orchestrator后端库的配置和权限

orchestrator对各个实例的采集信息会存储在后端库中，后端库只供orchestrator自己本身使用，可做如下的配置：

MySQL

由于orchestrator会在后端创建一些表，且创建的库是由orchestrator自身使用，可以直接赋权库的all权限；

CREATE DATABASE IF NOT EXISTS orchestrator;
CREATE USER 'orch_backend'@'127.0.0.1' IDENTIFIED BY 'orch_backend_password';
GRANT ALL PRIVILEGES ON `orchestrator`.* TO 'orch_backend'@'127.0.0.1';

orchestrator.conf.json的配置

针对后端库的认证配置，使用如下参数进行配置

{
  "MySQLOrchestratorHost": "127.0.0.1",
  "MySQLOrchestratorPort": 3306,
  "MySQLOrchestratorMaxPoolConnections": 4,
  "MySQLOrchestratorDatabase": "orchestrator",
  "MySQLOrchestratorUser": "orch_backend",
  "MySQLOrchestratorPassword": "orch_backend_password",


  "MySQLOrchestratorUseMutualTLS": false,
}

还可以使用MySQLOrchestratorCredentialsConfigFile参数，指定一个类似.my.cnf文件格式的配置文件

{
  "MySQLOrchestratorCredentialsConfigFile": "/etc/mysql/orchestrator-backend.cnf",
}


## 配置文件格式
cat /etc/mysql/orchestrator-backend.cnf
[client]
user=orch_backend
password=orch_backend_password
host=127.0.0.1
port=3306

‍

SQLite

orchestrator后端库还支持SQLite，SQLite默认已经嵌入到orchestrator，只需在配置参数中指定即可运行。

{
  "BackendDB": "sqlite",
  "SQLite3DataFile": "/var/lib/orchestrator/orchestrator.db",  
}

‍

3.2

配置要管理的MySQL库

orchestrator在指定的探测间隔内，会对每一个管理的MySQL实例进行探测来收集相关信息，需要创建相应的账号

{
  "MySQLTopologyUser": "orch",
  "MySQLTopologyPassword": "orch",
  "MySQLTopologyCredentialsConfigFile": "",
  "MySQLTopologyUseMixedTLS": false,
}

‍

MySQLTopologyCredentialsConfigFile参数

用法同MySQLOrchestratorCredentialsConfigFile参数

MySQLTopologyUseMixedTLS参数

如果在实例发现时，报如下错误，则因为启用了TLS，该参数默认值为true，且默认并没有在orchestrator.conf.json文件中配置，需要手动添加下并设置其为false

ERROR ReadTopologyInstance(xxxx:3306) show global status like 'Uptime': TLS requested but server does not support TLS

对应的权限

CREATE USER 'orch'@'orch_host' IDENTIFIED BY 'orch_topology_password';
GRANT SUPER, PROCESS, REPLICATION SLAVE, RELOAD ON *.* TO 'orch'@'orch_host';
GRANT SELECT ON mysql.slave_master_info TO 'orch'@'orch_host';


-- Only for NDB Cluster
GRANT SELECT ON ndbinfo.processes TO 'orch'@'orch_host';

‍

关于mysql.slave_master_info表的查询权限

在基于MySQL社区版本的MySQL实例中，通过读取该表的信息，获取用户名和密码，以此来重构主从关系。

但该权限不是必须的，如果生产环境中的主从账号比较固定，还可以通过ReplicationCredentialsQuery参数来配置一个查询参数，来获取用户名和密码等信息；

该参数需要返回一个单行5列的查询值，分别对应User、Password、SSLCaCert、SSLCert、SSLKey；

如果db中没有mysql.slave_master_info表或者不想给该表的select权限，则可以按照如下方式进行配置

{
    "ReplicationCredentialsQuery": "select 'rep','rep','','','';",
}

3.3 主从复制

故障探测使用MySQL拓扑本身作为信息来源，所以还需要对MySQL的复制做一些配置，以便能快速的判断。

-- 设置从库等待主库发送数据或者心跳的超时时间
set global slave_net_timeout = 4;


-- change master to 设置尝试连接的间隔秒数和尝试连接的次数
CHANGE MASTER TO MASTER_CONNECT_RETRY=1, MASTER_RETRY_COUNT=86400;

安装和启动

orchestrator采用golang进行编写，可以直接在官网上下载二进制包进行部署即可。

4.1 下载和安装

sudo mkdir -p /usr/local
sudo cd /usr/local
sudo tar xzfv orchestrator-3.2.6-linux-amd64.tar.gz

‍

4.2 配置文件

orchestrator启动时，会读取一个json格式的配置文件，可以通过-config参数来指定具体的配置文件，如果不指定该参数，则orchestrator默认读取配置文件的路径依次为：

/etc/orchestrator.conf.json
orchestrator家目录下的conf/orchestrator.conf.json
orchestrator家目录下的orchestrator.conf.json

orchestrator的参数将近200个，大部分的配置参数可以先忽略，可以先使用orchestrator-sample.conf.json示例配置文件，并做一些简单的更改。

4.3 运行和启动

orchestrator是已编译的二进制文件，可以直接运行。

## 二进制直接运行
nohup ./orchestrator http &


## 指定配置文件运行
nohup ./orchestrator -config ./orchestrator.conf.json http &


## systemd方式运行
systemctl start orchestrator

‍

05

故障探测

orchestrator使用整体的比较全面的方法来检测master或者intermediate master是否故障，并对故障类型做相应的分析分类。

其充分利用复制拓扑，不仅观察master本身，还观察它的replicas，如要针对一个dead master类型的判定，必须同时满足以下情况，才会将集群判定为DeadMaster：

连不上master；
能够连上master的副本，并且所有的副本均不能连接到master；

5.1 常见的故障分析类型

orchestrator通过分析后端采集信息，来对故障探测的类型做分析，实例采集间隔由InstancePollSeconds参数控制。

常见的故障类型分析：

DeadMasterWithoutReplicas

最近一次检查master为不可达，且没有从库；这种情况说明master是一个故障单点。

DeadMaster

最近一次检查master为不可达、且其所有的从库最近一次检查都可达、从库全无复制；这种情况说明master故障，如果配置了自动故障转移，则会执行。

DeadMasterAndReplicas

最近一次检查master为不可达、且其所有的从库最近一次检查都不可达、从库全无复制；这种情况可能是orchestrator自身的问题；

DeadMasterAndSomeReplicas

最近一次检查master为不可达、且其部分从库可达，从库全无复制；当master所在的数据中心有问题时则可能出现这种情况，如果配置了自动故障转移，则会执行；

UnreachableMasterWithLaggingReplicas

最近一次检查master为不可达、且所有的从库都有延迟；部分从库有复制；这种情况说明master可能处于濒死的边缘，等待下一个轮询的判定；

UnreachableMaster

以下两种情况均判定为该类型：

最近一次检查master为不可达、且其部分从库可达、部分从库有复制；

最近一次检查master为不可达，但部分检查有效，部分从库可达，部分从库有复制；

这种情况说明master可能处于濒死的边缘，等待下一个轮询的判定；

NoWriteableMasterStructureWarning

检查master可达，且处于只读状态，并且其有从库可达，同时配置了RecoverNonWriteableMaster参数；

这种情况很明显主库设置了只读属性，如果配置RecoverNonWriteableMaster参数为true，则orchestrator会将master的只读属性摘除；

MasterSingleReplicaNotReplicating

检查master可达，且其唯一的一个从库可达，但停止了复制；这种情况说明唯一的从库复制线程有问题；

MasterSingleReplicaDead

检查master可达，且其唯一的一个从库不可达；这种情况说明唯一的从库有问题；

AllMasterReplicasNotReplicating

检查master可达，且所有的从库可达，但都停止了复制；这种情况说明主从的复制线程有问题；

其他类型

除此以外，还有很多其他的类型，如关于半同步的、级联复制拓扑结构中的中间库状态的等等，详细的其他类型可在GetReplicationAnalysis函数中查看；

检查和恢复

在分析完当前MySQL的故障类型后，orchestrator会对不同的场景分析做不同的处理：

checkAndRecoverDeadMaster

针对DeadMaster、DeadMasterAndSomeReplicas场景的分析，则可能会执行checkAndRecoverDeadMaster函数，来决定是否要采取恢复流程；

checkAndRecoverNonWriteableMaster

针对NoWriteableMasterStructureWarning场景的分析，尝试使用该流程进行恢复；

checkAndRecoverGenericProblem

是一个通用的问题检查恢复，不做具体动作。针对DeadMasterAndReplicas、UnreachableMaster、UnreachableMasterWithLaggingReplicas、AllMasterReplicasNotReplicating、AllMasterReplicasNotReplicatingOrDead这些场景的分析，会使用该恢复流程做处理；

其他场景类型

除以上外，针对半同步、级联中间库、双主、MGR等场景，都会有不同的恢复流程来处理。

故障切换

orchestrator支持优雅切换、自动故障切换、手动强制切换等多种故障切换方式。

7.1 自动恢复

在满足故障探测、相关分析、和设置切换的条件后，orchestrator会对主库所有的从库做一个全面的综合考量，如考虑从库执行的位置点、数据中心、版本的兼容、binlog格式、是否满足相应的参数、promotion_rule规则的判定等等，来寻找一个符合设定条件的候选节点并尝试提升其为新的主库，从而完成自动故障恢复；

关于候选节点的选取流程，后面会单独介绍。

7.2 优雅的、有计划的恢复

在计划范围内的，可以通过graceful-master-takeover和graceful-master-takeover-auto这两个命令来做恢复；

graceful-master-takeover与graceful-master-takeover-auto的区别在于老主库作为新主库的从库，是否会开启复制，前者不会开启，后者会自动开启；

7.3 手动恢复

使用recover和recover-lite命令来做恢复,自动恢复也是使用该命令；

两者的区别在于recover-lite不会执行hooks定义的脚本;

7.4 手动强制恢复、故障转移

使用force-master-failover和force-master-takeover命令来强制故障恢复；

force-master-failover

丢弃master并强制启动一个故障转移，该操作是让orchestrator自己选择一个合适的从库来替换master；

force-master-takeover

丢弃master并强制启动故障转移，该操作是将人为指定的从库作为新master,区别于force-master-failover；

7.5 防止摇摆

在一些场景下，当完成一次故障恢复后，可能短时间内又发生了一次相同的故障，orchestrator通过RecoveryPeriodBlockSeconds参数来阻止下一次恢复的发生，该参数默认设置为3600秒。

7.6 故障后的ack

针对一次自动恢复后的，还可以通过ack方式确认后，让其继续执行故障恢复。

ack-all-recoveries表示ack全部的故障恢复；

ack-cluster-recoveries表示ack指定的集群故障恢复；

ack-instance-recoveries表示ack指定的实例故障恢复；

hooks

orchestrator支持在故障检测、故障切换之前、故障切换后等阶段自定义脚本，以通过hooks的方式来做一些额外的处理动作；

hooks支持一个数组参数，即可以在任意一个hooks中，可以定义多个脚本；

8.1 脚本处理说明

如果process数组中的脚本以&结尾，则脚本将会被异步执行，执行状态会被忽略，不影响整体流程；
如果process数组中的搅拌不以&结尾，则执行时脚本任意一步退出状态码不为0，则会终止整个流程；
hooks中指定多个脚本时，orchestrator将按照脚本定义的顺序来执行；
orchestrator同时也支持一些参数和执行变量，以便供自定义的脚本引用，具体可参考官方文档；

8.2 支持的hooks有如下几种

PreGracefulTakeoverProcesses

在执行graceful master takeover切换前被调用；

PreFailoverProcesses

在执行恢复动作之前被调用；

PostMasterFailoverProcesses

在Master故障成功恢复后调用；

PostIntermediateMasterFailoverProcesses

在中间master或者replication group的成员成功恢复后调用；

PostFailoverProcesses

在任意恢复成功之后调用(包括PostMasterFailoverProcesses和PostIntermediateMasterFailoverProcesses)；

PostUnsuccessfulFailoverProcesses

在任意未完全成功恢复之后调用；

PostGracefulTakeoverProcesses

在执行graceful master takeover切换后被调用；

在成功执行take-master之后，执行的动作

在探测到故障时被调用；

PostTakeMasterProcesses

在成功执行take-master之后，被调用；

8.3

Hooks的参数和环境

orchestrator为所有的hooks提供failure/recovery(故障/恢复)相关信息变量，如认证失败的实例、认证提升master的实例、影响的副本、故障的类型、集群的名称等；

简单举例

## 以下为提供的部分参数，可以在脚本中以占位符的方式进行引用
{failureType}
// 失败的类型


{instanceType}
// 实例的类型,输出的值有("master", "co-master", "intermediate-master")


{isMaster} 
// 是否为master 输出的值有：(true/false)


{isCoMaster} (true/false)


{failureDescription}
// 输出故障描述


{failedHost}
// 输出失败的主机


{failedPort}
// 输出失败的端口


{failureCluster}
// 失败的集群名


{failureClusterAlias}
// 失败的集群别名


{failureClusterDomain}
// 失败的集群域名


{countReplicas} (replaces {countSlaves})
// 副本的数量,替代countSlaves

‍

引用示例

这些信息变量可以通过环境变量或脚本中特殊引用两种方式被引用：

{
  "PreGracefulTakeoverProcesses": [
    "echo 'Planned takeover about to take place on {failureCluster}. Master will switch to read_only' >> /tmp/recovery.log",
    "scripts/send_alarm.sh &",
  ],   
}

‍

简单使用

orchestrator默认监听的端口是3000，启动后，可以通过web界面进行访问。

9.1 web上的样子

通过给定一个实例后，orchestrator会根据该实例进行拓扑发现，并将拓扑架构在web界面上展示。如下图，通过给定任意一个要发现的实例，则一段时间后，orchestrator会自动探测出该实例所在集群的整个拓扑结构：

通过访问web界面的Clusters下的Discover，如url路径如下：http://localhost:3000/web/discover，指定主从关系的任意一个实例，则orchestrator会自动发现其主从关系，并在Dashboard下展示。

9.2 管理和操作方式

orchestrator相关命令的操作，有多种方式，可以通过如下来进行管理。

使用orchestrator二进制文件管理

orchestrator二进制文件本身也具有客户端命令操作的功能

使用orchestrator-client来管理

该文件是一个包裹api操作的shell脚本，其特点是不用到处部署orchestrator，其本质上是调用orchestrator提供的api来访问；

## 设置orchestrator的api环境变量
export ORCHESTRATOR_API=https://orchestrator.myservice.com:3000/api


## 部署了多个orchestrator节点(如生产环境3个节点组成raft)
export ORCHESTRATOR_API="https://orchestrator.host1:3000/api https://orchestrator.host2:3000/api https://orchestrator.host3:3000/api"

使用API方式来管理

api操作通过url的方式进行访问;

使用Web 界面来管理

通过界面的拖拽等方式来进行管理(功能有限)。

9.3 示例

查看当前所有集群的相关信息

## 使用orchestrator命令 
./orchestrator -c clusters


## orchestrator-client命令 
./orchestrator-client -c clusters 


## 调用api的方式 
curl -s http://orchestrator.myservice.com:3000/api/clusters-info|jq 


## 浏览器中使用web界面查看 
http://orchestrator.myservice.com:3000/web/clusters/

‍

orchestrator常用命令

需要说明的是：

虽然大部分的命令都可以通过orchestrator、api方式进行调用，但个别命令可能只能通过orchestrator或api方式进行调用，具体可参见命令帮助文档；

10.1 查询信息相关

orchestrator提供了很多查询的命令，很多见名知意，以下只列出常用的一些命令

clusters

查询出当前orchestrator探测到的所有MySQL集群；

clusters-alias

列出当前orchestrator探测到的所有MySQL集群和别名；

all-clusters-masters

列出当前探测到的所有集群可写的master实例；

topology

通过给定的任意一个实例或集群别名，显示其整个集群的拓扑结构；

命令对应的API

## clusters
 clusters-info
 
 ## clusters-alias
 clusters-info
 
 ## all-clusters-masters
 masters
 
 ## topology
 topology/:clusterHint
 topology/:host/:port

相关示例

## 列出当前探测的所有MySQL集群
./orchestrator-client -c clusters


## 列出当前orchestrator探测到的所有MySQL集群别名
./orchestrator-client -c clusters-alias


## 列出当前探测到的所有集群可写的master实例
./orchestrator-client -c all-clusters-masters


## 通过给定的任意一个实例，显示其整个集群的拓扑结构
./orchestrator-client -c topology -i instance.belonging.to.a.topology.com


## 通过给定集群的别名,显示整个集群的拓扑结构
./orchestrator-client -c topology -alias cluster_3306

10.2 实例的发现和移除管理

discover

通过给定的一个实例，来发现它并探测其所在MySQL的集群拓扑结构；

forget

忘记一个指定的实例；说明：

如果忘记的实例，仍然在主从拓扑结构中存在，则会在下一次探测时再次被发现；
忘记实例操作，只是将实例的相关信息从orchestrator的后端库中移除，并不影响MySQL集群实际的主从关系；

forget-cluster

忘记指定的集群。该命令只在api中支持，可以将整个集群中所有实例全部忘记。同forget一样，只是删除存储在orchestrator后端库的信息，并不影响MySQL集群实际的主从关系；

命令对应的API

## discover
discover/:host/:port


## forget
forget/:host/:port


## forget-cluster
forget-cluster/:clusterHint

相关示例

## 发现一个实例并拓扑其所在的MySQL集群拓扑结构;
./orchestrator-client -c discover -i instance.to.discover.com:3306


## 忘记某个实例
./orchestrator-client -c forget -i instance.to.forget.com:3306


## 忘记整个集群
./orchestrator-client -c forget-cluster -alias cluster_for_forget

10.3 拓扑重构

orchestrator支持基于Oracle GTID、MariaDB GTID、Pseudo GTID等多种类型的MySQL拓扑结构，针对每一种其都提供了相应的拓扑重构命令，但最常用的还是smart重构命令，smart重构命令会根据当前拓扑结构的具体类型，调用不同的重构命令进行拓扑重构。

relocate

将一个实例重构于另一个(目标)实例之下，其目标实例几乎可以是任意一个。

relocate-replicas

将指定实例的所有或者部分副本重构于另一个(目标)实例之下，可以通过-pattern 正则来指定要匹配的部分副本(如果不指定,则影响全部)，通常这样比一个个relocate重构要快。

需要说明的是：

该操作并不影响指定的实例，只影响其副本或部分副本；
orchestrator会分多步骤来处理该指令,并不保证原子性，重构后可能有的会成功有的会失败；

take-siblings

将指定副本的所有兄弟副本重构为自己的子副本。

regroup-replicas

给定一个实例(可能是已经crashed的),挑选一个它的副本,并将其提升为master；

说明：

给定的实例只能是master，且无法指定副本具体是哪一个(指定也是忽略),orchestrator会自己判断选取合适的副本来完成重构；
该操作实际上是执行了RegroupReplicas函数，对当前master的所有副本依据一定的规则排序后，选出一个候选节点，并对其他剩余副本做change master操作，这在故障转移章节会介绍；
该命令只支持在orchestrator中使用；

take-master

将一个副本变成其master的master，就是将主从互换下角色；

说明：

该操作只影响切换的两个实例，这两个实例上的其他实例结构并不会改变；
要操作实例的master必须也是一个副本；

命令对应的API

## relocate
relocate/:host/:port/:belowHost/:belowPort


## relocate-replicas
relocate-slaves/:host/:port/:belowHost/:belowPort


## take-siblings
enslave-siblings/:host/:port


## regroup-replicas
regroup-slaves/:host/:port


## take-master
enslave-master/:host/:port

相关示例

relocate示例

## relocate
./orchestrator-client -c relocate -i replica.to.relocate.com -d instance.that.becomes.its.master

relocate-replicas示例

## 现有拓扑结构
# ./orchestrator-client -c topology -alias 3200_cluster
db84.add.dbserver.com:3200 (3200_db84)     [0s,ok,5.6.51-91.0-log,rw,ROW,>>,GTID]
+ db85.add.dbserver.com:3300 (3300_db85)   [0s,ok,8.0.20-11,rw,ROW,>>,GTID]
  + db86.add.dbserver.com:3200 (3200_db86) [0s,ok,8.0.20-11,ro,ROW,>>,GTID]
  + db86.add.dbserver.com:3300 (3300_db86) [0s,ok,8.0.20-11,ro,ROW,>>,GTID]
  + db86.add.dbserver.com:3400 (3400_db86) [0s,ok,8.0.20-11,ro,ROW,>>,GTID]


## 执行relocate-replicas操作,将db85下的所有副本全部挂到db84下
# ./orchestrator-client -c relocate-replicas -i db85.add.dbserver.com:3300 -d db84.add.dbserver.com:3200      
db86.add.dbserver.com:3300
db86.add.dbserver.com:3400
db86.add.dbserver.com:3200


## 查看新的拓扑结构
# ./orchestrator-client -c topology -alias 3200_cluster
db84.add.dbserver.com:3200 (3200_db84)   [0s,ok,5.6.51-91.0-log,rw,ROW,>>,GTID]
+ db85.add.dbserver.com:3300 (3300_db85) [0s,ok,8.0.20-11,rw,ROW,>>,GTID]
+ db86.add.dbserver.com:3200 (3200_db86) [0s,ok,8.0.20-11,ro,ROW,>>,GTID]
+ db86.add.dbserver.com:3300 (3300_db86) [0s,ok,8.0.20-11,ro,ROW,>>,GTID]
+ db86.add.dbserver.com:3400 (3400_db86) [0s,ok,8.0.20-11,ro,ROW,>>,GTID]

take-siblings示例

## 现有拓扑结构
# ./orchestrator-client -c topology -alias 3200_cluster
db84.add.dbserver.com:3200 (3200_db84)   [0s,ok,5.6.51-91.0-log,rw,ROW,>>,GTID]
+ db85.add.dbserver.com:3300 (3300_db85) [0s,ok,8.0.20-11,rw,ROW,>>,GTID]
+ db86.add.dbserver.com:3200 (3200_db86) [0s,ok,8.0.20-11,ro,ROW,>>,GTID]
+ db86.add.dbserver.com:3300 (3300_db86) [0s,ok,8.0.20-11,ro,ROW,>>,GTID]
+ db86.add.dbserver.com:3400 (3400_db86) [0s,ok,8.0.20-11,ro,ROW,>>,GTID]

## 执行take-siblings操作(将db85下的所有兄弟副本,都挂载到db85下)
# ./orchestrator-client -c take-siblings -i db85.add.dbserver.com:3300
db85.add.dbserver.com:3300<db84.add.dbserver.com:3200

## 查看重构后的拓扑结构
# ./orchestrator-client -c topology -alias 3200_cluster                              
db84.add.dbserver.com:3200 (3200_db84)     [0s,ok,5.6.51-91.0-log,rw,ROW,>>,GTID]
+ db85.add.dbserver.com:3300 (3300_db85)   [0s,ok,8.0.20-11,ro,ROW,>>,GTID]
  + db86.add.dbserver.com:3200 (3200_db86) [0s,ok,8.0.20-11,ro,ROW,>>,GTID]
  + db86.add.dbserver.com:3300 (3300_db86) [0s,ok,8.0.20-11,ro,ROW,>>,GTID]
  + db86.add.dbserver.com:3400 (3400_db86) [0s,ok,8.0.20-11,ro,ROW,>>,GTID]

regroup-replicas示例

## 现有拓扑结构
# ./orchestrator-client -c topology -alias 3200_cluster
db84.add.dbserver.com:3200 (3200_db84)   [0s,ok,5.6.51-91.0-log,rw,ROW,>>,GTID]
+ db85.add.dbserver.com:3300 (3300_db85) [0s,ok,8.0.20-11,rw,ROW,>>,GTID]
+ db86.add.dbserver.com:3200 (3200_db86) [0s,ok,8.0.20-11,ro,ROW,>>,GTID]
+ db86.add.dbserver.com:3300 (3300_db86) [0s,ok,8.0.20-11,ro,ROW,>>,GTID]
+ db86.add.dbserver.com:3400 (3400_db86) [0s,ok,8.0.20-11,ro,ROW,>>,GTID]


## 执行regroup-replicas操作(该命令只支持使用orchestrator来操作)
# ./orchestrator -c regroup-replicas -i db85.add.dbserver.com:3300


## 查看重构后的拓扑结构
# ./orchestrator-client -c topology -alias 3200_cluster                              
db84.add.dbserver.com:3200 (3200_db84)     [0s,ok,5.6.51-91.0-log,rw,ROW,>>,GTID]
+ db85.add.dbserver.com:3300 (3300_db85)   [0s,ok,8.0.20-11,ro,ROW,>>,GTID]
  + db86.add.dbserver.com:3200 (3200_db86) [0s,ok,8.0.20-11,ro,ROW,>>,GTID]
  + db86.add.dbserver.com:3300 (3300_db86) [0s,ok,8.0.20-11,ro,ROW,>>,GTID]
  + db86.add.dbserver.com:3400 (3400_db86) [0s,ok,8.0.20-11,ro,ROW,>>,GTID]

take-master示例

## 查看当前拓扑(db162是一个中间主库，其包含2个从库db163和db165)
./orchestrator-client -c topology -i db161.add.dbserver.com:3000
db161.add.dbserver.com:3000     [0s,ok,5.6.36-log,rw,ROW,>>,GTID]
+ db162.add.dbserver.com:3000   [0s,ok,5.6.36-log,ro,ROW,>>,GTID]
  + db163.add.dbserver.com:3000 [0s,ok,5.6.36-log,ro,ROW,>>,GTID]
  + db165.add.dbserver.com:3000 [0s,ok,5.6.36-log,rw,ROW,>>,GTID]


## 对db163执行take-master操作(实际调换db163和db162)
## 即将dbpnew163作为db162的master -i指定要操作的实例
# ./orchestrator-client -c take-master -i db163.add.dbserver.com:3000
db163.add.dbserver.com:3000<db161.add.dbserver.com:3000


## 执行后的拓扑结构(这两个实例上的其他副本结构不变,db165实例依然还是db162的副本)
# ./orchestrator-client -c topology -i db161.add.dbserver.com:3000
db161.add.dbserver.com:3000       [0s,ok,5.6.36-log,rw,ROW,>>,GTID]
+ db163.add.dbserver.com:3000     [0s,ok,5.6.36-log,ro,ROW,>>,GTID]
  + db162.add.dbserver.com:3000   [0s,ok,5.6.36-log,ro,ROW,>>,GTID]
    + db165.add.dbserver.com:3000 [0s,ok,5.6.36-log,rw,ROW,>>,GTID]

10.4 命令的帮助

可通过以下方式获取帮助。

## 输出orchestrator命令行常用命令帮助
./orchestrator -h


## 输出orchestrator操作相关命令帮助
./orchestrator help


## 查看orchestrator某个具体命令的帮助
./orchestrator help <command>
Detailed help for a given command (e.g. "relocate")
orchestrator help relocate

‍

认证与安全

当通过web或api的方式访问orchestrator时，可以通过以下方式来进行安全认证。

11.1 基本认证（basic）

指定AuthenticationMethod类型为basic，配置用户名和密码即可；

{
 "AuthenticationMethod": "basic",
 "HTTPAuthUser":         "orch",
 "HTTPAuthPassword":     "orch"
}

‍

11.2

基本认证扩展(multi)

该认证方式同basic工作模式，但其还配置了一个用户名为readonly的用户，其密码可以是任意的；readonly用户只能查看，不能操作；

{
 "AuthenticationMethod": "multi",
 "HTTPAuthUser":         "orch",
 "HTTPAuthPassword":     "orch"
}

11.3

orchestrator-client的认证配置

如果orchestrator启用了认证，则客户端可以通过以下方式进行访问。

配置参数

## 添加配置认证的参数
export ORCHESTRATOR_AUTH_USER=username
export ORCHESTRATOR_AUTH_PASSWORD=password

执行时使用-b参数

./orchestrator-client -b username:password -c <command>

api的配置

curl时添加认证即可；

curl -u username:password -s http://orchestrator.myservice.com:3000/api/clusters-info|jq

总结

orchestrator通过一个整体全面的分析，对MySQL集群进行管理，支持MySQL主从复制拓扑关系的调整、主库故障切换、手动切换等，还提供了web界面展示拓扑关系图和通过拖拽的方式来操作MySQL集群。另外提供了Restful API便于集成在别的系统中，同时相比于MHA等其他管理工具，避免了单点故障等，是一个值得推荐的MySQL高可用管理和复制拓补显示工具。

原文链接：https://blog.csdn.net/ZVAyIVqt0UFji/article/details/124335071

MySQL

‍ SQLite

其他场景类型

‍

你可能也喜欢

‍

SQLite