アプリケーションとApsaraDB RDS for MySQLインスタンス間で短期間の接続などの接続が頻繁に確立されている場合、またはRDSインスタンスに許可されている接続の最大数に達している場合は、データベースプロキシ機能の接続プールを使用できます。 接続プールを使用すると、アプリケーションがRDSインスタンスに接続する頻度、RDSインスタンスのメインスレッドオーバーヘッド、およびRDSインスタンスへの接続の総数を減らすことができます。
接続プーリングタイプを選択する
ApsaraDB RDS for MySQLは、トランザクションレベルの接続プールとセッションレベルの接続プールをサポートしています。 ビジネス要件に基づいて、接続プーリングを使用するかどうか、および接続プーリングのタイプを決定できます。
タイプ | シナリオ |
トランザクションレベルの接続プール (推奨) | ワークロードでは短期間の接続が必要です。接続は頻繁に確立され、接続数はRDSインスタンスでサポートされる最大接続数に達します。 トランザクションレベルの接続プールの制限は、ワークロードには影響しません。 詳細については、「トランザクション接続プールの制限」をご参照ください。 |
セッションレベルの接続プール | ワークロードでは短命の接続が必要であり、接続は頻繁に確立されます。 ただし、トランザクションレベルの接続プールの制限は、ワークロードに影響します。 |
接続プールは無効です | ワークロードでは永続的な接続が必要で、少数の接続が確立され、Druid、DBCP、c3p0、HikariCPなどの接続プールがアプリケーションで使用されます。 |
接続プーリングタイプの概要
トランザクションレベルの接続プール (推奨)
シナリオ
ほとんどの場合、ワークロードでは短期間の接続が必要です。
接続は頻繁に確立されます。
接続数が、RDSインスタンスでサポートされている最大接続数に達しています。
メリット
トランザクションレベルの接続プールにより、アプリケーションがRDSインスタンスに接続する頻度と、RDSインスタンスのメインスレッドオーバーヘッドが削減されます。
トランザクションレベルの接続プールにより、RDSインスタンスへの接続の総数が減少します。
働き主義
トランザクションレベルの接続プーリングが有効になっている場合、クライアントはリクエストを開始するときにデータベースプロキシに接続します。 データベースプロキシは、データベースへのバックエンド接続をすぐには確立しません。 要求を処理する必要がある場合、データベースプロキシは、利用可能なバックエンド接続を求めて接続プールを検索する。
user
およびdbname
パラメーターの値が指定されたシステム変数の値と同じである場合、接続は使用可能と見なされます。
使用可能なバックエンド接続が存在する場合、接続が使用されます。 リクエスト内のトランザクションが完了した後、接続は接続プールによって再要求されます。
利用可能なバックエンド接続が存在しない場合、新しいバックエンド接続が確立される。
トランザクションレベルの接続プーリングにより、複数のセッションで1つのバックエンド接続を共有できます。 アクティブなトランザクションの接続はバックエンド接続を占有しますが、非アクティブなトランザクションの接続はバックエンド接続を占有しません。
一定期間内に、同じバックエンド接続が複数の進行中のセッションでトランザクションを処理できます。 これは次の利点を提供します。
データベースへの接続の頻度が減少します。
バックエンド接続は、接続頻度およびデータベースのメインスレッドのオーバーヘッドを低減するために、ある期間にわたって存続することができる。
データベースへの接続の総数が減少します。
複数の進行中のセッションがバックエンド接続を共有します。 これにより、アイドル接続がバックエンド接続リソースを占有するのを防ぎ、データベースへの接続の総数を減らします。 アイドル接続では、セッションが終了しないとき、フロントエンド接続は非アクティブになります。
データベースプロキシ機能は、接続の最大数を制限しません。 この数は、RDSインスタンスの仕様によって異なります。
制限事項
次のいずれかの操作を実行すると、接続が閉じられるまで接続がロックされます。 これは、接続プールによって接続を再利用できないことを示します。
PREPAREステートメントを実行します。
一時テーブルを作成します。
ユーザー変数を変更します。
16 MB以上のサイズのパケットなど、大きなパケットを処理します。
LOCK TABLEステートメントを実行します。
複数文クエリを実行します。
ストアドプロシージャを呼び出します。
FOUND_ROWS、ROW_COUNT、およびLAST_INSERT_ID関数はサポートされていません。 これらの関数を呼び出すことはできますが、これらの関数によって返される結果は不正確な場合があります。
使用するデータベースプロキシのバージョンがV1.13.11以降の場合、
SELECT SQL_CALC_FOUND_ROWS * FROM LIMIt1 T *
ステートメントの後にSELECT FOUND_ROWS()
ステートメントを実行できます。 この方法は、オープンソースMySQLでは推奨されなくなりました。SELECT FOUND_ROWS()
ステートメントをSELECT COUNT(*) FROM tb1
ステートメントに置き換えることができます。 詳細については、「FOUND_ROWS() 」をご参照ください。使用するデータベースプロキシのバージョンがV1.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および監査機能によって返されるIPアドレスおよびポート番号が、クライアントの実際のIPアドレスおよびポート番号と異なる場合があります。 詳細については、「SQLエクスプローラーと監査機能の使用」をご参照ください。データベースプロキシは、すべてのプライマリ、セカンダリ、および読み取り専用RDSインスタンスから
SHOW PROCESSLIST
ステートメントによって取得された結果をマージします。 その後、データベースプロキシは結果セットをアプリケーションに返します。 トランザクションレベルの接続プーリングを有効にすると、フロントエンド接続のスレッドIDがバックエンド接続のスレッドIDと異なります。 その結果、プロセスが正常に終了した場合でも、killコマンドに対してエラーが返されることがあります。 この場合、SHOW PROCESSLISTステートメント
を再度実行して、プロセスが終了したかどうかを確認できます。
セッションレベルの接続プール
シナリオ
ほとんどの場合、ワークロードでは短期間の接続が必要です。
接続は頻繁に確立されます。
メリット
トランザクションレベルの接続プールにより、アプリケーションがRDSインスタンスに接続する頻度と、RDSインスタンスのメインスレッドオーバーヘッドが削減されます。
働き主義
フロントエンド接続とバックエンド接続
クライアントとデータベース間の接続は、データベースプロキシによって、フロントエンド接続とバックエンド接続の2つの部分に分割されます。 フロントエンド接続は、クライアントとデータベースプロキシとの間の接続を指す。 バックエンド接続は、データベースプロキシとデータベース間の接続を指します。 クライアントはアプリケーションとすることができる。
接続プーリングが無効な接続確立
接続プーリングが無効になっている場合、クライアントによって開始されたセッションごとにフロントエンド接続とバックエンド接続を確立する必要があります。 これにより、データベースのメインスレッドのオーバーヘッドが増加します。
セッションレベルの接続プールの仕組み
セッションレベルの接続プールを有効にすると、クライアントがセッションを開始するときにフロントエンド接続が確立されます。 次に、システムは、利用可能なバックエンド接続について接続プールを検索する。
バックエンド接続のuser、clientip、およびdbnameパラメーターの値が一致する場合、バックエンド接続は使用可能と見なされます。
使用可能なバックエンド接続が存在する場合、接続が使用されます。
利用可能なバックエンド接続が存在しない場合、新しいバックエンド接続が確立される。
セッションが終了すると、フロントエンド接続が閉じられ、バックエンド接続が接続プールによって再利用されます。 新しいセッションが開始されると、バックエンド接続を直接使用できます。 これにより、データベースのメインスレッドのオーバーヘッドが削減されます。
次の図は、接続を確立するプロセスを示しています。
セッションレベルの接続プールを使用する場合、1つのセッションが1つのバックエンド接続を占有します。 バックエンド接続は、セッションが終了した後にのみ、接続プールによって再利用されます。
制限事項
非該当
使用上の注意
セッションが終了する前に、セッションがアイドルであり、トランザクションを処理する必要がない場合でも、セッションのバックエンド接続を他のセッションで使用することはできません。 その結果、データベースへの接続の総数は減少しません。
接続プール機能の設定
前提条件
データベースプロキシ機能が有効になっています。 詳細については、「データベースプロキシ機能の有効化」をご参照ください。
使用上の注意
接続プール機能は、アカウントに対するIP固有の権限をサポートしていません。 接続プール機能を有効にして、異なるIPアドレスを使用するアカウントにデータベースまたはテーブルのアクセス許可を付与すると、アクセス許可エラーが発生する可能性があります。 たとえば、アカウントは192.xx. xx.1 IPアドレスからログオンするとdatabase_aに対する権限を持ちますが、192.xx. xx.2 IPアドレスからログオンするとdatabase_aに対する権限を持ちません。 この場合、既存の接続が再利用されるときに許可エラーが発生する可能性があります。
データベースシステムのデータベースプロキシで提供される接続プール機能は、アプリケーションで提供される接続プールには影響しません。 アプリケーションが接続プールを提供している場合は、データベースシステムの接続プール機能を有効にする必要はありません。
接続プーリング機能は、多数の低速SQLクエリによって引き起こされる接続蓄積の問題を解決することができません。 関連するSQLステートメントを最適化するか、RDSインスタンスの問題をトラブルシューティングすることを推奨します。
データベースプロキシのバージョンが2.9.1より前の場合、読み取り専用属性を持つデータベースプロキシエンドポイントの接続プールを構成することはできません。 データベースプロキシのバージョンが2.9.1以降の場合、読み取り /書き込み属性または読み取り専用属性を持つデータベースプロキシエンドポイントの接続プールを構成できます。
手順
[インスタンス] ページに移動します。 上部のナビゲーションバーで、RDS インスタンスが存在するリージョンを選択します。 次に、RDSインスタンスを見つけ、インスタンスのIDをクリックします。
左側のナビゲーションウィンドウで、データベースプロキシをクリックします。
[接続情報] セクションで、次のいずれかの方法を使用して接続プール機能を有効にします。
説明デフォルトでは、接続プール機能は無効になっています。
接続プーリングタイプが変更された後、変更は新しい接続に対してのみ有効になります。
方法1: 接続プールを設定する
データベースプロキシエンドポイントの右側にあるアイコンの上にポインターを移動します。 表示されるダイアログボックスで、[トランザクションレベルの接続プールの有効化] または [セッションレベルの接続プールの有効化] をクリックします。 表示されるダイアログボックスで [OK] をクリックします。
方法2: 接続プールを設定するデータベースプロキシエンドポイントを見つけ、[操作] 列の [設定の変更] をクリックします。 表示されるダイアログボックスで、[接続プール] の右側にある必要な接続プールのタイプを選択します。
説明接続プール機能が有効になっている場合は、接続プールタイプを変更できます。
関連する API 操作
操作 | 説明 |
ApsaraDB RDSインスタンスの専用プロキシに関する詳細を照会します。 | |
データベースプロキシエンドポイントに関する情報を照会します。 | |
データベースプロキシエンドポイントの接続設定を変更します。 |
条件
短期間の接続: 短期間だけ開いている接続。 たとえば、PHPアプリケーションが単純なクエリを実行するための接続が確立され、その後閉じられます。 利点は、接続リソースが長期間占有されないことである。 欠点は、クライアントが要求を開始するたびに接続を確立しなければならないことである。 これにより、データベースのメインスレッドのオーバーヘッドが増加します。
永続的な接続: 長期間開いている接続。 例えば、ウェブサーバまたはアプリケーションサーバは、MySQLサーバへの多数の接続を確立し、ウェブサーバまたはアプリケーションサーバが停止するまで接続を開いたままにする。 利点は、接続が低頻度で確立され、メインスレッドのオーバーヘッドを低減することである。 欠点は、接続リソースが長時間占有されることである。
よくある質問
接続プール機能を有効にするための最大接続数はいくつですか。
接続数がRDSインスタンスでサポートされている最大接続数を超える可能性がある場合は、トランザクションレベルの接続プールを有効にすることを推奨します。
接続プール内の接続はどのくらい存続できますか?
接続プール内の接続は、10秒間存続させることができます。
接続プール機能はインスタンスのパフォーマンスに影響しますか?
接続プール機能を有効にすると、短期間の接続シナリオでインスタンスのパフォーマンスが約10% 向上します。
トランザクションレベルの接続プーリングとセッションレベルの接続プーリングの違いは何ですか?
トランザクションレベルの接続プールは、RDSインスタンスのメインスレッドオーバーヘッドを削減するだけでなく、RDSインスタンスへの接続の総数も削減します。
セッションレベルの接続プールでは、RDSインスタンスのメインスレッドオーバーヘッドを減らすことしかできませんが、RDSインスタンスへの接続の総数を減らすことはできません。
トランザクションレベルの接続プーリングは、セッションレベルの接続プーリングとはどのように機能しますか?
タイプ | セッション共有バックエンド接続 | バックエンド接続が使用される時刻 | バックエンド接続が再利用された時刻 | セッションとバックエンド接続のマッピング |
トランザクションレベルの接続プール | 対象 | トランザクションが処理中です。 | トランザクションが完了しました。 セッションは終了しない場合があります。 | N:1 |
セッションレベルの接続プール | 非対象 | セッションが作成中です。 | セッションが終了します。 | N:N |
データベースプロキシがアプリケーションから切断されました。 アプリケーションとデータベースプロキシの両方が接続プール機能を使用しているために切断が発生しますか?
断線の原因は、実際の状況によって異なります。 接続プーリング機能を使用しているアプリケーションとデータベースプロキシが原因であるとは限りません。