13518219792
网站建设资讯

NEWS

网站建设资讯

【沃趣科技】MySQL高可用工具Orchestrator系列二：复制拓扑的发现

沃趣科技作为国内领先的数据库云平台解决方案提供商，一直致力于企业级数据库云平台产品的研发，为用户提供高性能、高可用、可扩展的的数据库云环境及不同业务场景需求的数据库平台，满足客户对极致性能、数据安全、容灾备份、业务永续等需求。沃趣科技凭借专业的团队，优质的产品，前沿的技术，贴心的服务赢得了客户的信任与尊重，也获得了市场的认同。

成都创新互联公司主要从事网站设计、网站制作、网页设计、企业做网站、公司建网站等业务。立足成都服务类乌齐,十载网站建设经验,价格优惠、服务专业,欢迎来电咨询建站服务:028-86922220

————————————————————————————————————

背   景

上篇文章讲了orchestrator单节点的安装。本篇文章我们继续探索orchestrator的旅程，讲一讲orchestrator是如何实现数据库实例复制拓扑的发现。

给定实例，如何发现自己

这里涉及到两个参数：HostnameResolveMethod、MySQLHostnameResolveMethod

HostnameResolveMethod有三个选项："cname"、"default"、"none"

  • cname:通过CNAME做域名解析（resolve hostname）

  • default:不做特别的解析, no special resolving via net protocols

  • none:do nothing

MySQLHostnameResolveMethod有三个选项："@@hostname"、"@@report_host"、""

  • @@hostname: select @@hostname

  • @@report_host: select @@report_host

  • "": do nothing

这里会有一个问题需要注意：

假设生产环境存在两台数据库服务器主机名一样，比如都是localhost.localdomain；并且，orch配置参数HostnameResolveMethod使用了默认的"default"、MySQLHostnameResolveMethod使用了默认的"@@hostname"。那么，orch在 找的时候，会将用户输入的I P 地址解析成hostname，但因为存在两台hostname一样的机器，所以可能会导致出错，即orch找不到正确的那台服务器。

因此，最好保证线上环境，不同服务器的主机名都不同。

给定主库，如何发现从库

由参数DiscoverByShowSlaveHosts控制。如果为true，则会尝试先通过show slave hosts命令去发现从库。此时会有三种情况。

  • 从库设置了正确的report_host，show slave hosts中的host字段显示正确的IP，则直接通过show slave hosts发现从库。

  • 从库设置了错误的report_host，show slave hosts中的host字段显示错误的IP，则orchestrator找不到从库。

         - 如果IP ping不通，则报如下信息：

[mysql] 2019/10/29 17:57:24 driver.go:81: net.Error from Dial()': dial tcp 10.10.30.222:3306: i/o timeout
[mysql] 2019/10/29 17:57:25 driver.go:81: net.Error from Dial()': dial tcp 10.10.30.222:3306: i/o timeout
[mysql] 2019/10/29 17:57:26 driver.go:81: net.Error from Dial()': dial tcp 10.10.30.222:3306: i/o timeout
2019-10-29 17:57:26 ERROR driver: bad connection

- 如果IP ping的通，则可能报如下信息：

2019-10-29 18:15:34 ERROR dial tcp 10.10.30.228:3306: connect: connection refused
2019-10-29 18:15:40 ERROR dial tcp 10.10.30.228:3306: connect: connection refused
2019-10-29 18:15:46 ERROR dial tcp 10.10.30.228:3306: connect: connection refused
2019-10-29 18:15:52 ERROR dial tcp 10.10.30.228:3306: connect: connection refused
// 或者
2019-10-29 18:11:11 ERROR Error 1045: Access denied for user 'orchestrator'@'10.10.30.146' (using password: YES)
WARNING: NamedStopwatch.Stop("instance") IsRunning is false
2019-10-29 18:11:17 ERROR Error 1045: Access denied for user 'orchestrator'@'10.10.30.146' (using password: YES)
WARNING: NamedStopwatch.Stop("instance") IsRunning is false

  • 从库没有设置report_host，show slave hosts中的host字段显示为空，则通过processlist发现从库。

     - 此时，会报如下信息：

2019-08-06 18:12:49 ERROR ReadTopologyInstance(10.10.30.129:3306) show slave hosts: ReadTopologyInstance(10.10.30.129:3306) 'show slave hosts' returned row with : <,3306>

如果为false，则通过information_schema.processlist去发现从库。

select substring_index(host, ':', 1) as slave_hostname from information_schema.processlist where command IN ('Binlog Dump', 'Binlog Dump GTID');

给定从库，如何发现主库

通过show slave status命令去发现主库。

DiscoveryByShowSlaveHosts意义

既然show slave status命令显示的host不一定准确，那为什么还要加入DiscoverByShowSlaveHosts这个参数呢？

这个有几种原因：

首先，MaxScale不支持PROCESSLIST，因此SHOW SLAVE HOSTS是唯一的选择。

更重要的是，如果只是通过information_schema.processlist去发现从库，master无法知道replica监听的是哪个端口。show processlist只会显示复制进程使用的套接字端口，而不是replica实例监听的端口。所以需要用户在配置文件中设置好report_host和report_port参数，并且在orch的配置文件中将参数DiscoverByShowSlaveHosts设置为true。

注意点

report_port  

report_port其实可以不在mysql配置文件中配置，因为report_port默认会被设置成slave的端口。

The default value for this option is the port number actually used by the slave. This is also the default value displayed by SHOW SLAVE HOSTS.

DiscoverByShowSlaveHosts设置为false  

这种情况下，orch通过information_schema.processlist去发现从库。如果slave的端口和master的不一样，orch会假设从库监听的是和主库相同的端口，那么这个slave就无法被orch自动发现，需要人工手动进行发现：

命令行：orchestrator-client -b hjj:hjj -c discover -i 10.10.30.230:3307

web界面：clusters/discover

实际生产环境中有可能主从端口不是同一个，所以DiscoverByShowSlaveHosts不能为false。

DiscoverByShowSlaveHosts设置为true

如果没有使用默认的3306端口，比如slave用的是3308端口，然后在mysql的配置文件中又没有配置report_host参数，orch会先尝试通过show slave hosts发现从库，但会报错，然后再通过processlist去发现从库。这个时候orch会假设从库监听的是和主库相同的端口（并不会使用show slave hosts中得到的port的信息，因为没有设置report_host，就无法将port和host对应），如果此时主库使用的是3306端口，那么这个slave就自动发现不了。

##这里我的master是10.10.30.230:3307，slave是10.10.30.249:3306，且从库没有设置report_host
// show slave hosts报错信息如下
2019-10-29 17:37:18 ERROR ReadTopologyInstance(10.10.30.230:3307) show slave hosts: ReadTopologyInstance(10.10.30.230:3307) 'show slave hosts' returned row with : <,3306>
// 显示10.10.30.249:3307连不上，说明通过processlist发现从库用的是和主库相同的端口
2019-10-29 17:37:24 ERROR dial tcp 10.10.30.249:3307: connect: connection refused

此时需要手动进行发现：

命令行：orchestrator-client -b hjj:hjj -c discover -i 10.10.30.249:3306

web界面：clusters/discover

结  论

综上考虑，我们需要将DiscoverByShowSlaveHosts设置为true，并且至少在mysql配置文件中设置正确的report_host。

参考文章

https://github.com/github/orchestrator/blob/master/docs/supported-topologies-and-versions.md
http://code.openark.org/blog/mysql/the-importance-of-report_host-report_port


|  作者简介

韩杰  沃趣科技高级数据库工程师

专注MySQL数据库三年，精通MySQL体系结构，数据库优化，trouble shooting。服务过多家银行客户，熟悉银行业务及系统下数据库不同架构使用场景。熟悉MySQL主从复制原理，及应用的各种高可用场景。


本文名称：【沃趣科技】MySQL高可用工具Orchestrator系列二：复制拓扑的发现
网页网址：http://cdweb.net/article/jiippp.html

其他资讯