db mysql high available / Orchestrator
作者:互联网
s
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
安装:
./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