はじめに
2018年9月に MariaDB Corporation は Clustrix 社を買収しましたが，先日 GA となった MaxScale 2.4 では新機能として Clustrix Monitor が追加されました。
この新機能では，既存の MariaDB Monitor, Galera Monitor と同様にバックエンドのDBサーバの死活監視などを行い，Router サービスと連携してクエリのルーティング等を行うことが可能です。
今回は Clustrix Monitor の簡単な検証を行ってみます。
テスト環境
以下の構成でテストを実施しました。いずれのノードもOSは CentOS 7.6.1810 を用いています。
- ClustrixDB 9.1.4 x 3 ノード
- MaxScale 2.4.2 GA
MaxScale 2.4 設定
/etc/maxscale.cnf を以下のように設定します。Clustrix Monitor の module 名は clustrixmon となり，他の monitor と同様にモニターする DB サーバのリスト，接続ユーザ名，パスワードを設定します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 |
[maxscale] threads=auto log_warning=1 [ClustrixDB] type=monitor module=clustrixmon servers=clx-n1,clx-n2,clx-n3 user=maxuser password=maxpwd [Splitter-Service] type=service router=readwritesplit servers=clx-n1,clx-n2,clx-n3 user=maxuser password=maxpwd transaction_replay=true localhost_match_wildcard_host=true [Splitter-Listener] type=listener service=Splitter-Service protocol=mariadbclient port=3306 [clx-n1] type=server address=10.0.0.103 port=3306 protocol=mariadbbackend [clx-n2] type=server address=10.0.0.92 port=3306 protocol=mariadbbackend [clx-n3] type=server address=10.0.0.220 port=3306 protocol=mariadbbackend |
ClustrixDB ノードでは接続ユーザに以下の権限を与えておく必要があります。
- system.nodeinfo
- system.membership
- system.softfailed_nodes
例えば，以下の GRANT 文で maxuser に各権限を与えることができます。
|
1 2 3 |
GRANT SELECT ON system.membership TO 'maxuser'@'%'; GRANT SELECT ON system.nodeinfo TO 'maxuser'@'%'; GRANT SELECT ON system.softfailed_nodes TO 'maxuser'@'%'; |
なお，同一クラスタ内の1ノードでユーザ設定を行えばよく，すべてのノードで同じ作業を行う必要はありません。
MaxScale の起動，各 ClustrixDB ノードのステータス確認
systemctl により MaxScale を起動します。
|
1 |
systemctl restart maxscale |
maxctrl list servers コマンドで各 server (ノード) のステータスを確認します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
$ maxctrl list servers ┌─────────────────────┬────────────┬──────┬─────────────┬─────────────────┬──────┐ │ Server │ Address │ Port │ Connections │ State │ GTID │ ├─────────────────────┼────────────┼──────┼─────────────┼─────────────────┼──────┤ │ @@ClustrixDB:node-3 │ 10.0.0.92 │ 3306 │ 0 │ Master, Running │ │ ├─────────────────────┼────────────┼──────┼─────────────┼─────────────────┼──────┤ │ @@ClustrixDB:node-2 │ 10.0.0.220 │ 3306 │ 0 │ Master, Running │ │ ├─────────────────────┼────────────┼──────┼─────────────┼─────────────────┼──────┤ │ @@ClustrixDB:node-1 │ 10.0.0.103 │ 3306 │ 0 │ Master, Running │ │ ├─────────────────────┼────────────┼──────┼─────────────┼─────────────────┼──────┤ │ clx-n1 │ 10.0.0.103 │ 3306 │ 0 │ Master, Running │ │ ├─────────────────────┼────────────┼──────┼─────────────┼─────────────────┼──────┤ │ clx-n2 │ 10.0.0.92 │ 3306 │ 0 │ Master, Running │ │ ├─────────────────────┼────────────┼──────┼─────────────┼─────────────────┼──────┤ │ clx-n3 │ 10.0.0.220 │ 3306 │ 0 │ Master, Running │ │ └─────────────────────┴────────────┴──────┴─────────────┴─────────────────┴──────┘ |
各 CluxtrixDB ノードが正常に稼働している場合は，上記のような出力が得られます。デフォルト設定では，dynamic_node_detection が true(有効)になっており，動的に各ノードのリストが取得されます(ClustrixDBは分散DBで各ノードがクラスタ内のすべてのノードの存在を把握しているため)。
maxscale.cnf の clustrixmon セクションの設定において，以下のように dynamic_node_detection を false に設定すれば，動的にノード検出は行われず，maxscale.cnf の server セクションで指定したノードのみ表示されます。
|
1 2 3 4 5 6 7 |
[ClustrixDB] type=monitor module=clustrixmon servers=clx-n1,clx-n2,clx-n3 user=maxuser password=password dynamic_node_detection=false |
maxctrl list servers の出力は以下のようになります。
|
1 2 3 4 5 6 7 8 9 10 |
$ maxctrl list servers ┌────────┬────────────┬──────┬─────────────┬─────────────────┬──────┐ │ Server │ Address │ Port │ Connections │ State │ GTID │ ├────────┼────────────┼──────┼─────────────┼─────────────────┼──────┤ │ clx-n1 │ 10.0.0.103 │ 3306 │ 0 │ Master, Running │ │ ├────────┼────────────┼──────┼─────────────┼─────────────────┼──────┤ │ clx-n2 │ 10.0.0.92 │ 3306 │ 0 │ Master, Running │ │ ├────────┼────────────┼──────┼─────────────┼─────────────────┼──────┤ │ clx-n3 │ 10.0.0.220 │ 3306 │ 0 │ Master, Running │ │ └────────┴────────────┴──────┴─────────────┴─────────────────┴──────┘ |
ClustrixDB は分散RDBMSのため，すべてのノードに書込を行うことができ，そのため各ノードのステータスが Master となっています。
transaction_replay(master_reconnection)のテスト
transaction_replay に関するブログ投稿と同様に，定期的にテストテーブルに INSERT を行い，テスト途中で ClustrixDB 1 ノードをシャットダウン，master_reconnection が Clustrix Monitor でも機能するか確認してみます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
$ ruby test_ts.rb INSERT INTO test.rwsplit VALUES (0, now()); INSERT INTO test.rwsplit VALUES (1, now()); INSERT INTO test.rwsplit VALUES (2, now()); INSERT INTO test.rwsplit VALUES (3, now()); INSERT INTO test.rwsplit VALUES (4, now()); INSERT INTO test.rwsplit VALUES (5, now()); INSERT INTO test.rwsplit VALUES (6, now()); INSERT INTO test.rwsplit VALUES (7, now()); INSERT INTO test.rwsplit VALUES (8, now()); INSERT INTO test.rwsplit VALUES (9, now()); INSERT INTO test.rwsplit VALUES (10, now()); INSERT INTO test.rwsplit VALUES (11, now()); INSERT INTO test.rwsplit VALUES (12, now()); INSERT INTO test.rwsplit VALUES (13, now()); INSERT INTO test.rwsplit VALUES (14, now()); INSERT INTO test.rwsplit VALUES (15, now()); INSERT INTO test.rwsplit VALUES (16, now()); INSERT INTO test.rwsplit VALUES (17, now()); INSERT INTO test.rwsplit VALUES (18, now()); INSERT INTO test.rwsplit VALUES (19, now()); INSERT INTO test.rwsplit VALUES (20, now()); |
transaction_replay(master_reconnection)により，アプリケーション(テストスクリプト)側では ClustrixDB との接続が途切れることはありませんでした。rwsplit テーブルを確認してみます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
MySQL [test]> SELECT * FROM rwsplit ORDER BY id; +----+---------------------+ | id | ts | +----+---------------------+ | 0 | 2019-09-06 03:18:42 | | 1 | 2019-09-06 03:18:43 | | 2 | 2019-09-06 03:18:44 | | 3 | 2019-09-06 03:18:45 | | 4 | 2019-09-06 03:18:46 | | 5 | 2019-09-06 03:18:47 | | 6 | 2019-09-06 03:18:48 | | 7 | 2019-09-06 03:18:49 | | 8 | 2019-09-06 03:18:50 | | 9 | 2019-09-06 03:18:51 | | 10 | 2019-09-06 03:18:52 | | 11 | 2019-09-06 03:18:53 | | 12 | 2019-09-06 03:21:03 | | 13 | 2019-09-06 03:21:04 | | 14 | 2019-09-06 03:21:05 | | 15 | 2019-09-06 03:21:06 | | 16 | 2019-09-06 03:21:07 | | 17 | 2019-09-06 03:21:08 | | 18 | 2019-09-06 03:21:09 | | 19 | 2019-09-06 03:21:10 | | 20 | 2019-09-06 03:21:11 | +----+---------------------+ 21 rows in set (0.001 sec) |
cluster_monitor_interval パラメータのデフォルト値が 60000 ms (1分間)と比較的大きい値となってるために，ID=11と12の間で2分強時間が空いていますが，アプリケーション側で再接続を行うことなく，継続的にデータ書きができていることが確認できました。
なお，ノードが停止している際は maxctrl list servers の出力は以下のようになります。
|
1 2 3 4 5 6 7 8 9 10 |
$ maxctrl list servers ┌────────┬────────────┬──────┬─────────────┬─────────────────┬──────┐ │ Server │ Address │ Port │ Connections │ State │ GTID │ ├────────┼────────────┼──────┼─────────────┼─────────────────┼──────┤ │ clx-n1 │ 10.0.0.103 │ 3306 │ 0 │ Down │ │ ├────────┼────────────┼──────┼─────────────┼─────────────────┼──────┤ │ clx-n2 │ 10.0.0.92 │ 3306 │ 1 │ Master, Running │ │ ├────────┼────────────┼──────┼─────────────┼─────────────────┼──────┤ │ clx-n3 │ 10.0.0.220 │ 3306 │ 0 │ Master, Running │ │ └────────┴────────────┴──────┴─────────────┴─────────────────┴──────┘ |
まとめ
今回は2019年8月にリリースされた MaxScale 2.4 の新機能，Clustrix Monitor の簡単な機能検証を行ってみました。 MariaDB Server と同様に master_reconnection が機能することが確認でき，これまで ClustrixDB では DB Proxy として HAProxy の利用を推奨してきましたが，MariaDB MaxScale を利用することが可能になったと言えます。
執筆者情報
2017年6月よりMariaDB CorporationにてAPAC(Asia Pacific)地域におけるプリセールス業務を主に担当。現在は主に日本を担当。
この執筆者の他の記事をよむ
