このトピックでは、RDS for MySQL のデータベースプロキシの使用に関する一般的な質問と問題について説明します。
目次
データベースプロキシとは
データベースプロキシは、データベースとアプリケーションサーバの間に位置するネットワークプロキシサービスです。アプリケーションからのすべてのリクエストをデータベースに転送し、自動読み書き分離、トランザクション分割、接続プール、接続の永続化などの高度な機能を提供します。高可用性、高性能、そして運用の容易さを実現するように設計されています。
汎用プロキシと専用プロキシの違い
汎用: 物理 CPU リソースを共有するため、コスト効率の高いオプションです。最大プロキシ仕様は 16 CPU コア (8 プロキシノード) で、このタイプは無料です。
専用: 専用の物理 CPU リソースを使用するため、より高いパフォーマンスの安定性を提供します。最大プロキシ仕様は 64 CPU コア (32 プロキシノード) で、このタイプは従量課金制です。
詳細については、汎用プロキシと専用プロキシ、プロキシノード数とプロキシ仕様の関係、およびデータベースプロキシの料金をご参照ください。
データベースプロキシはプライマリインスタンスの QPS や TPS を使用するか
いいえ、使用しません。
プロキシ接続アドレスは通常のインスタンスエンドポイントと同じか
いいえ、異なります。
通常のインスタンスエンドポイントは、すべてのリクエストをその特定のインスタンスにルーティングします。
プロキシ接続アドレスは、SQL ステートメントに基づいて読み取りリクエストと書き込みリクエストを自動的に識別します。書き込みリクエストをプライマリインスタンスに転送し、読み取りリクエストを読み取り専用インスタンスに転送します。このプロセスにより、読み書き分離が実現され、プライマリインスタンスの負荷が軽減されます。
データベースプロキシを有効にした後、プライマリインスタンスと読み取り専用インスタンスの元のエンドポイントは回収されるか
いいえ。
データベースプロキシの内部ネットワークタイプはプライマリインスタンスと同じか
データベースプロキシの内部ネットワークは常に VPC です。
データベースプロキシのアーキテクチャとフェールオーバーのサポート
データベースプロキシは、高可用性のデュアルプライマリノードアーキテクチャを採用しています。トラフィックは 2 つのノード間で 1:1 の比率で分散されます。一方のノードに障害が発生した場合、もう一方のノードがすべてのトラフィックを引き継ぎます。障害が発生したノードを再構築するタスクが自動的にトリガーされ、高可用性が維持されます。
デプロイメントアーキテクチャの詳細については、「プロキシのデプロイメントアーキテクチャ」をご参照ください。
プロキシ仕様とノード仕様の関係
プロキシ仕様 = すべてのプロキシノード仕様の合計
たとえば、専用プロキシがデュアルゾーンデプロイメント (アベイラビリティゾーン A とアベイラビリティゾーン B) でデプロイされているとします。アベイラビリティゾーン A には 2 つのプロキシノードがあり、それぞれのプロキシノード仕様は 1 CPU コアです。アベイラビリティゾーン B には 2 つのプロキシノードがあり、それぞれのプロキシノード仕様は 2 CPU コアです。合計プロキシ仕様は次のように計算されます：(1 CPU コア × 2) + (2 CPU コア × 2) = 2 CPU コア + 4 CPU コア = 6 CPU コア。
プロキシノードと仕様の関係
プロキシノード数 = プロキシ仕様 / ユニットあたりの仕様 (ユニットあたりの仕様は 2 CPU コアで固定)
たとえば、プロキシ仕様が 6 CPU コアの場合、プロキシノード数は 3 (6 / 2) です。
プロキシノード仕様の制限
単一プロキシノードの仕様は、汎用タイプで 1〜8 CPU コア、専用タイプで 1〜16 CPU コアの範囲です。
同じアベイラビリティゾーン内のすべてのプロキシノードは、同じ仕様である必要があります。
2 つのノードを持つデュアルゾーンデプロイメントでは、両方のノードが同じ仕様である必要があります。
異なるアベイラビリティゾーンのプロキシノードは、異なる仕様を持つことができます。汎用プロキシの場合、異なるアベイラビリティゾーンのプロキシノードで同じ仕様を使用することを推奨します。
プロキシノードとエンドポイントの関係
いいえ
RDS インスタンスでデータベースプロキシを有効にすると、1〜7 個のプロキシエンドポイントを作成できます。各プロキシエンドポイントに対して、1 つの内部エンドポイントと 1 つのパブリックエンドポイントを作成できます。詳細については、「プロキシエンドポイントの追加」をご参照ください。
プロキシエンドポイントを追加するとパフォーマンスは向上するか
いいえ、向上しません。
データベースプロキシのパフォーマンスは、RDS High-availability Edition インスタンスの場合は読み取り専用インスタンスの数とプロキシノードの数 (プロキシ仕様) に依存します。RDS Cluster Edition インスタンスの場合は、セカンダリインスタンスの数とプロキシノードの数 (プロキシ仕様) に依存します。
読み取り専用インスタンス (High-availability Edition の場合) またはセカンダリインスタンス (Cluster Edition の場合) の数を増やすと、データベースプロキシの読み取り処理能力が向上します。
プロキシノードの数 (プロキシ仕様) を増やすと、データベースプロキシ全体のパフォーマンスが向上します。
データベースプロキシの接続数制限
データベースプロキシは最大接続数を制限しません。この制限は、ご利用のデータベースのコンピュートノードの仕様によって決まります。
接続タイムアウトエラーの対処法
wait_timeout パラメーターの値を増やして、再度接続を試みてください。インスタンスパラメーターの変更方法の詳細については、「ApsaraDB RDS for MySQL インスタンスのパラメーターを設定する」をご参照ください。
プロキシエンドポイントの変更
はい。
プロキシ接続アドレス (読み書き分離エンドポイント) を変更できます。詳細については、「プロキシエンドポイントの変更」をご参照ください。
プライマリインスタンスへの読み取りリクエストの送信
はい。
読み取り重みの配分を設定する際に、プライマリインスタンスに読み取り重みを割り当てることができます。プライマリインスタンスに読み取り重みを割り当てる方法の詳細については、「ApsaraDB RDS for MySQL インスタンスのデータベースプロキシ機能を有効にする」をご参照ください。
読み書き分離におけるヒントのサポート
はい。ヒントを使用して、リクエストを強制的にプライマリインスタンスで実行させることができます。RDS の読み書き分離でサポートされているヒントの形式の詳細については、「デフォルトの読み取り重み割り当てルール」の「ヒントを使用して SQL ステートメントをプライマリインスタンスまたは読み取り専用インスタンスのどちらに送信するかを指定する」セクションをご参照ください。
変更した読み取り重みが有効にならない
読み取り重みを変更した後、新しい重みに基づいて分散されるのは新しい接続のみです。既存の接続は影響を受けません。
読み取り重みと負荷の不均衡
ノード間の負荷分散が設定された読み取り重みと一致しない場合は、以下を確認してください：
リクエストがトランザクションの一部であるかどうかを確認します。トランザクション内のすべてのリクエストはプライマリインスタンスにルーティングされます。トランザクション分割を有効にすることで、プライマリインスタンスの負荷を軽減できます。
接続がプロキシ接続アドレス経由でのみ行われていることを確認してください。プライマリインスタンスまたは読み取り専用インスタンスのエンドポイントを使用した接続は、読み取り重みの分散をバイパスします。
データベースプロキシなしでの読み取り重みの設定
データベースプロキシが無効になっている場合、読み取り専用インスタンスの読み取り重みを設定することはできません。ただし、アプリケーションコードでプライマリインスタンスと読み取り専用インスタンスの個別のエンドポイントを使用することで、読み書き分離と負荷分散を実現することは可能です。
利用不可の読み取り専用インスタンスに対する接続フェールオーバー
いいえ、障害が発生したインスタンスへの既存の接続は自動的にフェールオーバーされません。障害が発生した接続がタイムアウトした後にのみ、正常なインスタンスへの新しい接続が確立されます。
データベースプロキシサービスを有効にした後の読み書き分離の検証方法
「読み書き分離の検証」をご参照ください。
新しい読み取り専用インスタンスへの自動データ同期
はい。読み書き分離のためにデータベースプロキシを有効にすると、既存データはプライマリインスタンスから読み取り専用インスタンスに自動的に同期されます。手動での操作は必要ありません。
プロキシの接続プールとアプリケーションの接続プールの比較
データベースプロキシは、アプリケーションのクライアントレベルのプールとは独立したプロキシレベルの接続プールを提供します。アプリケーションがすでに接続プールを使用している場合、プロキシの接続プールを使用する必要はありません。データベースプロキシの接続プールの詳細については、「接続プールの設定」をご参照ください。
クエリ結果の文字化けへの対処
次のコマンドを実行して、プライマリインスタンスと読み取り専用インスタンスで使用されている文字セットが一致しているか確認してください：
select
@@global.character_set_results,
@@global.character_set_client,
@@global.character_set_connection,
@@global.character_set_server;文字セットが一致しない場合、文字化けが発生することがあります。プライマリインスタンスまたは読み取り専用インスタンスの文字セットを変更して、それらが一致するようにしてください。インスタンスの文字セットの変更方法の詳細については、「ApsaraDB RDS for MySQL インスタンスの文字セット」をご参照ください。
DDL の自動同期
はい。データベースやテーブルの作成・削除、テーブル構造の変更、権限の変更など、すべての DDL 操作はプライマリインスタンスからそのセカンダリインスタンスに自動的に同期されます。
VPC と vSwitch ID の表示
インスタンスの [データベースプロキシ] ページで、[接続情報] セクションに移動します。情報を表示するには、次の図に示すように、[ポート] の右側にあるアイコンにポインターを合わせます。
ゾーン間移行がプライマリインスタンスに与える影響
プロキシノードをアベイラビリティゾーン間で移行すると、プロキシ接続アドレスを使用するワークロードのみが影響を受けます。プライマリインスタンスのエンドポイント、読み取り専用インスタンスのエンドポイント、クラスターの読み書きエンドポイント、クラスターの読み取り専用エンドポイント、またはノードレベルのエンドポイントを介した接続は影響を受けません。影響を最小限に抑えるには、ワークロードを影響を受けないエンドポイントに切り替え、オフピーク時に移行を実行してください。
プロキシのゾーン間移行の影響
プロキシをアベイラビリティゾーン間で移行すると、データベースプロキシを使用する接続で約 30 秒間の瞬断が発生する可能性があります。実際の影響時間はワークロードによって異なります。影響を最小限に抑えるには、ワークロードを影響を受けないエンドポイントに切り替え、オフピーク時に移行を実行してください。詳細については、「データベースプロキシのゾーン間移行」をご参照ください。
ゾーン間移行が最寄りアクセスに与える影響
利用できなくなる可能性があります。
設定変更時のアベイラビリティゾーンの変更
いいえ。
別のアベイラビリティゾーンに移行する必要がある場合は、「データベースプロキシのゾーン間移行」をご参照ください。
シングルゾーンデプロイメントへの変更時の vSwitchId エラーの解決
デュアルゾーンデプロイメント (例：アベイラビリティゾーン 1 とアベイラビリティゾーン 2) からシングルゾーンデプロイメント (例：アベイラビリティゾーン 1) に変更する場合、まずアベイラビリティゾーン 2 のプロキシ接続アドレスを削除する必要があります。詳細については、「プロキシエンドポイントの変更」をご参照ください。
解決されたプロキシ IP アドレスは固定か
いいえ、固定ではありません。接続には、解決された IP アドレスではなく、常にプロキシ接続アドレス (例: d3pswqe3jk9xwc5d****-rw4rm.rwlb.rds.aliyuncs.com) を使用してください。
プロキシエンドポイント経由の接続の検証
接続方法はセッション ID で識別できます。セッション ID が 16777215 未満の場合はインスタンスエンドポイント経由の接続を示し、それより大きい ID はプロキシ接続アドレス経由の接続を示します。
セッション ID はセッション管理で確認できます。
書き込み後すぐにデータが表示されない
一般的な原因: これは、レプリケーション遅延によりプライマリインスタンスに追いついていない読み取り専用インスタンスに、プロキシが読み取りリクエストをルーティングした場合に発生します。
ソリューション：
ヒントの使用：強い読み取り整合性が必要なクエリには、
/*FORCE_MASTER*/ヒントを使用してリクエストをプライマリインスタンスにルーティングします。トランザクション分割の無効化：強い読み取り整合性が必要なクエリをトランザクション内にカプセル化します。
整合性レベルの設定をグローバル整合性にします。
これらのソリューションはいずれも、より多くのクエリをプライマリインスタンスにルーティングするため、その負荷が増加する可能性があります。変更を加える前に、プライマリインスタンスのキャパシティを評価してください。特定の高い整合性が必要な読み取りリクエストのみをプライマリインスタンスにルーティングする推奨される方法として、ヒントの使用を推奨します。