すべてのプロダクト
Search
ドキュメントセンター

ApsaraDB RDS:接続プール機能の設定

最終更新日:Mar 19, 2024

アプリケーションとApsaraDB RDS for MySQLインスタンス間で短期間の接続などの接続が頻繁に確立されている場合、またはRDSインスタンスに許可されている接続の最大数に達している場合は、データベースプロキシ機能の接続プールを使用できます。 接続プールは、アプリケーションがRDSインスタンスに接続する頻度を減らし、RDSインスタンスのメインスレッドオーバーヘッドを減らし、RDSインスタンスへの接続の総数を減らすことができます。

接続プーリングタイプを選択する

ApsaraDB RDS for MySQLは、トランザクションレベルの接続プールとセッションレベルの接続プールをサポートしています。 ビジネス要件に基づいて、接続プーリングを使用するかどうか、および接続プーリングのタイプを決定できます。

データ型

シナリオ

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

  • ほとんどの場合、ワークロードでは短期間の接続が必要です。

  • 接続は頻繁に確立されます。

  • 接続数がRDSインスタンスでサポートされている最大接続数よりも多いこと。

上記のシナリオでは、トランザクションレベルの接続プール機能の制限がワークロードに影響しない場合、トランザクションレベルの接続プールを使用することを推奨します。 詳細については、「制限事項」をご参照ください。

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

  • ほとんどの場合、ワークロードでは短期間の接続が必要です。

  • 接続は頻繁に確立されます。

上記のシナリオでは、トランザクションレベルの接続プール機能の制限がワークロードに影響する場合、セッションレベルの接続プールを使用できます。 詳細については、「制限事項」をご参照ください。

接続プールは無効です

  • ほとんどの場合、ワークロードでは永続的な接続が必要です。

  • 接続の数は少ないです。

  • Druid、DBCP、c3p0、HikariCPなどの接続プールは、アプリケーションで使用されます。

接続プーリングタイプの概要

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

シナリオ

  • ほとんどの場合、ワークロードでは短期間の接続が必要です。

  • 接続は頻繁に確立されます。

上記のシナリオでは、トランザクションレベルの接続プール機能の制限がワークロードに影響する場合、セッションレベルの接続プールを使用できます。 詳細については、「制限事項」をご参照ください。

メリット

セッションレベルの接続プールは、アプリケーションがRDSインスタンスに接続する頻度を減らします。 これにより、RDSインスタンスのメインスレッドオーバーヘッドが削減されます。

働き主義

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

クライアントとデータベース間の接続は、データベースプロキシによって、フロントエンド接続とバックエンド接続の2つの部分に分割されます。 フロントエンド接続は、クライアントとデータベースプロキシ間の接続を指し、バックエンド接続は、データベースプロキシとデータベース間の接続を指す。 クライアントはアプリケーションとすることができる。 次の図は、接続を示しています。

接続プールが無効な接続

接続プーリングが無効になっている場合、クライアントによって開始されたセッションごとにフロントエンド接続とバックエンド接続が確立されます。 セッションが終了すると、フロントエンド接続とバックエンド接続の両方が閉じられます。 クライアントがセッションを再び開始すると、そのセッションのために新しいフロントエンドおよびバックエンド接続が確立される。 次の図は、接続を確立するプロセスを示しています。

クライアントがセッションを開始するたびに、バックエンド接続を確立する必要があります。 これにより、データベースのメインスレッドのオーバーヘッドが大きくなります。

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

セッションレベルの接続プールを有効にすると、クライアントがセッションを開始するときにフロントエンド接続が確立されます。 次に、システムは、利用可能なバックエンド接続について接続プールを検索する。

説明

バックエンド接続のuser、clientip、およびdbnameパラメーターの値が一致する場合、バックエンド接続は使用可能と見なされます。

  • 使用可能なバックエンド接続が存在する場合、接続が使用されます。

  • 使用可能なバックエンド接続が存在しない場合、バックエンド接続が確立されます。

セッションが終了すると、フロントエンド接続が閉じられ、バックエンド接続が接続プールによって再利用されます。 新しいセッションが開始されると、バックエンド接続を直接使用できます。

これにより、データベースプロキシとデータベースとの間の接続を確立する頻度およびデータベースのメインスレッドのオーバーヘッドが低減される。

次の図は、接続を確立するプロセスを示しています。

セッションレベルの接続プールを使用する場合、1つのセッションが1つのバックエンド接続を占有します。 バックエンド接続は、セッションが終了した後にのみ、接続プールによって再利用されます。

制限

なし。

使用上の注意

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

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

シナリオ

  • ほとんどの場合、ワークロードでは短期間の接続が必要です。

  • 接続は頻繁に確立されます。

  • 接続数が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_modecharacter_set_servercollation_servertime_zoneの変数と一致します。 リクエストに他のセッションレベルのシステム変数が含まれている場合は、リクエストの接続が確立された後に、アプリケーションでSETステートメントを明示的に実行してこれらの変数を構成する必要があります。 そうでなければ、システム変数が再構成されたコネクションをコネクションプールから選択して再利用することができる。

  • SELECT CONNECTION_ID() ステートメントを実行して、接続のスレッドIDを照会できます。 この方法で、接続が再利用されているかどうかを確認できます。

  • 既存の接続を再利用すると、SHOW PROCESSLISTステートメントまたはSQL Explorerおよび監査機能によって返されるIPアドレスおよびポート番号が、クライアントの実際のIPアドレスおよびポート番号と異なる場合があります。 詳細については、「SQLエクスプローラーと監査機能の使用」をご参照ください。

  • データベースプロキシは、すべてのプライマリ、セカンダリ、および読み取り専用RDSインスタンスからSHOW PROCESSLISTステートメントによって取得された結果をマージします。 その後、データベースプロキシは結果セットをアプリケーションに返します。 トランザクションレベルの接続プールを有効にすると、アプリケーションとデータベースプロキシ間の接続のスレッドIDが、データベースプロキシとデータベースシステム間の接続のスレッドIDと異なります。 その結果、プロセスが正常に終了した場合でも、killコマンドに対してエラーが返されることがあります。 この場合、SHOW PROCESSLISTステートメントを再度実行して、プロセスが終了したかどうかを確認できます。

接続プール機能の設定

前提条件

データベースプロキシ機能が有効になっています。 詳細については、「データベースプロキシ機能の有効化」をご参照ください。

注意事項

  • 接続プール機能は、アカウントに対するIP固有の権限をサポートしていません。 接続プール機能を有効にして、異なるIPアドレスを使用するアカウントにデータベースまたはテーブルのアクセス許可を付与すると、アクセス許可エラーが発生する可能性があります。 たとえば、アカウントは192.xx. xx.1 IPアドレスからログオンするとdatabase_aに対する権限を持ちますが、192.xx. xx.2 IPアドレスからログオンするとdatabase_aに対する権限を持ちません。 この場合、既存の接続が再利用されるときに許可エラーが発生する可能性があります。

  • データベースシステムのデータベースプロキシで提供される接続プール機能は、アプリケーションで提供される接続プールには影響しません。 アプリケーションが接続プールを提供している場合は、データベースシステムの接続プール機能を有効にする必要はありません。

  • 接続プーリング機能は、多数の低速SQLクエリによって引き起こされる接続蓄積の問題を解決することができません。 関連するSQLステートメントを最適化するか、RDSインスタンスの問題をトラブルシューティングすることを推奨します。

手順

  1. [インスタンス] ページに移動します。 上部のナビゲーションバーで、RDS インスタンスが存在するリージョンを選択します。 次に、RDSインスタンスを見つけ、インスタンスのIDをクリックします。
  2. 左側のナビゲーションペインで、[データベース] をクリックします。

  3. [接続情報] セクションで、次のいずれかの方法を使用して接続プール機能を有効にします。

    説明
    • デフォルトでは、接続プール機能は無効になっています。

    • 接続プーリングタイプが変更された後、変更は新しい接続に対してのみ有効になります。

    • 方法1: 接続プールを設定するimage.pngデータベースプロキシエンドポイントの右側にあるアイコンの上にポインターを移動します。 表示されるダイアログボックスで、[トランザクションレベルの接続プールの有効化] または [セッションレベルの接続プールの有効化] をクリックします。 表示されるダイアログボックスで [OK] をクリックします。

      image.png

    • 方法2: 接続プールを設定するデータベースプロキシエンドポイントを見つけ、[操作] 列の [設定の変更] をクリックします。 表示されるダイアログボックスで、[接続プール] の右側にある必要な接続プールのタイプを選択します。

      説明

      接続プール機能が有効になっている場合は、接続プールタイプを変更できます。

      image.png

関連する API 操作

API 操作

説明

DescribeDBProxy

ApsaraDB RDSインスタンスの専用プロキシに関する詳細を照会します。

DescribeDBProxyEndpoint

データベースプロキシエンドポイントに関する情報を照会します。

ModifyDBProxyEndpoint

データベースプロキシエンドポイントの接続設定を変更します。

条件

  • 短命の接続: 短期間しか開いていない接続。 たとえば、PHPアプリケーションが単純なクエリを実行するための接続が確立され、その後閉じられます。 利点は、長期間にわたって接続が占有されないことである。 欠点は、クライアントが要求を開始するたびに、接続を確立しなければならないことである。 これにより、データベースのメインスレッドのオーバーヘッドが増加します。

  • 永続的な接続: 長期間開いている接続。 例えば、ウェブサーバまたはアプリケーションサーバは、MySQLサーバへの多数の接続を確立し、ウェブサーバまたはアプリケーションサーバが停止するまで接続を開いたままにする。 接続は数ヶ月間開いたままであるかもしれません。 利点は、接続頻度が比較的小さく、データベースのメインスレッドのオーバーヘッドが小さいことです。 欠点は、接続が長期間開いていることです。

FAQ

接続プール機能を有効にするための最大接続数はいくつですか。

接続数がRDSインスタンスでサポートされている最大接続数を超える可能性がある場合は、トランザクションレベルの接続プールを有効にすることを推奨します。

接続プール内の接続はどのくらい存続できますか?

接続プール内の接続は、10秒間存続させることができます。

接続プール機能はインスタンスのパフォーマンスに影響しますか?

接続プール機能を有効にすると、短期間の接続シナリオでインスタンスのパフォーマンスが約10% 向上します。

トランザクションレベルの接続プーリングとセッションレベルの接続プーリングの違いは何ですか?

トランザクションレベルの接続プールは、RDSインスタンスのメインスレッドオーバーヘッドを削減するだけでなく、RDSインスタンスへの接続の総数も削減します。

セッションレベルの接続プールでは、RDSインスタンスのメインスレッドオーバーヘッドを減らすことしかできませんが、RDSインスタンスへの接続の総数を減らすことはできません。

トランザクションレベルの接続プーリングは、セッションレベルの接続プーリングとはどのように機能しますか?

データ型

セッション共有バックエンド接続

バックエンド接続が使用される時刻

バックエンド接続が再利用された時刻

セッションとバックエンド接続のマッピング

トランザクションレベルの接続プール

トランザクションが処理中です。

トランザクションが完了しました。 セッションは終了しない場合があります。

N:1

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

任意

セッションが作成中です。

セッションが終了します。

N:N

データベースプロキシがアプリケーションから切断されました。 アプリケーションとデータベースプロキシの両方が接続プール機能を使用しているために切断が発生しますか?

断線の原因は、実際の状況によって異なります。 接続プーリング機能を使用しているアプリケーションとデータベースプロキシが原因であるとは限りません。