ClustrixDB Monitor – MaxScale 2.4 新機能

Posted on 9月 10, 2019 by MariaDB

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 サーバのリスト，接続ユーザ名，パスワードを設定します。

[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 に各権限を与えることができます。

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 を起動します。

systemctl restart maxscale

maxctrl list servers コマンドで各 server (ノード) のステータスを確認します。

# 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 セクションで指定したノードのみ表示されます。

[ClustrixDB]
type=monitor
module=clustrixmon
servers=clx-n1,clx-n2,clx-n3
user=maxuser
password=password
dynamic_node_detection=false

# 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 でも機能するか確認してみます。

$ 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 テーブルを確認してみます。

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 は以下のような出力となります。

┌────────┬────────────┬──────┬─────────────┬─────────────────┬──────┐
│ 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 を利用することが可能になったといえます。

なお，MaxScale 2.4 は BSL 1.1 でライセンスされており，production 環境で用いる場合には弊社営業まで下記ボタンからお問い合わせ願います。

お問い合わせ

ClustrixDB Monitor – MaxScale 2.4 新機能

テスト環境

MaxScale 2.4 設定

MaxScale の起動，各 ClustrixDB ノードのステータス確認

transaction_replay(master_reconnection)のテスト

まとめ

You might also be interested in

スケールアウト型データベース ClustrixDB とは

スケールアウト型データベース ClustrixDB とは

BSL(Business Source License)

BSL(Business Source License)

transaction_replay - MaxScale read/write split 新機能

transaction_replay - MaxScale read/write split 新機能