Orchestrator管理mysql复制

24次阅读

共计 11062 个字符,预计需要花费 28 分钟才能阅读完成。

……………………………………………………………………… 系统:centos7Mysql:5.7.22IP:192.168.225.130,端口 3306(存放 orchestrator 的扩普状态)M1:主:192.168.225.128:3306 —— 从:192.168.225.129:3306M2:主:192.168.225.128:3307 —— 从:192.168.225.129:3307………………………………………………………………………
一、简介
orchestrator – 对 MySQL 复制拓扑管理并可视化的工具。支持:
 检测和审查复制集群
 安全拓扑重构: 转移服务于另外一台计算机的系统拓扑 S
 整洁的拓扑可视化
 复制问题可视化
 通过简单的拖拽修改拓扑
 维护模式声明和执行
 审计操作
重构拓扑只需要简单的拖拽。Orchestrator 会保证安全, 并且禁止非法复制拓扑。Orchestrator 是高可用性管理工具,它提供了发现 MySQL 环境的复制拓扑能力,通过上下链接来识别主从。它也可以通过 GUI 重构复制拓扑结构,提供一个拖放界面将从设备提升为主设备,这是一个非常安全的操作。事实上,Orchestrator 拒绝任何非法操作,以免破坏系统。最后,Orchestrator 在节点遭遇失败时可以支持恢复,因为它使用状态的概念智能选择正确的恢复方法,并决定使用适当的主升级过程。
二、安装配置步骤
操作步骤
步骤 1、下载安装
网址:https://github.com/github/orc…
# 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
步骤 2、添加 host
在 130 上面添加 host,vim /etc/hosts192.168.225.128 vm-test1192.168.225.129 vm-test2192.168.225.130 vm-test3
步骤 3、Mysql 主从上面配置文件配置 report_host
DiscoverByShowSlaveHosts”: ture 这种情况下,必须配置 report_host$ vim /etc/my_3306.cnfreport_host=192.168.225.128 //ip 为自身的 ip 说明: 不加 report_host,show slave hosts 不会显示 host,会导致程序报错的
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’;
步骤 5、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. 
步骤 6、修改配置文件(存储 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,默认会调用
步骤 7、启动 orchestrator
$ cd /usr/local/orchestrator/$ nohup orchestrator http &
步骤 8、显示已知的集群
$ orchestrator -c clusters // 第一次执行成功后库 orchestrator 中就出现很多表,以后执行会显示出已经知道的集群拓扑 $ orchestrator -c clusters –config=/path/to/config.file // 若配置文件在其他路径

步骤 9、发现 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

三、配置 config
1、轮询时间设置
InstancePollSeconds,默认是 1 分钟轮询一次服务器
2、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.
3、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 知道集群名称的查询
4、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
四、常用命令
1、显示已知集群 ???? 如何使用 ip,而不是 hostname
# orchestrator -c clusters
# orchestrator -c clusters –config=/path/to/config.file

2、发现新的实例
# orchestrator -c discover -i 127.0.0.1:3306
# orchestrator -c discover -i 127.0.0.1:3306 –debug –stack
说明:–debug 用来调试,–stack 会在报错的地方打印出来追踪的代码堆
3、忘记一个实例
# orchestrator -c forget -i 127.0.0.1:22987
若一个 slave 断开了,复制不正常,可使用该命令将其从集群中去掉
4、打印拓扑实例的 ASCII 树
# orchestrator -c topology -i vm-test1:3306

5、relocate 移动一个副本 到 目的地 下作为副本
# orchestrator -c relocate -i vm-test2:3310 -d vm-test2:3307
变为
# orchestrator -c relocate -i vm-test2:3308 -d vm-test2:3307

变为
6、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

7、使实例为只读或者只写
# orchestrator -c set-read-only -i vm-test1:3307
# orchestrator -c set-writeable -i vm-test1:3307
8、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
9、吧副本向上移动,前提: 该副本有 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
10、把 S2(以及它下面的 S22)移动到另一个 S1 下面
说明:S2 和 S1 需属于同一级别
# orchestrator -c move-below -i vm-test2:3308 -d vm-test1:3307 –debug
11、破坏恢复 slave 的 binlog 坐标(gtid 不适用)
$ orchestrator -c detach-replica -i a.replica.8.instance.com // 破坏
$ orchestrator -c reattach-replica -i a.replica.8.instance.com // 恢复

五、配置 orchestrator-client(128/129/130 都可)
步骤 1、配置环境
# export ORCHESTRATOR_API=http://192.168.225.130:3000/api
步骤 2、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
步骤 3、基础命令;
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 命令通用
六、故障转移
1、手动强制故障转移, 即 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
2、优雅的接管 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
变为

七、高可用方式
方式一: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
1、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,再次查看状态
3、注意事项
Orchestrator 命令行不支持给定的 raft 设置,因为它直接与底层数据库交互,不参与 raft 识别。因此不能确保所有的 raft 成员都可以看到变更。若要强制在 orchestrator 命令行执行命令,可加参数 –ignore-raft-setup,不过最好在 leader 端执行。
4、Orchestrator service
(1)单一的 orchestrator 节点拥有领导权,可以:运行恢复(2)所有的节点将:发现(探测)mysql 拓扑运行故障检测记录监控检测(3)非 leader 节点不能:运行任意命令(eg:重新部署、开机停机)按照人类请求运行恢复处理客户端 HTTP 请求(但是一些端点,如负载均衡器和健康检查,是有效的)。
5、Orchestrator/raft
(1)添加新节点虽然 DB 为空,不过也不需要做什么,启动后,过一段时间即可自动加入 raft 集群也可以克隆原来的 DB,使用备份恢复的方法,为新后端 DB 提供数据(没有必要)。(2)替换 node3(原来是:node1,node2,node3,使用 nodex 替换 node3)关闭 node3,node1 和 node2 会运行正常,且在 node1 和 node2 选择出一个 leader 创建好 nodex,配置好后端数据库修改 node1、node2、nodex 中的配置文件,RaftNodes: [“node1”, “node2”, “nodeX”]启动 nodex,重启 node1、node2(不重启 node2 和 3 将不会识别出 nodex)
八、Pseudo GTID
1、概述
Pseudo GTID 是向二进制日志中注入惟一条目的方法,这样就可以在没有直接连接的情况下使用它们来匹配 / 同步副本,或者使用主服务器已损坏 / 死亡的副本。Pseudo GTID 对于没有 GTID 的用户很有吸引力。Pseudo GTID 具有 GTID 的大部分优点,但没有作出 GTID 所要求的承诺。使用 Pseudo gtid,无论使用哪个 MySQL 版本,您都可以保留现有的拓扑。
2、优势:
完成 master 故障转移。完成中间 master 故障转移。任意重构,将副本从一个地方迁移到另一个地方(甚至那些没有二进制日志记录的副本)。厂商中立; 在 Oracle 和 MariaDB 上工作,甚至两者的结合。没有配置更改。复制设置保持原样。没有承诺。您可以选择随时不使用 Pseudo gtid; 不要再写 P -GTID 了。P-gtid 意味着对运行的副本进行安全的复制:log-slave-updates sync_binlog= 1 与 MySQL 5.6 上的 GTID 不同,服务器不需要运行打开 log-slave-updates,不过建议最好打开。
3、开启 P -GTID
{“AutoPseudoGTID”: true,}还需要在 mysql 机器上授权 GRANT DROP ON _pseudo_gtid_.* to ‘orchestrator’@’orch_host’; 如果想只在特定集群上开启 P -GTID 功能,只需在特定集群开通权限即可。
4、局限
(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 无法匹配服务器。
5、说明:
orchestrator-client -c relocate -i some.server.to.relocate -d under.some.other.serverRelocate 命令将自动识别是否开启了 Pseudo_GTID
九、故障检测
Orchestrator 使用整体分析 master 和中间 master 的故障。不同于按照多长时间联系不到 master 来断定错误,orchestrator。当所有 master 的副本都同意无法连接 master 时,复制拓扑就被破坏了,故障转移是合理的。要诊断一个 dead master,orchestrator 必须:A. 无法连接该 master; && B. 可以联接 master 的副本,并确认副本也不能看到 master
1、检测和恢复
检测不一定会导致恢复,有些情况下是不希望恢复的:A. 该集群不在自动故障转移列表 B. 管理员用户已经指出,不应该在特定的服务器上进行恢复。C. 用户禁用了恢复 D. 在同一集群上的上一次恢复在不久前完成,并且 anti-flapping 发生 E. 故障类型认为不值得恢复。
在特定场景中,检测后会立即进行恢复,其他时候,恢复可能是在长时间的检测之后
2、检测失败的场景:
(1)dead masterMaster 连接失败 Master 的所有副本都连接失败

正文完
 0