--- title: "ClustrixDB Monitor – MaxScale 2.4 新機能" publish_date: 2019-09-10 updated_date: 2023-10-12 author: "MariaDB" tags: - name: "ClustrixDB" url: "/ja/resources/blog/tag/clustrixdb-ja.md" - name: "MaxScale" url: "/ja/resources/blog/tag/maxscale-ja.md" --- # ClustrixDB Monitor – MaxScale 2.4 新機能 2018年9月に MariaDB Corporation は [Clustrix](https://staging-mdb.com/ja/products/clustrixdb/) 社を買収しましたが，[先日 GA となった MaxScale 2.4](https://staging-mdb.com/kb/en/mariadb-maxscale-24-mariadb-maxscale-242-release-notes-2019-08-30/) では新機能として [Clustrix Monitor](https://staging-mdb.com/kb/en/mariadb-maxscale-24-clustrix-monitor/) が追加されました。 この新機能では，既存の [MariaDB Monitor](https://staging-mdb.com/kb/en/mariadb-maxscale-24-mariadb-monitor/), [Galera Monitor](https://staging-mdb.com/kb/en/mariadb-maxscale-24-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](https://staging-mdb.com/kb/en/mariadb-maxscale-24-clustrix-monitor/#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 に関するブログ投稿](https://staging-mdb.com/ja/resources/blog/maxscale-2-3-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](https://staging-mdb.com/kb/en/mariadb-maxscale-24-clustrix-monitor/#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 環境で用いる場合には弊社営業まで下記ボタンからお問い合わせ願います。 [お問い合わせ](https://staging-mdb.com/ja/contact/)