ApsaraDB RDS:コネクションプーリングの設定

トランザクションレベルの接続プーリング (推奨)

ユースケース

• アプリケーションが主に短時間接続を使用している。

• 接続が頻繁に作成される。

• 接続数が多く、MySQL データベースの接続制限に近づいている。

メリット

• アプリケーションとデータベース間の接続確立の頻度を減らし、MySQL データベースのメインスレッドへのオーバーヘッドを低減します。

• データベースへの総接続数を削減します。

仕組み

トランザクションレベルの接続プーリングを有効にすると、クライアントがセッションリクエストを開始した際、データベースプロキシはクライアントとのフロントエンド接続を確立しますが、すぐにデータベースへのバックエンド接続を作成するわけではありません。リクエストを処理する必要がある場合、プロキシはトランザクションレベルの接続プールで利用可能なバックエンド接続があるかを確認します。

• 利用可能な接続が存在する場合、プロキシはそれを再利用します。トランザクションが完了すると、プロキシはその接続をトランザクションレベルの接続プールに戻します。

• 利用可能な接続が存在しない場合、プロキシはデータベースへの新しいバックエンド接続を作成します。

複数のセッションが単一のバックエンド接続を共有できます。アクティブなトランザクションを持つセッションはバックエンド接続を占有しますが、非アクティブなトランザクションを持つセッションは占有しません。次の図に示します。

単一のバックエンド接続が時間とともに複数のセッションからのトランザクションリクエストを処理できるようにすることで、このモデルは次の利点を提供します。

• 接続頻度の削減：バックエンドはデータベースへの持続的接続を維持するため、新しい接続を頻繁に確立する必要がなくなり、データベースのメインスレッドへの負荷が軽減されます。

• 総接続数の削減：複数のセッションが同じバックエンド接続を共有するため、アイドル状態の接続がリソースを消費するのを防ぎ、データベースへの総接続数を削減します。

制限事項

• 以下の操作を実行すると、接続が閉じるまでロックされます。ロックされた接続は、再利用のために接続プールに戻されません。

  • `PREPARE` 文またはコマンドの実行。

  • 一時テーブルの作成。

  • ユーザー変数の変更。

  • 大容量パケット (例：16 MB 以上) の処理。

  • `LOCK TABLE` の使用。

  • 複数ステートメントのクエリの実行。

  • ストアドプロシージャの呼び出し。

• `FOUND_ROWS`、`ROW_COUNT`、および `LAST_INSERT_ID` 関数はサポートされていません。これらの関数を呼び出すことはできますが、その結果が正しいことは保証されません。

  • プロキシのバージョンが 1.13.11 以降の場合、SELECT SQL_CALC_FOUND_ROWS * FROM t1 LIMIT * 文の直後に SELECT FOUND_ROWS() コマンドを使用できます。ただし、MySQL はこの使用法を推奨しなくなりました。SELECT FOUND_ROWS() を SELECT COUNT(*) FROM tb1 に置き換えることを推奨します。詳細については、「FOUND_ROWS()」をご参照ください。

  • プロキシのバージョンが 1.13.11 以降の場合、INSERT 文の直後に SELECT LAST_INSERT_ID() 文を使用すると、正しいクエリ結果が保証されます。

注意事項

• wait_timeout が設定されている接続では、各リクエストが接続プールから接続を取得するため、クライアント側で wait_timeout の設定が有効にならない場合があります。wait_timeout 期間が経過すると、接続プール内のバックエンド接続のみが切断され、クライアント接続が切断されることはありません。

• sql_mode、character_set_server、collation_server、および time_zone 変数を除き、アプリケーションが他のセッションレベルのシステム変数に依存している場合、クライアントは接続確立後に明示的に `SET` 文を実行する必要があります。そうしないと、接続プールがシステム変数が変更された接続を再利用する可能性があります。

• 接続が再利用される可能性があるため、select connection_id() を実行して現在の接続のスレッド ID をクエリできます。

• 接続が再利用される可能性があるため、show processlist または SQL Explorer and Audit によって表示される IP アドレスとポートが、クライアントの実際の IP アドレスとポートと一致しない場合があります。

• データベースプロキシは、すべてのノードからの show processlist の結果をマージして返します。フロントエンドとバックエンドの接続のスレッド ID はマッピングできません。これにより、`KILL` コマンドが正常に実行されたにもかかわらず、エラーを報告する可能性があります。

セッションレベルの接続プーリング

ユースケース

• アプリケーションが主に短時間接続を使用している。

• 接続が頻繁に作成される。

メリット

アプリケーションとデータベース間の接続確立の頻度を減らし、MySQL データベースのメインスレッドへのオーバーヘッドを低減します。

仕組み

フロントエンド接続とバックエンド接続

アプリケーションなどのクライアントがデータベースとの接続を確立すると、データベースプロキシがミドルウェアとして機能します。次の図に示すように、接続をクライアントとデータベースプロキシ間のフロントエンド接続と、データベースプロキシとデータベース間のバックエンド接続に分割します。

コネクションプーリングが無効な場合の接続プロセス

コネクションプーリングが無効な場合、プロキシはセッションごとに新しいフロントエンド接続とバックエンド接続を作成します。

セッションレベルの接続プーリングの仕組み

セッションが確立されると、セッションレベルの接続プーリングはまずフロントエンド接続を作成します。次に、接続プールで利用可能なバックエンド接続があるかを確認します。

• 利用可能な接続が存在する場合、それは再利用されます。

• 利用可能な接続が存在しない場合、データベースとの新しいバックエンド接続が確立されます。

セッションが終了すると、プロキシはフロントエンド接続を切断し、バックエンド接続をプールに戻します。これにより、バックエンド接続が新しいセッションによって再利用できるようになり、データベースのメインスレッドへのオーバーヘッドが削減されます。

セッションレベルの接続プーリングでは、1 つのセッションがセッション終了まで 1 つのバックエンド接続を占有します。セッションが終了して初めて、バックエンド接続がプールに解放されます。次の図に示します。

制限事項

なし。

注意事項

セッションが終了するまで、そのバックエンド接続は、アイドル状態であっても、処理するトランザクションがなくても、他のセッションでは使用できません。したがって、セッションレベルの接続プーリングは、データベース接続の総数を削減するものではありません。