Orchestrator实现MySQL故障切换

这一节内容，来聊聊Orchestrator（后面简称Orch）的部署和通过Orch实现MySQL故障切换测试。

这一节内容，就采用Orch/Raft方案。在这种方案中，每一个Orch实例都需要一套单独的后端MySQL（当然，也可以是SQLite，这篇文章只讲后端数据库是MySQL的场景）。

Orch负责监听MySQL一主两从架构中三个MySQL实例（A、B和C）的状态，当A发生故障时，Orch会自动从B和C中选择一个新主进行切换，假设B为新主，Orch会自动创建B到C的复制关系，旧主会被踢出复制拓扑（如果旧主需要重新加入拓扑，需要手动与B或者C建立复制关系）。

在切换之后，如果为了客户端能正常找到新主，可能会涉及到VIP修改、DNS修改等操作，可以放在PostFailoverProcesses的Hook中。关于Hook的用法，后面有机会再写一篇。

当然，如果生产环境考虑使用Orch，可以使用一套Orch集群，管理上百套MySQL拓扑，类似Redis Sentinel管理多套Redis主从。

另外，被管理的MySQL拓扑只有主从也行，这篇文章选择一主两从是为了验证其他从是否会自动接到新主下进行复制。

配置主为A，从为B和C的一主两从环境，这个环境可自行部署，这篇文章就不赘述了。

2 安装和配置Orch

在三台Orch机器上执行

2.1 获取Orch安装包

wget https://github.com/openark/orchestrator/releases/download/v3.2.6/orchestrator-3.2.6-1.x86_64.rpm

2.2 安装Orch

yum install orchestrator-3.2.6-1.x86_64.rpm

2.3 配置数据库

在前面我们也讲到，每个Orch实例都需要准备一套单独的MySQL来存放Orch的元数据。

在这每一套Orch数据库中创建Orch用户：

CREATE USER 'orc_server_user'@'127.0.0.1' IDENTIFIED BY 'BdgwetY123';
GRANT ALL PRIVILEGES ON `orchestrator`.* TO 'orc_server_user'@'127.0.0.1';

2.4 配置Orch

cd usr/local/orchestrator
mkdir -p {log,conf,raftdata}
cp orchestrator-sample.conf.json ./conf/orchestrator.conf.json

编辑配置文件./conf/orchestrator.conf.json，修改如下参数：

......
  "MySQLTopologyUser": "orc_client_user",
  "MySQLTopologyPassword": "iqadgurad1q8",
  ......
  "MySQLOrchestratorHost": "127.0.0.1",
  "MySQLOrchestratorPort": 3306,
  "MySQLOrchestratorDatabase": "orchestrator",
  "MySQLOrchestratorUser": "orc_server_user",
  "MySQLOrchestratorPassword": "BdgwetY123",
   ......
  "AuthenticationMethod": "basic",
  "HTTPAuthUser": "admin",
  "HTTPAuthPassword": "uq81sgca1da",  
  "RaftEnabled":true,
  "RaftDataDir":"/usr/local/orchestrator/raftdata",
  "RaftBind":"192.168.21.11",
  "DefaultRaftPort":10008,
  "RaftNodes":[
  "192.168.21.11",
  "192.168.21.14",
  "192.168.21.28"
  ],
    ......
  "RecoveryPeriodBlockSeconds": 60,
  "RecoveryIgnoreHostnameFilters": [],
  "RecoverMasterClusterFilters": [
    "*"
  ],
  "RecoverIntermediateMasterClusterFilters": [
    "*"
  ],
  ......

参数解释：

MySQLTopologyUser：拓扑发现用户；
MySQLTopologyPassword：拓扑发现密码；
MySQLOrchestratorHost：Orch后端数据库地址；
MySQLOrchestratorPort：Orch后端数据库端口；
MySQLOrchestratorDatabase：Orch后端数据库；
MySQLOrchestratorUser：Orch后端数据库用户；
MySQLOrchestratorPassword：Orch后端数据库密码；
AuthenticationMethod：认证方式，如果开启，页面、命令行、API都需要通过用户密码才能访问；
HTTPAuthUser：认证用户；
HTTPAuthPassword：认证密码；
RaftEnabled：开启Raft集群模式；
RaftDataDir：Raft集群工作目录，存放临时数据；
RaftBind：Raft集群监听IP地址，这里填写本机IP，注意，三个节点只有这个位置配置不一样；
DefaultRaftPort：Raft集群监听端口；
RaftNodes：所有Orch节点的IP；
RecoveryPeriodBlockSeconds：该时间内再次发生故障，不会再次转移；
RecoveryIgnoreHostnameFilters：恢复会忽略的主机；
RecoverMasterClusterFilters：只在匹配这些正则表达式模式的集群上进行主恢复，“*”表示所有集群都能恢复；
RecoverIntermediateMasterClusterFilters：仅在与这些正则表达式模式匹配的集群上进行IM恢复，“*”表示所有都能恢复。

3 将测试高可用的MySQL配置到Orch中

3.1 在测试高可用的MySQL中创建Orch连接用户

create user 'orc_client_user'@'192.168.21.%' identified by 'iqadgurad1q8'; 
grant super, process, replication slave, reload on *.* to 'orc_client_user'@'192.168.21.%'; 
grant select on mysql.slave_master_info to 'orc_client_user'@'192.168.21.%';

3.2 启动 Orch

如果三个Orch节点之间有防火墙限制，则需要互相开放10008和3000端口。

cd usr/local/orchestrator
./orchestrator -config ./conf/orchestrator.conf.json http >> ./log/orchestrator.log 2>&1 &

3.3 在页面查看Orch集群信息

登录页面：Orch IP:3000

会进入到如下界面，

输入下面两行配置的用户和密码就可以登录

"HTTPAuthUser": "admin",

"HTTPAuthPassword": "uq81sgca1da",

点击 Home --> Status

可以看到 Orch 集群信息

根据上面的信息，登录到leader节点，后面的操作都是在leader节点执行的。

3.4 将业务MySQL添加到Orch中

Cluster-->Discover，添加主的IP和端口，只要DiscoverByShowSlaveHosts参数设置为true，则可以自动发现这个主实例下面的所有从实例。

3.5 查看拓扑集群

Cluster-->Dashboard

4 测试高可用

把刚才新增拓扑的Master节点（也就是172.168.21.11:3307）关闭

再次查看拓扑，变成了

其中，192.168.21.28:3307变成了主，192.168.21.14:3307之前接在192.168.21.11:3307后面，现在接在192.168.21.28:3307后面了。

也就是Orch除了实现自动切换，也会把其他节点接在新主下复制数据。

作用	IP:Port	Orch的后端数据库
Orch Leader	192.168.21.11:3000	192.168.21.11:3306
Orch	192.168.21.14:3000	192.168.21.14:3306
Orch	192.168.21.28:3000	192.168.21.28:3306

作用	IP:Port
MySQL 服务 A	192.168.21.11:3307
MySQL 服务 B	192.168.21.14:3307
MySQL 服务 C	192.168.21.28:3307

Orchestrator实现MySQL故障切换

评论