consulアーキテクチャのMHA自動切替例の詳細説明

はじめに

長い間、オンラインでの masterha_manager 自動切り替えスクリプトを有効にしてきませんでした。主な理由は、ネットワークにジッターが発生した場合 (ネットワーク ケーブル、対応するキャビネット スイッチが不安定である場合)、データベースにアクセスできないという保証がないためです。たとえば、検出スクリプトが配置されているマシンを再起動します。ネットワーク カードはデータベースに問題があることを意味するものではないため、この観点からは、1 点が検出されただけでデータベースにアクセスできないと判断することはできません。幸いなことに、これは可能です。 consul を使用します (consul は DNS インターフェースを提供するため、著者は consul を使用することを好みます。これは etcd の機能ではありません)。n クラスターの環境では、検出の半分以上であるマルチポイント検出メカニズムを追加します。ポイントはデータベースにアクセスできないことを検出し、次の図に示すように masterha_manager. スクリプトの呼び出しを開始します。 は各 consul サーバー にデプロイする必要があります。これにより、MySQL が正常かどうかを複数回クリックしてチェックできるようになります。正常であれば、checkmysql が設定します。値が 1 のキー: mysql/mysqlxxxx/node-consul。それ以外の場合、値は 0 になります。node-consul のデフォルト値は、現在のホスト名です。

checkmysql 検出後、テンプレート ファイル mysqlxxx.tpl に従って consul-template ツールを使用して、すべてのキーの変更を監視し、変更がある場合は、 mysqlxxxx.conf を設定し、masterha_manager_consul スクリプトを呼び出して切り替えを開始します 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

masterha_manager_consul メソッド MHA:: HealthCheck::wait_until_unreachable は、無限ループの検出を回避するためにスクリプト内で書き換えられます。データベース内で異常とみなされる検出ポイントが半分未満の場合、呼び出しのラウンドは終了します。そうでない場合は、子プロセスが終了します。切り替え操作の実行を開始します。

注:

masterha_manager_consul は MHA v0.5.6 に基づいて変更されており、デフォルトでは 21:00 の間でのみ使用可能です。自動切り替えの場合、night オプションを使用してこの機能を制御できます。また、複数の consul サーバー を異なるスイッチにデプロイすることをお勧めします。

使用説明

コードについては 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

テスト環境 引き続き前のテスト環境を使用します: iposホスト名バージョン10.0.21.5centos 6.5 cz-test1consul 0.8v10.0.21.7centos 6.5cz-test2コンスル0.8v 10.0.21.17centos 6.5cz-test3consul 0.8v 🎜

下面所有的操作都假设已经安装好了 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アーキテクチャのMHA自動切替例の詳細説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。