MySQL高可用工具Orchestrator：复制拓扑的发现

标签：slave show 拓扑 host 3308 MySQL report Orchestrator 从库

1、orchestrator如何去发现mysql实例 这个涉及到两个参数：HostnameResolveMethod和MySQLHostnameResolveMethod HostnameResolveMethod的值有三个选项：     "cname":通过cname做域名解析(resolve  hostname)     "default":不做特别的解析,默认为该值     "none": do  nothing   MySQLHostnameResolveMethod的值有三个选项：     "@@hostname":select  @@hostnam     ,默认为改值                "@@report_host":select @@report_host     "": do  nothing     注意：假设生产环境存在两台数据库服务器主机名一样，比如都是localhost.localdomain；并且，orch配置参数HostnameResolveMethod使用了默认的"default"、MySQLHostnameResolveMethod使用了默认的"@@hostname"。那么，orch在查找的时候，会将用户输入的IP地址解析成hostname，但因为存在两台hostname一样的机器，所以可能会导致出错，即orch找不到正确的那台服务器。 因此，最好保证线上环境，不同服务器的主机名都不同   2、给了主库，如何发现从库的---由参数 DiscoverByShowSlaveHosts  控制 1） " DiscoverByShowSlaveHosts":"true"，则会先通过show  slave hosts命令去发现从库，此时会有三种情况：

• 如果从库设置了正确的report_host，show slave hosts中的host字段显示正确的IP，则直接通过show slave hosts发现从库；
• 从库设置了错误的report_host，show slave hosts中的host字段显示错误的IP，则orchestrator找不到从库
• 如果ping不通，则报如下信息：

[mysql] 2021/06/09 17:57:24 driver.go:81: net.Error from Dial()': dial tcp 192.168.221.142:3308: i/o timeout [mysql] 2021/06/09 17:57:25 driver.go:81: net.Error from Dial()': dial tcp 192.168.221.142:3308: i/o timeout [mysql] 2021/06/09 17:57:26 driver.go:81: net.Error from Dial()': dial tcp 192.168.221.142:3308: i/o timeout

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

2021-06-09 18:15:34 ERROR dial tcp 192.168.221.142:3308: connect: connection refused 2021-06-09 18:15:40 ERROR dial tcp 192.168.221.142:3308: connect: connection refused 2021-06-09 18:15:46 ERROR dial tcp 192.168.221.142:3308: connect: connection refused 2021-06-09 18:15:52 ERROR dial tcp 192.168.221.142:3308: connect: connection refused // 或者 2021-06-09 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 2021-06-09 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发现从库，此时，会报如下信息：

2021-06-09 18:12:49 ERROR ReadTopologyInstance(192.168.221.142:3308) show slave hosts: ReadTopologyInstance(192.168.221.142:3308) 'show slave hosts' returned row with <host,port>: <,3306>   2） " DiscoverByShowSlaveHosts":"false"，则通过information_schema.processlist去发现从库 select substring_index(host, ':', 1) as slave_hostname from information_schema.processlist where command IN ('Binlog Dump', 'Binlog Dump GTID');     3、给定从库，如何发现主库 通过show slave status命令去发现主库， 既然show slave hosts命令显示的host不一定准确，那为什么还要加入DiscoverByShowSlaveHosts这个参数呢？ 原因： 如果只是通过information_schema.processlist去发现从库，master无法知道replica监听的是哪个端口。show processlist只会显示复制进程使用的套接字端口，而不是replica实例监听的端口。所以需要用户在配置文件中设置好report_host和report_port参数，并且在orch的配置文件中将参数DiscoverByShowSlaveHosts设置为true。   注意：report_port其实可以不在mysql配置文件中配置，因为report_port默认会被设置成slave的端口   如果 " DiscoverByShowSlaveHosts":"false"，orch通过information_schema.processlist去发现从库。如果slave的端口和master的不一样，orch会假设从库监听的是和主库相同的端口，那么这个slave就无法被orch自动发现，需要人工手动进行发现：   命令行：orchestrator-client -b hjj:hjj -c discover -i 192.168.221.142:3308 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就自动发现不了   此时需要手动进行发现： 命令行：orchestrator-client -b hjj:hjj -c discover -i 192.168.221.142:3308 web界面：clusters/discover     综合考虑，将 " DiscoverByShowSlaveHosts"设置为"true", 并且至少在mysql配置文件中设置正确的report_host，最好也设置上report_port

标签：slave,show,拓扑,host,3308,MySQL,report,Orchestrator,从库
From： https://www.cnblogs.com/harda/p/16995668.html