DockerでのMariaDBMaxScaleロードバランシング：管理：パート2

このブログ投稿は、DockerでのMariaDB MaxScale Load Balancingの続きです：Deployment-Part1。このパートでは、サービス制御、構成管理、クエリ処理、セキュリティ、クラスター調整などの高度なユースケースを使用した管理操作に焦点を当てます。この投稿に示されている手順と手順の例は、このブログシリーズの最初の部分で設定した実行環境に基づいています。

サービス制御

MaxScaleの場合、コンテナを開始および停止することがサービスを制御する唯一の方法です。コンテナが作成されている場合は、次のコマンドを使用してサービスを管理できます。

$ docker start maxscale
$ docker stop maxscale
$ docker restart maxscale

ルート権限なしで実行

Dockerコンテナーは、デフォルトでroot特権で実行され、コンテナー内で実行されるアプリケーションも実行されます。ハッカーはコンテナ内で実行されているアプリケーションをハッキングすることでDockerホストへのルートアクセスを取得できるため、これはセキュリティの観点からのもう1つの大きな懸念事項です。

Dockerをroot以外のユーザーとして実行するには、ユーザーをdockerグループに追加する必要があります。まず、Dockerグループがない場合は作成します：

$ sudo groupadd docker

次に、ユーザーをdockerグループに追加します。この例では、ユーザーは「vagrant」です：

$ sudo usermod -aG docker vagrant

ログアウトして再度ログインし、グループメンバーシップが再評価されるようにします（または、機能しない場合は再起動します）。この時点で、ユーザー「vagrant」として標準の実行コマンド（sudoは不要）を使用してMaxScaleコンテナーを実行できます。

$ docker run -d \
--name maxscale-unprivileged \
-p 4006:4006 \
-p 4008:4008 \
-p 8989:8989 \
-v $PWD/maxscale.cnf:/etc/maxscale.cnf \
mariadb/maxscale

MaxScaleプロセスはユーザー「maxscale」によって実行され、ルートレベルまでの特別な権限は必要ありません。したがって、セキュリティが心配な場合は、コンテナを非特権モードで実行することが常に最善の方法です。

構成管理

スタンドアロンのMaxScaleコンテナの場合、構成管理では、マップされた構成ファイルを変更してから、MaxScaleコンテナを再起動する必要があります。ただし、Docker Swarmサービスとして実行している場合は、新しい構成を新しいバージョンとしてSwarmConfigsにロードする必要があります。例：

$ cat maxscale.cnf | docker config create maxscale_config_v2 -

次に、古い構成（maxscale_config）を削除してサービスを更新し、新しい構成（maxscale_config_v2）を同じターゲットに追加します。

$ docker service update \
--config-rm maxscale_config \
--config-add source=maxscale_config_v2,target=/etc/maxscale.cnf \
maxscale-cluster

その後、Docker Swarmはコンテナの削除をスケジュールし、レプリカの要件が満たされるまで、一度に1つのコンテナの手順を置き換えます。

アップグレードとダウングレード

Dockerでアプリケーションを実行する利点の1つは、簡単なアップグレードとダウングレードの手順です。実行中のコンテナはすべてイメージに基づいており、このイメージはイメージタグを使用して簡単に切り替えることができます。 MaxScaleで使用可能なイメージのリストを取得するには、DockerHubの[タグ]セクションを確認してください。次の例は、MaxScale2.3を以前の1つのマイナーバージョン2.2にダウングレードするプロセスを示しています。

$ docker run -d \
--name maxscale \
-p 4006:4006 \
-p 4008:4008 \
-v $PWD/maxscale.cnf:/etc/maxscale.cnf \
mariadb/maxscale:2.3
$ docker rm -f maxscale
$ docker run -d \
--name maxscale \
-p 4006:4006 \
-p 4008:4008 \
-v $PWD/maxscale.cnf:/etc/maxscale.cnf \
mariadb/maxscale:2.2

構成オプションが実行するバージョンと互換性があることを確認してください。たとえば、上記のダウングレードは、次のエラーが原因で最初の実行で失敗します。

2019-06-19 05:29:04.301   error  : (check_config_objects): Unexpected parameter 'master_reconnection' for object 'rw-service' of type 'service', or 'true' is an invalid value for parameter 'master_reconnection'.
2019-06-19 05:29:04.301   error  : (check_config_objects): Unexpected parameter 'delayed_retry' for object 'rw-service' of type 'service', or 'true' is an invalid value for parameter 'delayed_retry'.
2019-06-19 05:29:04.301   error  : (check_config_objects): Unexpected parameter 'transaction_replay_max_size' for object 'rw-service' of type 'service', or '1Mi' is an invalid value for parameter 'transaction_replay_max_size'.
2019-06-19 05:29:04.302   error  : (check_config_objects): Unexpected parameter 'transaction_replay' for object 'rw-service' of type 'service', or 'true' is an invalid value for parameter 'transaction_replay'.
2019-06-19 05:29:04.302   error  : (check_config_objects): Unexpected parameter 'causal_reads_timeout' for object 'rw-service' of type 'service', or '10' is an invalid value for parameter 'causal_reads_timeout'.
2019-06-19 05:29:04.302   error  : (check_config_objects): Unexpected parameter 'causal_reads' for object 'rw-service' of type 'service', or 'true' is an invalid value for parameter 'causal_reads'.

コンテナイメージをダウングレードする前に、上記の構成ファイルでサポートされていない構成オプションを削除する必要があります。

master_reconnection
delayd_retry
transaction_replay
causeal_reads_timeout
causeal_reads

最後に、コンテナを再起動すると、問題がないはずです。 MaxScaleのバージョンアップグレードも同様に機能します。使用したいタグを変更するだけで、すぐに使用できます。

MaxScaleフィルター

MaxScaleは、フィルターと呼ばれるコンポーネントを使用して、要求が通過するときに要求を操作または処理します。このページにリストされているように、使用できるフィルターはたくさんあります。MaxScale2.3フィルター。たとえば、特定のクエリが条件に一致する場合はファイルにログインできます。また、受信クエリをバックエンドサーバーに到達する前に書き換えることもできます。

フィルタをアクティブにするには、セクションを定義し、さらに下の例に示すように、対応するサービス定義に定義名を含める必要があります。

すべてのクエリログ（QLA）

その名前が説明するように、QLAフィルターは、すべてのクエリがクライアントセッションごとのルールセットに一致することをログに記録します。すべてのクエリは、ファイルベース形式に従ってログに記録されます。

まず、type=filterとmodule=qlafilterでコンポーネントを定義します：

## Query Log All (QLA) filter
## Filter module for MaxScale to log all query content on a per client session basis
[qla-sbtest-no-pk]
type		= filter
module		= qlafilter
filebase	= /tmp/sbtest
match		= select.*from.*
exclude		= where.*id.*
user		= sbtest

次に、フィルターコンポーネントをサービスに追加します。

[rw-service]
...
filters        = qla-sbtest-no-pk
[rr-service]
...
filters        = qla-sbtest-no-pk

コンテナの/tmpをDockerホスト上の実際のディレクトリにマップすることもお勧めします。これにより、生成されたログファイルを取得するためにコンテナにアクセスする必要がなくなります。まず、ディレクトリを作成し、グローバルに書き込み可能な権限を付与します。

$ mkdir qla
$ chmod 777 qla

上記のディレクトリをコンテナにバインドする必要があるため、実行中のコンテナを停止して削除し、次のコマンドを使用して再実行する必要があります。

$ docker stop maxscale
$ docker run -d \
--name maxscale \
--restart always \
-p 4006:4006 \
-p 4008:4008 \
-p 8989:8989 \
-v $PWD/maxscale.cnf:/etc/maxscale.cnf \
-v $PWD/qla:/tmp \
mariadb/maxscale

次に、qlaディレクトリ内のログに記録されたクエリのコンテンツを取得できます。

$ cat qla/*
Date,[email protected],Query
2019-06-18 08:25:13,[email protected]::ffff:192.168.0.19,select * from sbtest.sbtest1

クエリの書き換え

クエリの書き換えは、データベースサーバーに対して実行されているクエリに応じて、問題のあるクエリをすばやく分離して修正し、パフォーマンスを向上させる機能です。

クエリの書き換えは、regexfilterを介して実行できます。このフィルターは、正規表現を使用して着信ステートメントを照合または除外し、それらを別のステートメントに置き換えることができます。すべてのルールは独自のセクションで定義され、対応するサービスにセクション名を含めてアクティブにします。

次のフィルターは、読み取り専用クライアントに公開したくないいくつかのSHOWコマンドと一致します。

## Rewrite query based on regex match and replace
[block-show-commands]
type            = filter
module          = regexfilter
options         = ignorecase
match           = ^show (variables|global variables|global status|status|processlist|full processlist).*
replace         = SELECT 'Not allowed'

次に、適用するサービスにフィルターを追加できます。たとえば、上記の場合、すべての読み取り専用接続をフィルタリングする必要があります。

[rr-service]
...
filters        = qla-sbtest-no-pk | block-show-commands

Linuxシェルパイプ「|」に似た構文を使用して、複数のフィルターを定義できることに注意してください。構文。コンテナを再起動して、構成の変更を適用します。

$ docker restart maxscale

次に、次のクエリで確認できます：

$ mysql -usbtest -p -h192.168.0.200 -P4006 -e 'SHOW VARIABLES LIKE "max_connections"'
+-------------+
| Not allowed |
+-------------+
| Not allowed |
+-------------+

期待どおりの結果が得られます。

クラスターリカバリ

MaxScale 2.2.2以降では、次のイベントの自動または手動のMariaDBレプリケーションまたはクラスターリカバリがサポートされています。

フェイルオーバー
切り替え
再参加
リセット-複製

マスタースレーブクラスターのフェールオーバーは、自動的にアクティブ化するように設定でき、多くの場合、設定する必要があります。スイッチオーバーは、MaxAdmin、MaxCtrl、またはRESTインターフェースを介して手動でアクティブ化する必要があります。再結合は、自動に設定することも、手動でアクティブにすることもできます。これらの機能は、「mariadbmon」モジュールに実装されています。

アクティブなマスター192.168.0.91を意図的にシャットダウンすると、次の自動フェイルオーバーイベントが発生しました。

$ docker logs -f maxscale
...
2019-06-19 03:53:02.348   error  : (mon_log_connect_error): Monitor was unable to connect to server mariadb1[192.168.0.91:3306] : 'Can't connect to MySQL server on '192.168.0.91' (115)'
2019-06-19 03:53:02.351   notice : (mon_log_state_change): Server changed state: mariadb1[192.168.0.91:3306]: master_down. [Master, Running] -> [Down]
2019-06-19 03:53:02.351   warning: (handle_auto_failover): Master has failed. If master status does not change in 4 monitor passes, failover begins.
2019-06-19 03:53:16.710   notice : (select_promotion_target): Selecting a server to promote and replace 'mariadb1'. Candidates are: 'mariadb2', 'mariadb3'.
2019-06-19 03:53:16.710   warning: (warn_replication_settings): Slave 'mariadb2' has gtid_strict_mode disabled. Enabling this setting is recommended. For more information, see https://mariadb.com/kb/en/library/gtid/#gtid_strict_mode
2019-06-19 03:53:16.711   warning: (warn_replication_settings): Slave 'mariadb3' has gtid_strict_mode disabled. Enabling this setting is recommended. For more information, see https://mariadb.com/kb/en/library/gtid/#gtid_strict_mode
2019-06-19 03:53:16.711   notice : (select_promotion_target): Selected 'mariadb2'.
2019-06-19 03:53:16.711   notice : (handle_auto_failover): Performing automatic failover to replace failed master 'mariadb1'.
2019-06-19 03:53:16.723   notice : (redirect_slaves_ex): Redirecting 'mariadb3' to replicate from 'mariadb2' instead of 'mariadb1'.
2019-06-19 03:53:16.742   notice : (redirect_slaves_ex): All redirects successful.
2019-06-19 03:53:17.249   notice : (wait_cluster_stabilization): All redirected slaves successfully started replication from 'mariadb2'.
2019-06-19 03:53:17.249   notice : (handle_auto_failover): Failover 'mariadb1' -> 'mariadb2' performed.
2019-06-19 03:53:20.363   notice : (mon_log_state_change): Server changed state: mariadb2[192.168.0.92:3306]: new_master. [Slave, Running] -> [Master, Running]

フェイルオーバーが完了すると、トポロジは次のようになります。

スイッチオーバー操作の場合、人間の介入とMaxCtrlコンソールを介してそれを行う1つの方法が必要です。古いマスターが操作可能になり、マスターとして昇格する準備ができているとすると、次のコマンドを送信して切り替え操作を実行できます。

$ docker exec -it maxscale maxctrl
maxctrl: call command mariadbmon switchover monitor mariadb1 mariadb2
OK

ここで、フォーマットは次のとおりです。

$ call command <monitoring module> <operation> <monitoring section name> <new master> <current master>

次に、サーバーを一覧表示して新しいトポロジを確認します。

 maxctrl: list servers
┌──────────┬──────────────┬──────┬─────────────┬─────────────────┬──────────────┐
│ Server   │ Address      │ Port │ Connections │ State           │ GTID         │
├──────────┼──────────────┼──────┼─────────────┼─────────────────┼──────────────┤
│ mariadb1 │ 192.168.0.91 │ 3306 │ 0           │ Master, Running │ 0-5001-12144 │
├──────────┼──────────────┼──────┼─────────────┼─────────────────┼──────────────┤
│ mariadb2 │ 192.168.0.92 │ 3306 │ 0           │ Slave, Running  │ 0-5001-12144 │
├──────────┼──────────────┼──────┼─────────────┼─────────────────┼──────────────┤
│ mariadb3 │ 192.168.0.93 │ 3306 │ 0           │ Slave, Running  │ 0-5001-12144 │
└──────────┴──────────────┴──────┴─────────────┴─────────────────┴──────────────┘

古いマスターを元の場所に昇格させました。おもしろいことに、ClusterControlの自動回復機能は、有効になっている場合とまったく同じことを行います。

最終的な考え

DockerでMariaDBMaxScaleを実行すると、MaxScaleクラスタリング、アップグレードとダウングレードが簡単、MySQLおよびMariaDBクラスターの高度なプロキシ機能などの追加の利点がもたらされます。