MariaDBMaxScale2.4の新機能

MaxScale 2.4は2019年12月21日にリリースされ、ClusterControl1.7.6はこのバージョンまでの監視と管理をサポートしています。ただし、展開の場合、ClusterControlはバージョン2.3までしかサポートしません。インスタンスを手動でアップグレードする必要があります。幸い、アップグレード手順は非常に簡単です。 MariaDB MaxScaleダウンロードページから最新バージョンをダウンロードして、パッケージインストールコマンドを実行するだけです。

次のコマンドは、CentOS7ボックスで既存のMaxScale2.3からMaxScale2.4にアップグレードする方法を示しています。

$ wget https://dlm.mariadb.com/1067184/MaxScale/2.4.10/centos/7/x86_64/maxscale-2.4.10-1.centos.7.x86_64.rpm
$ systemctl stop maxscale
$ yum localinstall -y maxscale-2.4.10-1.centos.7.x86_64.rpm
$ systemctl start maxscale
$ maxscale --version
MaxScale 2.4.10

このブログ投稿では、このバージョンの注目すべき改善点と新機能のいくつかと、実際の動作の様子を紹介します。 MariaDB MaxScale 2.4での変更の完全なリストについては、その変更ログを確認してください。

インタラクティブモードのコマンド履歴

これは基本的に小さな改善であり、MaxScaleの管理と監視タスクの効率に大きな影響を与えます。 MaxCtrlのインタラクティブモードにコマンド履歴が追加されました。コマンド履歴を使用すると、上矢印キーまたは下矢印キーを押すことで、実行したコマンドを簡単に繰り返すことができます。ただし、Ctrl + R機能（指定した文字に一致する最後のコマンドを思い出してください）はまだありません。

以前のバージョンでは、標準のシェルモードを使用して、コマンドが.bash_historyファイルによってキャプチャされていることを確認する必要があります。

ガレラモンのGTIDモニタリング

これは、非同期レプリケーション（クラスター間レプリケーション、またはMariaDBレプリケーションを介したMariaDB Galeraクラスターレプリケーションとも呼ばれます）を介して地理的な冗長性を備えたGaleraクラスターで実行しているユーザーにとって優れた拡張機能です。

MaxScale 2.3以前では、MariaDBクラスター間でマスタースレーブレプリケーションを有効にした場合、次のようになります。

MaxScale 2.4の場合、現在は次のようになっています（Galera1の行）：

MaxScaleを使用せずに、すべてのノードのレプリケーション状態を簡単に確認できるようになりました。個々のノードを繰り返しチェックする必要があります。

SmartRouter

これは、MaxScale 2.4の新しい主要機能の1つであり、MaxScaleは、クエリを処理するのに最適なバックエンドMariaDBバックエンドサーバーを学習するのに十分なほどスマートになっています。 SmartRouterは、クラスターへのクエリのパフォーマンスまたは実行時間を追跡します。測定値は、クエリの正規値をキーとして保存されます。クエリの標準は、すべてのユーザー定義定数が疑問符に置き換えられたSQLです。例：

UPDATE `money_in` SET `accountholdername` = ? , `modifiedon` = ? , `status` = ? , `modifiedby` = ? WHERE `id` = ?

これは、マルチサイトの地理的レプリケーションまたは1つのレプリケーションチェーン内のMariaDBストレージエンジンの組み合わせでMariaDBを実行している場合、たとえばトランザクションワークロード（OLTP）を処理する専用スレーブで実行している場合に非常に便利な機能です。）InnoDBストレージエンジンと、Columnstoreストレージエンジンで分析ワークロード（OLAP）を処理するための別の専用スレーブを使用します。

次の図に示すように、シドニーとシンガポールの2つのサイトがあるとします。

プライマリサイトはシンガポールにあり、MariaDBマスターとスレーブがあります、別の読み取り専用スレーブがシドニーにあります。アプリケーションは、次のポート設定を使用して、それぞれの国にあるMaxScaleインスタンスに接続します。

読み取り/書き込み分割：3306
ラウンドロビン：3307
スマートルーター：3308

SmarRouterサービスとリスナーの定義は次のとおりです。

[SmartQuery]
type=service
router=smartrouter
servers=DB_1,DB_2,DB_5
master=DB_1
user=maxscale
password=******

[SmartQuery-Listener]
type = listener
service = SmartQuery
protocol = mariadbclient
port = 3308

MaxScaleを再起動し、シンガポールとシドニーにある両方のMaxScaleノードへの読み取り専用クエリの送信を開始します。クエリがラウンドロビンルーター（ポート3307）によって処理される場合、クエリはラウンドロビンアルゴリズムに基づいてルーティングされていることがわかります。

(app)$ mysql -usbtest -p -h maxscale_sydney -P3307 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+--------------------+
| count(id) | @@hostname         |
+-----------+--------------------+
|   1000000 | mariadb_singapore2 |
+-----------+--------------------+

上記から、シドニーのMaxScaleが上記のクエリをシンガポールのスレーブに転送したことがわかります。これはそれ自体が最適なルーティングオプションではありません。

SmartRouterがポート3308でリッスンしていると、クエリがシドニーの最も近いスレーブにルーティングされていることがわかります。

(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+-----------------+
| count(id) | @@hostname      |
+-----------+-----------------+
|   1000000 | mariadb_sydney1 |
+-----------+-----------------+

シンガポールのサイトで同じクエリが実行されると、シンガポールにあるMariaDBスレーブにルーティングされます：

(app)$ mysql -usbtest -p -h maxscale_singapore -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+--------------------+
| count(id) | @@hostname         |
+-----------+--------------------+
|   1000000 | mariadb_singapore2 |
+-----------+--------------------+

ただし問題があります。 SmartRouterは、これまで正規が表示されたことのない読み取りクエリを検出すると、そのクエリをすべてのクラスターに送信します。クラスターからの最初の応答は、そのクラスターをその正規のクラスターに最適なクラスターとして指定します。また、最初の応答を受信すると、他のクエリはキャンセルされます。すべてのクラスターがクエリまたはキャンセルに応答すると、応答がクライアントに送信されます。

つまり、正規のクエリ（正規化されたクエリ）を追跡し、そのパフォーマンスを測定するために、最初のクエリが最初の実行で失敗することがわかります。次に例を示します。

(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
ERROR 2013 (HY000) at line 1: Lost connection to MySQL server during query

MariaDB Sydneyの一般的なログから、MaxScaleからの「接続が失われました」エラーにもかかわらず、最初のクエリ（ID 74）が正常に実行された（接続、クエリ、および終了）ことがわかります。

  74 Connect  [email protected] as anonymous on 
  74 Query    SELECT COUNT(id),@@hostname FROM sbtest.sbtest1
  74 Quit

同じ後続のクエリが正しく処理され、正しい応答で返されました：

(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+------------------------+
| count(id) | @@hostname             |
+-----------+------------------------+
|   1000000 | mariadb_sydney.cluster |
+-----------+------------------------+

MariaDB Sydney（ID 75）の一般的なログをもう一度見ると、最初のクエリと同じように同じ処理イベントが発生しました：

  75 Connect  [email protected] as anonymous on 
  75 Query    SELECT COUNT(id),@@hostname FROM sbtest.sbtest1
  75 Quit

この観察から、パフォーマンスを測定し、後続の同一のクエリに対してよりスマートになるために、MaxScaleが最初のクエリに失敗しなければならない場合があると結論付けることができます。アプリケーションは、クライアントに戻る前、またはトランザクションを再試行する前に、この「最初のエラー」を適切に処理できる必要があります。

サーバー用UNIXソケット実行中のMySQLまたはMariaDBサーバーに接続する方法は複数あります。ホストIPアドレスとポート（リモート接続）、Windowsの名前付きパイプ/共有メモリ、またはUnixベースのシステムのUnixソケットファイルを使用して、標準のネットワークTCP/IPを使用できます。 UNIXソケットファイルは、異なるプロセス（この場合はMySQLクライアントとサーバー）間の通信を容易にする特別な種類のファイルです。ソケットファイルはファイルベースの通信であり、別のマシンからソケットにアクセスすることはできません。 TCP / IPよりも高速な接続（ネットワークオーバーヘッドなし）と、同じコンピューター上のサービスまたはプロセスに接続する場合にのみ使用できるため、より安全な接続アプローチを提供します。

MaxScaleサーバーがMariaDBサーバー自体にもインストールされているとすると、代わりにソケットUNIXソケットファイルを使用できます。 [サーバー]セクションで、「アドレス」行を削除またはコメント化し、ソケットファイルの場所を含むソケットパラメータを追加します。

[DB_2]
type=server
protocol=mariadbbackend
#address=54.255.133.39
socket=/var/lib/mysql/mysql.sock

上記の変更を適用する前に、ローカルホストからMaxScaleaxscaleユーザーを作成する必要があります。マスターサーバーの場合：

MariaDB> CREATE USER 'maxscale'@'localhost' IDENTIFIED BY 'maxscalep4ss';
MariaDB> GRANT SELECT ON mysql.user TO 'maxscale'@'localhost';
MariaDB> GRANT SELECT ON mysql.db TO 'maxscale'@'localhost';
MariaDB> GRANT SELECT ON mysql.tables_priv TO 'maxscale'@'localhost';
MariaDB> GRANT SHOW DATABASES ON *.* TO 'maxscale'@'localhost';

再起動後、MaxScaleは実際のアドレスの代わりにUNIXソケットパスを表示し、サーバーリストは次のように表示されます：

ご覧のとおり、状態とGTID情報はソケット接続を介して正しく取得されます。このDB_2は、リモート接続用にポート3306を引き続きリッスンしていることに注意してください。これは、MaxScaleが監視のためにこのサーバーに接続するためにソケットを使用していることを示しています。

ソケットを使用すると、ローカル接続のみが許可され、より安全になるため、常に優れています。ネットワークからMariaDBサーバーを閉じて（例：--skip-networking）、MaxScaleに「外部」接続を処理させ、UNIXソケットファイルを介してMariaDBサーバーに転送することもできます。

サーバーのドレイン

MaxScale 2.4では、バックエンドサーバーをドレインできます。つまり、既存の接続を引き続き使用できますが、サーバーへの新しい接続は作成されません。ドレイン機能を使用すると、アプリケーション側からのユーザーエクスペリエンスに影響を与えることなく、適切なメンテナンスアクティビティを実行できます。正常に閉じる必要のある実行中のクエリによっては、サーバーのドレインに時間がかかる場合があることに注意してください。

サーバーをドレインするには、次のコマンドを使用します。

後遺症は、次のいずれかの状態になる可能性があります。

ドレイン-サーバーがドレインされています。ドレイン-サーバーがドレインされました。サーバーが空になり、サーバーへの接続数が0に減少しました。メンテナンス-サーバーはメンテナンス中です。

サーバーがドレインされた後、MaxScaleの観点から見たMariaDBサーバーの状態は「メンテナンス」です：

サーバーがメンテナンスモードの場合、サーバーへの接続は作成されず、既存の接続は閉じられます。

結論

MaxScale 2.4は、以前のバージョンに比べて多くの改善と変更をもたらし、MariaDBサーバーとそのすべてのコンポーネントを処理するのに最適なデータベースプロキシです。