首页 > 数据库> 文章详细

db mysql high available / Orchestrator

2022-04-08 17:33:12 阅读：246 来源： 互联网

标签：available Orchestrator 实例 high cluster host 复制 MySQL orchestrator

https://github.com/github/orchestrator

MySQL高可用复制管理工具 —— Orchestrator介绍

https://www.cnblogs.com/zhoujinyi/p/10387581.html

背景

在MySQL高可用架构中，目前使用比较多的是Percona的PXC，Galera以及MySQL 5.7之后的MGR等，其他的还有的MHA，今天介绍另一个比较好用的MySQL高可用复制管理工具：Orchestrator（orch）。

Orchestrator（orch）：go编写的MySQL高可用性和复制拓扑管理工具，支持复制拓扑结构的调整，自动故障转移和手动主从切换等。后端数据库用MySQL或SQLite存储元数据，并提供Web界面展示MySQL复制的拓扑关系及状态，通过Web可更改MySQL实例的复制关系和部分配置信息，同时也提供命令行和api接口，方便运维管理。相对比MHA来看最重要的是解决了管理节点的单点问题，其通过raft协议保证本身的高可用。GitHub的一部分管理也在用该工具进行管理。关于Orchestrator更详细的介绍可以看Github的介绍，大致的特点有：

① 自动发现MySQL的复制拓扑，并且在web上展示。

② 重构复制关系，可以在web进行拖图来进行复制关系变更。

③ 检测主异常，并可以自动或手动恢复，通过Hooks进行自定义脚本。

④ 支持命令行和web界面管理复制。

环境：

系统：
Ubuntu 16.04

三台主机：
test1:192.168.163.131
test2:192.168.163.132
test3:192.168.163.133

后端MySQL端口：3306
测试MySQL端口：3307

安装

根据需要下载合适的包进行安装，本文是基于Ubuntu16.04安装的，下载好deb包后，需要安装jq的依赖包（apt-get install jq）。安装完成之后，相应的目录为：

/usr/local/orchestrator
-rwxr-xr-x 1 root root  20M 1月  16 21:49 orchestrator
-rw-r--r-- 1 root root 5.1K 1月  16 21:49 orchestrator-sample.conf.json
-rw-r--r-- 1 root root 4.4K 1月  16 21:49 orchestrator-sample-sqlite.conf.json
drwxr-xr-x 7 root root 4.0K 2月  15 19:03 resources

orchestrator：应用程序

*.json：默认的配置模板

resources：orchestrator相关的文件：client、web、伪GTID等相关文件。

配置

配置的相关参数了解后，大致说明如下（可能会有偏差、后续不定时更新）：

View Code

按照本文的测试用例，定制了一个相关的模板（/etc/orchestrator.conf.json）：

View Code

这里列出说明几个比较重要的参数：

ListenAddress：　　
web界面的http端口
MySQLOrchestratorHost
orch后端数据库地址
MySQLOrchestratorPort
orch后端数据库端口
MySQLOrchestratorDatabase
orch后端数据库名
MySQLOrchestratorUser
orch后端数据库用户名（明文）
MySQLOrchestratorPassword
orch后端数据库密码（明文）
MySQLOrchestratorCredentialsConfigFile
后端数据库用户名密码的配置文件「 "MySQLOrchestratorCredentialsConfigFile": "/etc/mysql/orchestrator-backend.cnf" 」，格式：
```
[client]
user=orchestrator_srv
password=${ORCHESTRATOR_PASSWORD}
```
后端MySQL数据库的用户权限需要是：
```
CREATE USER 'orchestrator_srv'@'orc_host' IDENTIFIED BY 'orc_server_password';
GRANT ALL ON orchestrator.* TO 'orchestrator_srv'@'orc_host';
```
MySQLTopologyUser
被管理的MySQL的用户（明文）
MySQLTopologyPassword
被管理的MySQL的密码（密文）
MySQLTopologyCredentialsConfigFile
被管理的MySQL的用户密码配置文件「"/etc/mysql/orchestrator-topology.cnf"」，格式：
```
[client]
user=orchestrator_srv
password=${ORCHESTRATOR_PASSWORD}
```

被管理MySQL数据库的用户权限需要是：

CREATE USER 'orchestrator'@'orc_host' IDENTIFIED BY 'orc_topology_password';
GRANT SUPER, PROCESS, REPLICATION SLAVE, REPLICATION CLIENT, RELOAD ON *.* TO 'orchestrator'@'orc_host';
GRANT SELECT ON meta.* TO 'orchestrator'@'orc_host';
GRANT SELECT ON ndbinfo.processes TO 'orchestrator'@'orc_host'; -- Only for NDB Cluster

InstancePollSeconds
orch探测MySQL的间隔秒数
MySQLConnectTimeoutSeconds
orch连接MySQL的超时时间
MySQLOrchestratorReadTimeoutSeconds
后端MySQL读超时时间
MySQLTopologyReadTimeoutSeconds
被管理MySQL读超时时间，用于除发现查询以外的所有查询
MySQLDiscoveryReadTimeoutSeconds
被管理MySQL读超时时间，用于发现
DefaultInstancePort
被管理MySQL的默认端口
DiscoverByShowSlaveHosts
通过show slave hosts 来发现拓扑结构
UnseenInstanceForgetHours
忽略看不见的实例的小时数
HostnameResolveMethod
解析主机名，使用主机名：default；不解析用none，直接用IP
MySQLHostnameResolveMethod
解析主机名，发出select @@hostname；发出select @@report_host（需要配置report_host）。不解析用""，直接用IP。
InstanceBulkOperationsWaitTimeoutSeconds
进行批量操作时等待单个实例的时间
ReasonableReplicationLagSeconds
复制延迟高于该值表示异常
VerifyReplicationFilters
在拓扑重构之前检查复制筛选器
ReasonableMaintenanceReplicationLagSeconds
复制延迟高于该值会上下移动调整MySQL拓扑
CandidateInstanceExpireMinutes
该时间之后，使用实例作为候选从库（在主故障转移时提升）的建议到期
ReplicationLagQuery（SlaveLagQuery）
使用SHOW SLAVE STATUS进行延迟判断，力度为秒。使用pt-heartbeat。这提供了亚秒级的力度，允许自己设置查询「 "select absolute_lag from meta.heartbeat_view"」
DetectClusterAliasQuery
查询集群别名的query，信息放到每个被管理实例的meta库的cluster表中「"select ifnull(max(cluster_name), '') as cluster_alias from meta.cluster where anchor=1"」
DetectClusterDomainQuery
查询集群Domain的query，信息放到每个被管理实例的meta库的cluster表中「select ifnull(max(cluster_domain), '') as cluster_domain from meta.cluster where anchor=1」
DetectInstanceAliasQuery
查询实例的别名
DetectDataCenterQuery
查询数据中心的query，信息放到每个被管理实例的meta库的cluster表中「"select substring_index(substring_index(@@hostname, '-',3), '-', -1) as dc"」
DetachLostReplicasAfterMasterFailover（DetachLostSlavesAfterMasterFailover）
是否强制分离在主恢复中不会丢失的从库
DetectSemiSyncEnforcedQuery
检测是否强制半同步
AutoPseudoGTID
是否自动将Pseudo-GTID条目注入主服务器，对于没用GTID的复制推荐使用。要是使用了GTID的复制，设置“false”即可。
RecoveryPeriodBlockSeconds
在该时间内再次出现故障，不会进行迁移，避免出现并发恢复和不稳定。
FailureDetectionPeriodBlockMinutes
在该时间内再次出现故障，不会被多次发现。
RecoverMasterClusterFilters
只对匹配这些正则表达式模式的集群进行主恢复（“*”模式匹配所有）。
RecoverIntermediateMasterClusterFilters
只对匹配这些正则表达式模式的集群进行主恢复（“*”模式匹配所有）。
OnFailureDetectionProcesses
检测故障转移时执行，属于Hooks。
PreGracefulTakeoverProcesses
在主变为只读之前立即执行，属于Hooks。
PreFailoverProcesses
在执行恢复操作之前立即执行，属于Hooks。
PostMasterFailoverProcesses
在主恢复成功结束时执行，属于Hooks。
PostFailoverProcesses
在成功恢复结束时执行，属于Hooks。
PostUnsuccessfulFailoverProcesses
在任何不成功的恢复结束时执行，属于Hooks。
PostIntermediateMasterFailoverProcesses
在成功的中间主恢复结束时执行，属于Hooks。
PostGracefulTakeoverProcesses
在旧主位于新晋升的主之后执行，属于Hooks。
CoMasterRecoveryMustPromoteOtherCoMaster
当'false'时，任何实例都可以得到提升；当'true'时，将提升共同主人否则失败。
ApplyMySQLPromotionAfterMasterFailover
将重置slave all并在提升的master上设置read_only = 0，默认true
PreventCrossDataCenterMasterFailover
如果为true（默认值：false），则不允许跨DC主故障转移，orchestrator将尽其所能仅在同一DC内进行故障转移，否则不进行故障转移。
MasterFailoverDetachReplicaMasterHost（MasterFailoverDetachSlaveMasterHost）
否应该在新升级的master上发出detach-replica-master-host，这样可以确保新master不会尝试复制正常之后的旧的master。如果参数ApplyMySQLPromotionAfterMasterFailover为True，则该参数无意义。
MasterFailoverLostInstancesDowntimeMinutes
主故障转移后丢失的任何服务器停机的分钟数（包括失败的主和丢失的从）。 0表示禁用。
PostponeReplicaRecoveryOnLagMinutes（PostponeSlaveRecoveryOnLagMinutes）
在崩溃恢复时，延迟超过给定分钟的从库在主被选出后才复活。值为0将禁用此功能。
BackendDB
后端数据库类型。
RaftEnabled
是否开启Raft，保证orch的高可用。
RaftDataDir
Raft的数据目录。
RaftBind
Raft 的 bind地址。
DefaultRaftPort
Raft的端口。
RaftNodes
Raft的节点。
ConsulAddress
Consul的地址。
ConsulAclToken
Consul的token。

运行部署

环境：

　在三台测试机上各自安装MySQL2个实例：orch用的后端MySQL（3306）和被orch管理的MySQL（3307）。按照给出的配置模板，首先在后端数据库的实例上创建账号：

CREATE USER 'orchestrator'@'127.0.0.1' IDENTIFIED BY '123456';
GRANT ALL ON orchestrator.* TO 'orchestrator'@'127.0.0.1';

再在被管理的MySQL（3307）实例上创建账号：

CREATE USER 'orchestrator'@'%' IDENTIFIED BY 'Aa123456';
GRANT SUPER, PROCESS, REPLICATION SLAVE, RELOAD ON *.* TO 'orchestrator'@'%';
GRANT SELECT ON mysql.slave_master_info TO 'orchestrator'@'%';
GRANT SELECT ON meta.* TO 'orchestrator'@'orc_host';

其中meta库的作用是自己的query所用到的，如：cluster、pseudo_gtid_status等，后面会有相关说明。

到此，关于orch的环境已经准备完毕，最后只需要把被管理的3台MySQL部署成一主二从即可（rep）:

Master：192.168.163.131:3307
Slave  ：192.168.163.132:3307
Slave  ：192.168.163.133:3307

最后，因为配置文件里写的是域名(hostname)，所以需要修改三台被管理MySQL的hosts。即：

192.168.163.131 test1
192.168.163.132 test2
192.168.163.133 test3

安装：

1. 开启orchestrator

./orchestrator --debug --config=/etc/orchestrator.conf.json http

2. 把配置好的复制实例加入到orchestrator，因为orch可以自动发现整个拓扑的所有实例，所以只需要添加任意一台实例即可，如果没有发现的话可以再添加。

在web上添加（导航里的Clusters -> Discover）：

添加完成之后，最终的结构图如下：

总结：

限于篇幅的原因，本文先对orchestrator进行参数和部署做些简单的说明，对于一些Failover和HA在放在下一篇「MySQL高可用复制管理工具 —— Orchestrator使用」中进行介绍。

参考文档：

https://github.com/github/orchestrator

https://www.percona.com/blog/2016/03/08/orchestrator-mysql-replication-topology-manager/

end

标签：available,Orchestrator,实例,high,cluster,host,复制,MySQL,orchestrator
来源： https://www.cnblogs.com/lindows/p/16118523.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

ICode9

db mysql high available / Orchestrator

背景

环境：

安装

配置

运行部署

环境：

安装：

总结：

参考文档：