집 > 기사 > 데이터 베이스 > 영사 아키텍처의 MHA 자동 전환 예에 대한 자세한 설명

영사 아키텍처의 MHA 자동 전환 예에 대한 자세한 설명

PHP中文网원래의: 2017-06-21 16:35:413440검색

소개

오랫동안 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  |
                                                                      +--------------------------+

masterha_manager 脚本进行切换, 如下图所示:

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

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

checkmysql 는 각 consul 서버에 배포되어야 MySQL이 정상인지 확인하기 위해 여러 번 클릭할 수 있습니다. 정상이면 checkmysql이 설정됩니다. 값이 1인 키: mysql/mysqlxxxx/node-consul, 그렇지 않으면 값은 0이 됩니다. 여기서 node-consul의 기본값은 현재의 호스트 이름입니다.

checkmysql 감지 후 템플릿 파일 mysqlxxx.tpl에 따라 consul-template 도구를 사용하여 모든 키 변경 사항을 모니터링하고 변경 사항이 있는 경우 mysqlxxxx.conf를 구성한 다음 masterha_manager_consul 스크립트를 호출하여 전환을 시작합니다.

우리는 masterha_manager_consul 메소드 MHA::에 있습니다. 무한 루프 감지를 피하기 위해 HealthCheck::wait_until_unreachable이 스크립트에 다시 작성되었습니다. 데이터베이스에서 감지 지점의 절반 미만이 비정상으로 간주되면 호출 라운드가 종료되고, 그렇지 않으면 하위 프로세스가 종료됩니다. 활성화됩니다. 전환 작업 수행을 시작합니다.

참고:

masterha_manager_consul는 MHA v0.5.6을 기준으로 수정되었으며 기본적으로 당일 21:00 사이에만 사용 가능합니다. 그리고 다음날 9시 자동 전환의 경우 야간 옵션을 통해 이 기능을 제어할 수 있습니다. 또한 여러 개의 consul 서버를 서로 다른 스위치에 배포하는 것이 좋습니다. 또는 캐비닛.

호스트 이름version cz-test1consul 0.8v콘술 0.8v consul 0.8v

10.0.21.5 centos 6.5

10.0.21.7 centos 6.5 cz-test2

10.0.21.17 centos 6.5 cz-test3

	10.0.21.5	centos 6.5
10.0.21.7	centos 6.5	cz-test2
10.0.21.17	centos 6.5	cz-test3
下面所有的操作都假设已经安装好了 `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` 部署完成后也可以用于其他需要一致性判断的业务, 不用太纠结于繁琐方面的考虑.

下面所有的操作都假设已经安装好了 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(&#39;mysql_read_default_file=./db.cnf;mysql_read_default_group=mysql3308&#39;,&#39;&#39;,...) failed: Can&#39;t connect to MySQL server on &#39;10.0.21.7&#39; (111) at checkmysql line 56
[2017-06-08T18:16:44] set 0 with key mysql/mysql3308/cz-test2 ok
DBI connect(&#39;mysql_read_default_file=./db.cnf;mysql_read_default_group=mysql3308&#39;,&#39;&#39;,...) failed: Can&#39;t connect to MySQL server on &#39;10.0.21.7&#39; (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 部署完成后也可以用于其他需要一致性判断的业务, 不用太纠结于繁琐方面的考虑.

위 내용은 영사 아키텍처의 MHA 자동 전환 예에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

성명：

이전 기사：mysql 사용자를 위한 일반적인 작업다음 기사：mysql 사용자를 위한 일반적인 작업