………………………………………………………………………系统: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_hostDiscoverByShowSlaveHosts": 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三、配置config1、轮询时间设置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:33065、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:33087、使实例为只读或者只写 # orchestrator -c set-read-only -i vm-test1:3307 # orchestrator -c set-writeable -i vm-test1:33078、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.com9、吧副本向上移动，前提:该副本有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 –debug10、把S2（以及它下面的S22）移动到另一个S1下面说明：S2和S1需属于同一级别# orchestrator -c move-below -i vm-test2:3308 -d vm-test1:3307 –debug11、破坏恢复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-test13.显示已知集群# 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:33062、优雅的接管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/raft1、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 GTID1、概述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的副本，并确认副本也不能看到master1、检测和恢复检测不一定会导致恢复，有些情况下是不希望恢复的：A.该集群不在自动故障转移列表B.管理员用户已经指出，不应该在特定的服务器上进行恢复。C.用户禁用了恢复D.在同一集群上的上一次恢复在不久前完成，并且anti-flapping发生E.故障类型认为不值得恢复。在特定场景中，检测后会立即进行恢复，其他时候，恢复可能是在长时间的检测之后2、检测失败的场景：（1）dead masterMaster连接失败Master的所有副本都连接失败