12-09
12-09
12-09
12-09
12-09
12-09
12-09
12-09
12-09
12-09
12-09
12-09
ADADADADAD
mysql数据库 时间:2024-12-03 12:14:16
作者:文/会员上传
12-09
12-09
12-09
12-09
12-09
12-09
12-09
12-09
12-09
12-09
12-09
12-09
沃趣科技作为国内领先的数据库云平台解决方案提供商,一直致力于企业级数据库云平台产品的研发,为用户提供高性能、高可用、可扩展的的数据库云环境及不同业务场景需求的数据库
以下为本文的正文内容,内容仅供参考!本站为公益性网站,复制本文以及下载DOC文档全部免费。
沃趣科技作为国内领先的数据库云平台解决方案提供商,一直致力于企业级数据库云平台产品的研发,为用户提供高性能、高可用、可扩展的的数据库云环境及不同业务场景需求的数据库平台,满足客户对极致性能、数据安全、容灾备份、业务永续等需求。沃趣科技凭借专业的团队,优质的产品,前沿的技术,贴心的服务赢得了客户的信任与尊重,也获得了市场的认同。
————————————————————————————————————
背 景上篇文章讲了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/2917:57:24driver.go:81:net.ErrorfromDial()':dialtcp10.10.30.222:3306:i/otimeout
[mysql]2019/10/2917:57:25driver.go:81:net.ErrorfromDial()':dialtcp10.10.30.222:3306:i/otimeout
[mysql]2019/10/2917:57:26driver.go:81:net.ErrorfromDial()':dialtcp10.10.30.222:3306:i/otimeout
2019-10-2917:57:26ERRORdriver:badconnection
- 如果IP ping的通,则可能报如下信息:
2019-10-2918:15:34ERRORdialtcp10.10.30.228:3306:connect:connectionrefused
2019-10-2918:15:40ERRORdialtcp10.10.30.228:3306:connect:connectionrefused
2019-10-2918:15:46ERRORdialtcp10.10.30.228:3306:connect:connectionrefused
2019-10-2918:15:52ERRORdialtcp10.10.30.228:3306:connect:connectionrefused
//或者
2019-10-2918:11:11ERRORError1045:Accessdeniedforuser'orchestrator'@'10.10.30.146'(usingpassword:YES)
WARNING:NamedStopwatch.Stop("instance")IsRunningisfalse
2019-10-2918:11:17ERRORError1045:Accessdeniedforuser'orchestrator'@'10.10.30.146'(usingpassword:YES)
WARNING:NamedStopwatch.Stop("instance")IsRunningisfalse
从库没有设置report_host,show slave hosts中的host字段显示为空,则通过processlist发现从库。
- 此时,会报如下信息:
2019-08-0618:12:49ERRORReadTopologyInstance(10.10.30.129:3306)showslavehosts:ReadTopologyInstance(10.10.30.129:3306)'showslavehosts'returnedrowwith<host,port>:<,3306>
如果为false,则通过information_schema.processlist去发现从库。
selectsubstring_index(host,':',1)asslave_hostnamefrominformation_schema.processlistwherecommandIN('BinlogDump','BinlogDumpGTID');
通过show slave status命令去发现主库。
既然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的端口。
Thedefaultvalueforthisoptionistheportnumberactuallyusedbytheslave.ThisisalsothedefaultvaluedisplayedbySHOWSLAVEHOSTS.
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
//showslavehosts报错信息如下
2019-10-2917:37:18ERRORReadTopologyInstance(10.10.30.230:3307)showslavehosts:ReadTopologyInstance(10.10.30.230:3307)'showslavehosts'returnedrowwith<host,port>:<,3306>
//显示10.10.30.249:3307连不上,说明通过processlist发现从库用的是和主库相同的端口
2019-10-2917:37:24ERRORdialtcp10.10.30.249:3307:connect:connectionrefused
此时需要手动进行发现:
命令行: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主从复制原理,及应用的各种高可用场景。
11-20
11-19
11-20
11-20
11-20
11-19
11-20
11-20
11-19
11-20
11-19
11-19
11-19
11-19
11-19
11-19