【沃趣科技】MySQL高可用工具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 <host,port>: <,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命令去發現主庫。

既然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 <host,port>: <,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主從復制原理，及應用的各種高可用場景。