Orchestrator管理mysql复制

时间 2019-12-07

原文原文链接

.................................................................................
系统:centos7
Mysql:5.7.22
IP：192.168.225.130，端口3306（存放orchestrator的扩普状态）
M1：主：192.168.225.128：3306 —— 从:192.168.225.129：3306
M2：主：192.168.225.128：3307 —— 从:192.168.225.129：3307
.................................................................................node

1、简介

orchestrator – 对 MySQL 复制拓扑管理并可视化的工具。
支持：mysql

 检测和审查复制集群
 安全拓扑重构:转移服务于另一台计算机的系统拓扑S
 整洁的拓扑可视化
 复制问题可视化
 经过简单的拖拽修改拓扑
 维护模式声明和执行
 审计操做

重构拓扑只须要简单的拖拽。Orchestrator 会保证安全,而且禁止非法复制拓扑。
Orchestrator是高可用性管理工具，它提供了发现MySQL环境的复制拓扑能力，经过上下连接来识别主从。它也能够经过GUI重构复制拓扑结构，提供一个拖放界面将从设备提高为主设备，这是一个很是安全的操做。事实上，Orchestrator拒绝任何非法操做，以避免破坏系统。
　　最后，Orchestrator在节点遭遇失败时能够支持恢复，由于它使用状态的概念智能选择正确的恢复方法，并决定使用适当的主升级过程。linux

2、安装配置步骤

操做步骤git

步骤一、下载安装

网址：https://github.com/github/orc...github

# wget https://github.com/github/orchestrator/releases/download/v3.0.11/orchestrator-3.0.11-1.x86_64.rpm
# wget https://github.com/github/orchestrator/releases/download/v3.0.11/orchestrator-client-3.0.11-1.x86_64.rpm 
安装：# rpm -ivh orchestrator-3.0.11-1.x86_64.rpm
# rpm -ivh orchestrator-client-3.0.11-1.x86_64.rpm
安装完成后，目录在/usr/local/orchestrator

步骤二、添加host

在130上面添加host，vim /etc/hosts
192.168.225.128 vm-test1
192.168.225.129 vm-test2
192.168.225.130 vm-test3web

步骤三、 Mysql主从上面配置文件配置report_host

DiscoverByShowSlaveHosts": ture 这种状况下，必须配置report_host
$ vim /etc/my_3306.cnf
report_host=192.168.225.128 //ip为自身的ip
说明:不加report_host ，show slave hosts 不会显示host，会致使程序报错的sql

report_host为只读参数，必须重启才可生效
说明：
DiscoverByShowSlaveHosts": false 也能够，这样就不须要设置report_host了数据库

步骤4 、130：3306上开通orchestrator的权限，存放扩谱状态：

CREATE DATABASE IF NOT EXISTS orchestrator;
mysql>  GRANT ALL PRIVILEGES ON `orchestrator`.* TO 'orche'@'127.0.0.1' IDENTIFIED BY '000000';

步骤五、M:3306-S:3306/3307主从复制开通orchestrator的帐户

M1/M2: mysql> GRANT SUPER, PROCESS, REPLICATION SLAVE, RELOAD ON *.* TO 'orche'@'192.168.225.130' IDENTIFIED BY '000000';
Mysql> GRANT SELECT ON mysql.slave_master_info TO 'orche'@'192.168.225.130';
说明：On MySQL 5.6 and above, and if using master_info_repository = 'TABLE', let orchestrator have access to the mysql.slave_master_infotable.

步骤六、修改配置文件(存储orche的扩谱状态的mysql3307用户名密码)

# cd /usr/local/orchestrator/
# cp orchestrator-sample.conf.json orchestrator.conf.json
# vim orchestrator.conf.json
  "MySQLOrchestratorHost": "127.0.0.1",
  "MySQLOrchestratorPort": 3306,
  "MySQLOrchestratorDatabase": "orchestrator",
  "MySQLOrchestratorUser": "orche",
  "MySQLOrchestratorPassword": "000000",

说明：配置文件放在/etc/orchestrator.conf.json，默认会调用json

步骤七、启动orchestrator

$ cd /usr/local/orchestrator/
$ nohup orchestrator http &vim

步骤八、显示已知的集群

$ orchestrator -c clusters //第一次执行成功后库orchestrator中就出现不少表，之后执行会显示出已经知道的集群拓扑
$ orchestrator -c clusters --config=/path/to/config.file //若配置文件在其余路径

步骤九、发现mysql hosts（也能够编辑web页添加）

$ orchestrator -c discover -i vm-test1:3306
$ orchestrator -c discover -i vm-test1:3307
$ orchestrator -c discover -i192.168.225.128:3306
说明：该命令会向上检测master，向下检测slave。 -i 表明实例，必须跟着hostname:port
步骤 10web页面

Web页面：http://192.168.225.130:3000

3、配置config

一、轮询时间设置

InstancePollSeconds，默认是1分钟轮询一次服务器

二、Configuration: discovery, name resolving

{
  "HostnameResolveMethod": "default",
  "MySQLHostnameResolveMethod": "@@hostname",
}
"HostnameResolveMethod": "cname": do CNAME resolving on hostname //主机名上的CNAME解析码
"HostnameResolveMethod": "default": no special resolving via net protocols 
"MySQLHostnameResolveMethod": "@@hostname": issue a select @@hostname
"MySQLHostnameResolveMethod": "@@report_host": issue a select @@report_host, requires report_host to be configured
"HostnameResolveMethod": "none" and "MySQLHostnameResolveMethod": "": do nothing. Never resolve. This may appeal to setups where everything uses IP addresses at all times.

三、Configuration: discovery, classifying servers

{
  "SlaveLagQuery": "select absolute_lag from meta.heartbeat_view",
  "DetectClusterAliasQuery": "select ifnull(max(cluster_name), '') as cluster_alias from meta.cluster where anchor=1",
  "DetectClusterDomainQuery": "select ifnull(max(cluster_domain), '') as cluster_domain from meta.cluster where anchor=1",
  "DataCenterPattern": "",
  "DetactDataCenterQuery": "select substring_index(substring_index(@@hostname, '-',3), '-', -1) as dc",
  "PhysicalEnvironmentPattern": "",
}

"SlaveLagQuery": 默认状况下，协调器使用SHOW SLAVE STATUS并接受1秒粒度值来表示延迟。然而，这种延迟并无考虑链式复制时的级联延迟。许多人使用自定义心跳机制，例如pt-heartbeat。这就提供了从master到sub-second的“绝对”延迟。
"DetectClusterAliasQuery": 可让orchestrator知道集群名称的查询

四、Configuration: recovery

{
  "RecoveryPeriodBlockSeconds": 3600,
  "RecoveryIgnoreHostnameFilters": [],
  "RecoverMasterClusterFilters": [
    "thiscluster",
    "thatcluster"
  ],
  "RecoverIntermediateMasterClusterFilters": [
    "*"
  ],
}

Orchestrator将自动恢复全部集群的中间主失败
Orchestrator将自动恢复两个指定集群的主故障;其余集群的主集群不会自动恢复。能够人为进行恢复。
一旦集群经历了恢复，orchestrator将在接下来的3600秒(1小时)内阻止自动恢复。这是一种anti-flapping机制。

{
  "ApplyMySQLPromotionAfterMasterFailover": true,
  "MasterFailoverLostInstancesDowntimeMinutes": 10,
  "FailMasterPromotionIfSQLThreadNotUpToDate": true,
  "DetachLostReplicasAfterMasterFailover": true,
}
"ApplyMySQLPromotionAfterMasterFailover": when true, orchestrator will reset slave all and set read_only=0 on promoted master. Default: true

4、经常使用命令

一、显示已知集群 ????如何使用ip，而不是hostname

# orchestrator -c clusters
# orchestrator -c clusters --config=/path/to/config.file

二、发现新的实例

# orchestrator -c discover -i 127.0.0.1:3306
# orchestrator -c discover -i 127.0.0.1:3306 --debug --stack

说明：--debug用来调试，--stack会在报错的地方打印出来追踪的代码堆

三、忘记一个实例

# orchestrator -c forget -i 127.0.0.1:22987

若一个slave断开了，复制不正常，可以使用该命令将其从集群中去掉

四、打印拓扑实例的ASCII树

# orchestrator -c topology -i vm-test1:3306

五、relocate移动一个副本到目的地下做为副本

# orchestrator -c relocate -i vm-test2:3310 -d vm-test2:3307

变为

# orchestrator -c relocate -i vm-test2:3308 -d vm-test2:3307

变为

六、relocate-replicas 移动一个副本下的全部副本到目的地下做为副本

# orchestrator -c relocate-replicas -i vm-test1:3307 -d vm-test2:3308

说明：可以使用--pattern来列出要移动的副本，默认为所有
注意每一个机器上要添加hosts解析

# orchestrator -c relocate-replicas -i vm-test2:3307 --pattern vm-test2:3310 -d vm-test2:3308

七、使实例为只读或者只写

# orchestrator -c set-read-only -i vm-test1:3307
 # orchestrator -c set-writeable -i vm-test1:3307

八、Start/stop slave

$ orchestrator -c stop-slave -i a.replica.8.instance.com
$ orchestrator -c start-slave -i a.replica.8.instance.com
$ orchestrator -c restart-slave -i a.replica.8.instance.com

九、吧副本向上移动，前提:该副本有grandparent

如：有A-B—C能够变为 A-B、A-C

# orchestrator -c move-up -i vm-test2:3310

变为

# orchestrator -c move-below -i 127.0.0.1:22988 -d 127.0.0.1:22990 --debug

十、把S2（以及它下面的S22）移动到另外一个S1下面

说明：S2和S1需属于同一级别

# orchestrator -c move-below -i vm-test2:3308 -d vm-test1:3307 --debug

十一、破坏恢复slave的binlog 坐标（gtid不适用）

$ orchestrator -c detach-replica -i a.replica.8.instance.com   //破坏
$ orchestrator -c reattach-replica -i a.replica.8.instance.com //恢复

5、配置orchestrator-client（128/129/130均可）

步骤一、配置环境

# export ORCHESTRATOR_API=http://192.168.225.130:3000/api

步骤二、linux下安装json解析工具jq

# wget https://github.com/stedolan/jq/releases/download/jq-1.5/jq-1.5.tar.gz 
# tar zxvf jq-1.5.tar.gz
# cd jq
# ./configure && make && sudo make install

步骤三、基础命令;

1.

# orchestrator-client -c help
# orchestrator-client -c which-api

2.列出master，集群

详情，见网址：https://github.com/github/orc...

# orchestrator-client -c api -path clusters 
# orchestrator-client -c clusters-alias      //master，集群名
//显示别名为vm-test1的集群的master
# orchestrator-client -c which-cluster-master -alias vm-test1 
//显示别名为vm-test1的集群下全部的实例
# orchestrator-client -c which-cluster-instances -alias vm-test1

3.显示已知集群

# orchestrator-client -c clusters

//发现、忘记实例

# orchestrator-client -c discover -i vm-test1:3306
# orchestrator-client -c forget -i vm-test1:3306

//列出实例的拓扑结构

# orchestrator-client -c topology -i vm-test1:3307

//relocate命令通用

6、故障转移

一、手动强制故障转移,即master downtimed，slave 双no，可是slave并无提高为master

# orchestrator-client -c force-master-failover --alias vm-test1:3306
# orchestrator-client -c force-master-failover -i vm-test1:3306

二、优雅的接管master

说明：原M：downtimed，show slave status能够看到做为原S的slave，可是为双no，由rw变为ro；
原S：若以前为ro，接管master后也是ro，show slave status 能够看到仍是做为原M的slave，且为双yes，

# orchestrator-client -c graceful-master-takeover -i vm-test2:3306 
//（cluster中某个机器host：port，也能够是vm-test1:3306）
# orchestrator-client -c graceful-master-takeover -i vm-test1 （cluster别名）
Command line: orchestrator-client -c graceful-master-takeover -alias mycluster -s designated.master.to.promote:3306

变为

7、高可用方式

方式一：synchronous replication backend

含义：假若有3个orchestrator node节点，每个node节点链接一个DB，这3个DB作的[galera|xtradb cluster|innodb cluster]，互相通讯保持同步。Orchestrator node节点之间不进行通讯。
Orchestrator/raft：假若有3个orchestrator node节点，每个node节点链接一个DB，这3个DB是互相独立的，不进行通讯。Orchestrator node节点之间经过raft识别进行通讯。

方式二：Orchestrator/raft

一、orchestrator/raft 概述

经过使用协商一致协议，orchestrator节点可以挑选出具备法定人数的领导，这意味着它不是孤立的。
例如，考虑一个3节点orchestrator/raft设置。一般状况下，三个节点会互相聊天，其中一个节点是稳定的被选出的leader。然而，面对网络分区，假设节点n1与节点n2和n3分开，能够保证leader不是n2就是n3。n1将不能成为leader，由于它没有法定人数（在一个3节点设置中，仲裁大小是2;在5个节点中设置仲裁大小为3）
服务节点：设置3个或5个orchestrator节点。其余数字也是合法的，但至少须要3个。

2.安装

（1）、在128/129/130上面分别安装orchestrator和orchestrator client ，配置文件加上raft，
启动 # nohup orchestrator http &
"RaftEnabled": true,
"RaftDataDir": "/data/orchestrator",
"RaftBind": "192.168.225.128",
"DefaultRaftPort": 10008,
"RaftNodes": [

"192.168.225.128",
"192.168.225.129",
"192.168.225.130"

]
（2）在须要监控的mysql集群上给128/129机器受权，以便orche帐户可访问
（3）配置orchestrator client

# export ORCHESTRATOR_API="http://192.168.225.130:3000/api http://192.168.225.129:3000/api http://192.168.225.128:3000/api"

配置完client后，client会自动选择出leader
（4）查看状态

关闭130的orchestrator，再次查看状态

三、注意事项

Orchestrator命令行不支持给定的raft设置，由于它直接与底层数据库交互，不参与raft识别。所以不能确保全部的raft成员均可以看到变动。
若要强制在orchestrator命令行执行命令，可加参数 --ignore-raft-setup，不过最好在leader端执行。

四、Orchestrator service

（1）单一的orchestrator节点拥有领导权，能够：运行恢复
（2）全部的节点将：
发现（探测）mysql 拓扑
运行故障检测
记录监控检测
（3）非leader 节点不能：
运行任意命令（eg：从新部署、开机停机）
按照人类请求运行恢复
处理客户端HTTP请求（可是一些端点，如负载均衡器和健康检查，是有效的）。

五、Orchestrator/raft

（1）添加新节点
虽然DB为空，不过也不须要作什么，启动后，过一段时间便可自动加入raft集群
也能够克隆原来的DB，使用备份恢复的方法，为新后端DB提供数据（没有必要）。
（2）替换node3
（原来是：node1，node2，node3，使用nodex替换node3）
关闭node3，node1和node2会运行正常，且在node1和node2选择出一个leader
建立好nodex，配置好后端数据库
修改node一、node二、nodex中的配置文件，RaftNodes: ["node1", "node2", "nodeX"]
启动nodex，重启node一、node2（不重启node2和3将不会识别出nodex）

8、Pseudo GTID

一、概述

Pseudo GTID是向二进制日志中注入唯一条目的方法，这样就能够在没有直接链接的状况下使用它们来匹配/同步副本，或者使用主服务器已损坏/死亡的副本。
Pseudo GTID对于没有GTID的用户颇有吸引力。Pseudo GTID具备GTID的大部分优势，但没有做出GTID所要求的承诺。使用Pseudo gtid，不管使用哪一个MySQL版本，您均可以保留现有的拓扑。

二、优点：

完成master故障转移。
完成中间master故障转移。
任意重构，将副本从一个地方迁移到另外一个地方(甚至那些没有二进制日志记录的副本)。
厂商中立;在Oracle和MariaDB上工做，甚至二者的结合。
没有配置更改。复制设置保持原样。
没有承诺。您能够选择随时不使用Pseudo gtid;不要再写P-GTID了。
P-gtid意味着对运行的副本进行安全的复制:log-slave-updates sync_binlog=1
与MySQL 5.6上的GTID不一样，服务器不须要运行打开log-slave-updates，不过建议最好打开。

三、开启P-GTID

{
"AutoPseudoGTID": true,
}
还须要在mysql机器上受权
GRANT DROP ON _pseudo_gtid_.* to 'orchestrator'@'orch_host';
若是想只在特定集群上开启P-GTID功能，只需在特定集群开通权限便可。

四、局限

（1）不支持 active-active master-master模式
但可支持active-passive master-master模式，Pseudo-GTID支持只注入到active master上
（2）没有开启log-slave-update的复本，能够经过中继日志同步。MySQL默认对中继日志的强制清除意味着，若是master发生崩溃，副本的中继日志也刚刚被清除，而后，在中继日志中没有用于修复拓扑的伪Pseudo-GTID信息。
频繁注入P-GTID能够缓解这一问题。咱们每5秒注入一次P-GTID
（3）当副本读取基于statement的复制relay logs和转译基于Row的复制binlog logs，而后，orchestrator经过中继日志匹配P-gtid。有关中继日志的限制，请参见（2）
（4）不能匹配两个服务器，其中一个是彻底RBR(接收和写入基于行的复制日志)，另外一个是彻底SBR。这种状况可能发生在由基于SBR的拓扑迁移到RBR拓扑时；
（5）一个边界场景下（当从5.6复制到5.7时，5.7向binlog 添加了匿名语句）这时orchestrator知道如何跳过这些语句。然而，若是5.6->5.7复制中断(eg：master dead)，而且匿名语句是binlog中的最后一条语句，此时，orchestrator没法匹配服务器。

五、说明：

orchestrator-client -c relocate -i some.server.to.relocate -d under.some.other.server
Relocate命令将自动识别是否开启了Pseudo_GTID

9、故障检测

Orchestrator使用总体分析master 和中间master的故障。不一样于按照多长时间联系不到master来判定错误，orchestrator。当全部master的副本都赞成没法链接master时，复制拓扑就被破坏了，故障转移是合理的。
要诊断一个dead master，orchestrator必须：
A.没法链接该master; &&
B.能够联接master的副本，并确认副本也不能看到master

一、检测和恢复

检测不必定会致使恢复，有些状况下是不但愿恢复的：
A.该集群不在自动故障转移列表
B.管理员用户已经指出，不该该在特定的服务器上进行恢复。
C.用户禁用了恢复
D.在同一集群上的上一次恢复在不久前完成，而且anti-flapping发生
E.故障类型认为不值得恢复。

在特定场景中，检测后会当即进行恢复，其余时候，恢复多是在长时间的检测以后

二、检测失败的场景：

（1）dead masterMaster链接失败Master的全部副本都链接失败