consul架構的 MHA 自動切換實例詳解

介紹

一直以來, 我們並未在線上啟用masterha_manager 自動切換腳本, 主要因為在網路抖動(網線, 所屬機櫃交換器不穩定)的情況下並不能保證資料庫真的不能存取.例如重啟檢測腳本所在機器的網卡並不能說明資料庫出了問題, 所以從這方面看我們不能僅通過一個點的檢測就判斷數據庫不可訪問.

幸好可以通過consul(因為consul 提供dns介面, 筆者更傾向於使用consul, 而不是etcd)集群的特性, 我們增加多點檢測機制, 在n 個集群的環境中, 有超過半數的檢測點檢測到數據庫有問題, 我們就認為數據庫不可訪問, 這時則開始呼叫masterha_manager 腳本進行切換, 如下圖所示:

       <checkmysql>         <checkmysql>         <checkmysql>
            |                   |                     |
       +---------+          +---------+          +---------+
       | consul1 |          | consul2 |          | consul3 |
       +---------+          +---------+          +---------+
                  \             |               /
                   \            |              /
                    \           |             /
                     \          |            /
                     +----------------------+
                     |   http api && acl    |
                     +----------------------+
                                |
                                |
                     +----------------------+
                     | consul-template      | ----> < mysqlxxx.tpl >  --->  <mysqlxxx.conf>
                     +----------------------+
                                                                                  |
                                                                      +--------------------------+  
                                                                      | masterha_manager_consul  |
                                                                      +--------------------------+

 

##checkmysql 需要部署到每台consul server 中, 這樣我們就實作了多點偵測MySQL 是否正常, 如果正常, checkmysql 會設定一個值為1 的鍵: mysql/mysqlxxxx /node-consul, 反之則值為0, 其中node-consul 的預設值為目前主機的hostname.

checkmysql 檢測完後,我們使用consul-template 工具根據模板檔案mysqlxxx.tpl 來監聽所有key 的變更, 如果有變化則產生配置mysqlxxxx.conf, 進而呼叫masterha_manager_consul#腳本開始進行切換.

我們在

masterha_manager_consul 腳本中重寫了方法MHA::HealthCheck::wait_until_unreachable, 避免了無限循環檢測, 如果少於一半的檢測點認為資料庫異常, 則退出該輪的呼叫, 否則啟用子程序開始執行切換操作.

#備註:

masterha_manager_consul 是基於MHA v0.5.6修改的, 並且預設只在當天的21點到第二天的9 點之間做自動切換, 可以透過night 選項控制此功能. 另外多台consul server 建議部署到不同的交換器或機櫃.

使用說明

程式碼見mha_manager_consul 整體結構如下:

mha_manager_consul
├── bin
│   ├── checkmysql
│   └── masterha_manager_consul
├── conf
│   ├── db.cnf
│   └── template-config
├── consul
│   ├── acl
│   │   ├── policy.ano
│   │   └── policy.key
│   ├── conf
│   │   └── consul.conf
│   └── conf.d
│       └── server.json
├── README.md
└── template
    └── mysql3308.tpl

測試環境

繼續使用以往的測試環境:

iposhostname#10.0.21.5#10.0.21.710.0.21.17

下面所有的操作都假设已经安装好了 consul cluster.

备注

在运行 checkmysql 之前, 我们需要设置好 acl 策略, 以免 consul 的敏感信息被旁人访问. 下面命令中的 token 参数即是 consul 主配置文件中的 acl_master_token 选项, 文件 policy.ano 则是限制匿名用户访问 mysql/* 相关键的策略, policy.key 则是设置允许访问 mysql.* 相关键的权限, 这里生成的 token 则为 dcb5b583-cd36-d39d-2b31-558bebf86502, 大家可以访问 consul acl 了解更多访问控制的内容.

#curl -X PUT --data @policy.ano http://localhost:8500/v1/acl/update?token=e95597e0-4045-11e7-a9ef-b6ba84687927
{"ID":"anonymous"}

#curl -X PUT --data @policy.key http://localhost:8500/v1/acl/update?token=e95597e0-4045-11e7-a9ef-b6ba84687927
{"ID":"dcb5b583-cd36-d39d-2b31-558bebf86502"}

checkmysql

在每个 consul server 的节点上运行该脚本, 这里的 token 参数即为上述 acl 的结果, tag 则是 db.conf 配置里的实例, 通过以下命令启动:

perl checkmysql --conf db.cnf --verbose --tag mysql3308 --token dcb5b583-cd36-d39d-2b31-558bebf86502
[2017-06-08T10:09:14] mysql/mysql3308/cz-test2 with value 1 no change
[2017-06-08T10:09:15] mysql/mysql3308/cz-test2 with value 1 no change

cz-test2 表示当前的主机名是 cz-test2, 对应上述介绍的 node-consul.

备注

如果你的 MySQL master 是通过 vip 提供服务, db.conf 配置里的 host 选项最好设置成 vip 的地址.

consul-template

在 checkmysql 更新 consul 的相关 key 之后, 如果有任意一个 checkmysql 变更了key 值, 则 consul-template 根据模板文件重新生成 mysqlxxx.conf 文件, 随后开始调用 masterha_manager_consul 脚本, consul-template 的配置详见 template-config; 通过以下命令启动:

# consul-template -config config 
2017/05/25 10:11:13 [DEBUG] (logging) enabling syslog on LOCAL5

mysqlxxxx.tpl 模板文件的内容如下:

# node3308

cz-test1:1
cz-test2:1
cz-test3:1

如果少于半数的监测点发现 MySQL 异常, consul-template 打印下面的消息:

[2017-06-08T10:24:15] status ok, skip switch..

反之则打印 error 信息, 并开始调用 masterha_manager_consul 脚本:

[2017-05-25T10:24:48] status error, need switch..
Wed May 24 10:24:48 2017 - [info] Reading default configuration from /etc/masterha/app_default.cnf..
...
...

conf.d/server.json

详见 template-config 配置中的 address = "consul.service.consul:8500" 选项; 在网络波动的情况下, address 选项如果只配置一个 consul server 的 ip 的话, consul-template 则不能连接到 consul server 中监控相应的 key 值, 尽管 consul-template 有重试功能, 但是在单 ip 的情况下, 难以确保可以正常获取相关的 key 值信息. conf.d/server.json 配置则将各个 consul server 的 ip 作为一个 dns 条目, 如下所示:

# dig @10.0.21.5 consul.service.consul
......
......
;; QUESTION SECTION:
;consul.service.consul.     IN  A

;; ANSWER SECTION:
consul.service.consul.  0   IN  A   10.0.21.7
consul.service.consul.  0   IN  A   10.0.21.5
consul.service.consul.  0   IN  A   10.0.21.17

单个 consul server 异常, 会自动跳到正常的 consul-server 中.

主从切换测试

我们简单关闭 master 的实例, 看看各工具间的输出状态.

关闭 master

关闭 master 后, checkmysql 脚本开始更新状态, 在超过半数的情况下调用 masterha_manager_consul 脚本进行主从切换: checkmysql 脚本输出, 开始将 key 的值更为 0

[2017-06-08T18:16:43] mysql/mysql3308/cz-test2 with value 1 no change
DBI connect('mysql_read_default_file=./db.cnf;mysql_read_default_group=mysql3308','',...) failed: Can't connect to MySQL server on '10.0.21.7' (111) at checkmysql line 56
[2017-06-08T18:16:44] set 0 with key mysql/mysql3308/cz-test2 ok
DBI connect('mysql_read_default_file=./db.cnf;mysql_read_default_group=mysql3308','',...) failed: Can't connect to MySQL server on '10.0.21.7' (111) at checkmysql line 56
[2017-06-08T18:16:45] mysql/mysql3308/cz-test2 with value 0 no change

mysql3308.conf 配置文件变更为如下:

# node3308

cz-test1:0
cz-test2:0
cz-test3:0

consul-template 则显示如下:

# consul-template -config config 
2017/06/08 12:11:13 [DEBUG] (logging) enabling syslog on LOCAL5

[2017-05-24T12:16:48] status error, need switch.. # 脚本判定超过半数认为数据库不可访问
Wed Jun 08 12:16:48 2017 - [info] Reading default configuration from /etc/masterha/app_default.cnf..
Wed Jun 08 12:16:48 2017 - [info] Reading application default configuration from /etc/masterha/app_56.conf..
Wed Jun 08 12:16:48 2017 - [info] Updating application default configuration from /usr/bin/init_conf_loads..
....

　　

如果没有超过半数, consul-template 则显示以下:

[2017-06-08T12:24:15] status ok, skip switch..

MHA 切换日志

mha 切换的日志则包含以下信息, 日志文件则根据 mha 的具体配置而定:

Wed Jun 08 12:45:37 2017 - [info] Starting master failover..
Wed Jun 08 12:45:37 2017 - [info] 
From:
10.0.21.7(10.0.21.7:3308) (current master)
 +--10.0.21.17(10.0.21.17:3308)

To:
10.0.21.17(10.0.21.17:3308) (new master)
...
...
Master failover to 10.0.21.17(10.0.21.17:3308) completed successfully.
Wed Jun 08 12:45:41 2017 - [info] Sending mail..

　　

总结

整体上而言, 使用 consul 的架构相对繁琐, 没有单节点那么简易方便, 不过对于比较核心的数据库来说, 一致性应该放到首位, 多点检测则很大程度上健壮了切换机制. 而且原工具自带的 masterha_manager 脚本本身只是循环检测, 超过三次错误(每次间隔时间递增)才会开始切换, 在网络波动, 交换机故障或数据库主机较繁忙的时候, 会引起一些意料之外的操作, 所以相对来说, 多点检测避免了这类不稳定的问题, 另外 consul cluster 部署完成后也可以用于其他需要一致性判断的业务, 不用太纠结于繁琐方面的考虑.

		##version
centos 6.5	cz-test1	consul 0.8v
centos 6.5	#cz-test2	consul 0.8v
centos 6.5	cz-test3	consul 0.8v

以上是consul架構的 MHA 自動切換實例詳解的詳細內容。更多資訊請關注PHP中文網其他相關文章！