MySQL高可用工具Orchestrator系列二：複製拓撲的發現

沃趣科技發表於2019-11-12
MySql

背   景

上篇文章講了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 <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命令去發現主庫。

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 <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主從複製原理，及應用的各種高可用場景。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/28218939/viewspace-2663643/，如需轉載，請註明出處，否則將追究法律責任。

相關文章