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

01

介绍

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

02

orchestrator是什么

2.1 功能

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

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

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

发现实例

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

重构拓扑结构

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

故障恢复

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

2.2 部署架构

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

生产推荐的部署架构

共享后端库架构

raft部署架构

03

相关配置

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 M