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

ApsaraDB RDS:データベースプロキシ機能の注意事項

最終更新日:Mar 15, 2026

ApsaraDB RDS for MySQL のデータベースプロキシ機能をご利用になる前に、スムーズな利用のために以下の注意事項をご確認ください。

  • 汎用型プロキシは無料です。専用プロキシ、読み取り専用インスタンス、プライマリインスタンスは別途課金されます。

  • データベースプロキシで接続保持機能が有効になっていない場合、プライマリインスタンスまたは読み取り専用インスタンスの構成を変更すると、インスタンススイッチオーバーが発生する可能性があります。インスタンススイッチオーバーの影響の詳細については、「インスタンススイッチオーバーの影響」をご参照ください。

  • 読み取り専用インスタンスをプロキシ接続アドレスに追加するか、エンドポイントに接続されている読み取り専用インスタンスを再起動すると、新規接続と既存接続の両方からのリクエストは、新規または再起動された読み取り専用インスタンスにルーティングされます。

  • プロキシ接続アドレスから読み取り専用インスタンスを削除すると、そのインスタンスで実行中のステートメントは失敗します。アプリケーションに影響を与えることなく読み取り専用インスタンスをオフラインにするには、プロキシのマイナーエンジンバージョンを 2.8.41 以降にアップグレードし、プロキシの読み書き属性を Read/Write に設定します。詳細については、「データベースプロキシのマイナーエンジンバージョンのアップグレード」と「読み書き属性と読み取り重みの構成」をご参照ください。

  • プロキシ接続アドレスは、圧縮プロトコルをサポートしていません。

  • High-availability Edition を実行する RDS インスタンスの場合、max_prepared_stmt_count パラメーターは、プライマリインスタンスとその読み取り専用インスタンスで同じ値である必要があります。

  • データベースプロキシは 1:N 接続モデルを使用します。ご利用のアプリケーションがプロキシに接続すると、プロキシはプライマリインスタンスと構成されているすべての読み取り専用インスタンスへの接続を確立します。データベースプロキシ自体は、最大接続数を制限しません。この制限は、バックエンドデータベースノードの仕様によって決定されます。トランザクションレベルの接続プーリングが無効になっている場合、各クライアント接続はプライマリインスタンスとすべての読み取り専用インスタンスにそれぞれ対応する接続を作成します。データベースプロキシを有効にした後、プライマリインスタンスと読み取り専用インスタンスの最大接続仕様を可能な限り一貫性のあるものに保ってください。そうしないと、ご利用のアプリケーションの接続数は、接続制限が最も低いインスタンスによって制限されます。

  • プロキシ接続アドレスを使用する場合、トランザクション分割が無効になっていると、すべてのトランザクションリクエストはプライマリインスタンスにルーティングされます。

  • 読み書き分離のためにプロキシ接続アドレスを使用する場合、非トランザクション読み取りの読み取り整合性は保証されません。読み取り整合性を確保するには、読み取りリクエストをトランザクションにカプセル化するか、ヒント構文を使用してください。

  • 接続プール機能はデフォルトで有効になっており、これにより show processlist コマンドがアイドルユーザー接続を表示する可能性があります。プロキシ接続アドレスを使用する場合、show processlist コマンドはすべてのノードからの結果をマージして返します。

  • 複数ステートメントを実行するか、ストアドプロシージャを呼び出すと、現在の接続を介した後続のすべてのリクエストはプライマリノードにルーティングされます。読み書き分離を再開するには、現在の接続を閉じて新しい接続を確立する必要があります。

  • MySQL コマンドラインを使用して接続し、ヒントステートメントを実行する場合、コマンドに -c オプションを含めてください。そうしないと、MySQL コマンドラインツールはヒントをフィルタリングします。ヒント構文の詳細については、「ヒント構文の使用」をご参照ください。

  • プライマリインスタンスがロックされている場合、バージョン 2.9.5 以降のプロキシインスタンスはリリースされません。読み取りリクエストの処理は継続できますが、書き込みリクエストは処理できません。

  • プライマリインスタンスをリリースすると、データベースプロキシは自動的にリリースされ、リリース後の専用プロキシには課金されません。

  • プロキシは現在、VPC または vSwitch の切り替えをサポートしていないため、プライマリインスタンスの VPC を変更してもプロキシの VPC は変更されません。プロキシは引き続きプライマリインスタンスと通信できますが、変更された VPC を介してプロキシエンドポイントにアクセスすることはできません。

  • 特権アカウントを使用してアカウントのホスト範囲を構成する場合、プロキシは 10.1.2.% 形式の CIDR ブロックをサポートします。

  • データベースプロキシの IP ホワイトリストは、プライマリインスタンスの IP ホワイトリストと同じです。プライマリインスタンスの IP ホワイトリストを更新すると、データベースプロキシの IP ホワイトリストも更新されます。

  • 高遅延ネットワークにおいて、プロキシ接続アドレスを介してバイナリロギング (Binlog) をサブスクライブすると、Binlog ダンプのネットワークスループットがパフォーマンスボトルネックになる可能性があります。これにより、ダウンストリームシステムでレプリケーションの遅延が蓄積される場合があります。ご利用のアプリケーションまたはサービスでデータベースノードへの直接接続を構成して Binlog データをプルすることを推奨します。

  • ゾーンの移行により、最寄りアクセス機能が無効になる場合があります。

    移行後、デフォルトで新しいゾーンにアクセスでき、元のゾーンの最寄りアクセス機能は無効になります。プロキシ接続アドレスのターゲットゾーンをデフォルトゾーンとは異なるゾーンに変更すると、対応するゾーンの最寄りアクセス機能も無効になります。以下の表に、シナリオの例を示します。

    シナリオ

    元のプロキシ情報

    ターゲットプロキシ情報

    現在のプロキシインスタンスゾーン

    プロキシエンドポイント

    最寄りアクセス

    ターゲットプロキシインスタンスゾーン

    デフォルトプロキシエンドポイントゾーン

    ターゲットプロキシエンドポイントゾーン

    最寄りアクセス

    シナリオ 1:

    Zone A + Zone B から Zone A + Zone C へ移行

    Zone A

    Proxy endpoint a

    Zone A

    Zone A

    Zone A

    Zone A

    Zone A

    Zone C

    無効

    Zone B

    Proxy endpoint b

    Zone B

    Zone C

    Zone C

    Zone C

    Zone C

    Zone D

    無効

    シナリオ 2:

    Zone A + Zone B から Zone C + Zone D への移行

    Zone A

    Proxy endpoint a

    Zone A

    Zone C

    Zone C

    Zone C

    Zone C

    Zone E

    無効

    Zone B

    Proxy endpoint b

    Zone B

    Zone D

    Zone D

    Zone D

    Zone D

    Zone E

    無効

  • 最寄りアクセス機能は、専用プロキシのデプロイモード 1 のみでサポートされています。この機能が有効になっており、汎用型プロキシまたは別のデプロイモードに変更する場合は、構成を変更する前に最寄りアクセス機能を無効にする必要があります。最寄りアクセス機能を無効にする方法の詳細については、「最寄りアクセスの設定」をご参照ください。プロキシデプロイメントアーキテクチャの詳細については、「プロキシデプロイメントアーキテクチャ」をご参照ください。

説明

プロキシの CIDR ブロックを 10.1.2.0/24 として構成することはサポートされていません。