ApsaraDB RDS:読み書き分離の属性と読み取りウェイトの設定

モードの選択

読み書きモードでは、プロキシのアクセスポリシーに少なくとも 1 つのプライマリインスタンスと 1 つの読み取り専用インスタンスが必要です。このモードは、トランザクション分割と接続プールをサポートしています。

読み取り専用モードでは、少なくとも 1 つの読み取り専用インスタンスが必要です。プライマリインスタンスはルーティングに関与せず、トランザクション分割はサポートされません。各クライアント接続は、1 つの読み取り専用インスタンス上の単一の接続にマッピングされます。合計接続容量は、設定されたすべての読み取り専用インスタンスの接続数の合計に等しくなります。

Cluster Edition インスタンスの場合、読み書きモードは書き込みをプライマリノードにのみ送信し、読み取り専用モードは読み取りをセカンダリノードにラウンドロビン方式でルーティングします。データベースプロキシの IP ホワイトリストは、プライマリインスタンスのホワイトリストと自動的に同期されます。

エッジケースにおけるルーティング動作

以下の表は、読み書きモードで読み取り専用インスタンスが利用できない場合、および読み取り専用モードですべてのウェイトシナリオにおける動作を示しています。

読み取り専用モードでは、「転送なし」とは、プライマリインスタンスが読み取りリクエストを受け入れないことを意味します。プロキシに読み取り可能なインスタンスがない場合、クライアントは接続エラーを受信します。

読み書きモードでプライマリのウェイトが 0 に設定されている場合、読み取りリクエストはデフォルトではプライマリインスタンスに送信されません。読み取りリクエストがプライマリインスタンスに送信されるのは、読み取り専用ノードが異常な状態である場合、ヒントによってルーティングが強制される場合、またはトランザクション分割が有効になっている場合のみです。

アクティブなリクエスト数に基づく負荷分散 (推奨)

各リクエストを (アクティブなリクエスト数 / ノードのウェイト) の比率が最も低いノードにルーティングします。これにより、不均等な負荷にリアルタイムで適応し、低速なノードの影響を受けにくくなります。

プライマリのウェイトが 100、読み取り専用ノード 1 のウェイトが 200、読み取り専用ノード 2 のウェイトが 200 の場合の例：

ウェイトベースの負荷分散

ラウンドロビンアルゴリズムを使用して、ウェイト比率に厳密に従って読み取りリクエストを分散します。各スケジューリングラウンドで、current_weight の値が最も高いノードを選択し、その後、次のようにウェイトを調整します。

1. 選択： current_weight が最も高いノードを選択します。値が同じ場合は、設定リスト内の位置によって決まります。

2. 蓄積： 各ラウンドの後、すべてのノードの current_weight は、自身のウェイト分だけ増加します。

3. リセット： 選択されたノードの current_weight は、すべてのノードのウェイトの合計分だけ減少します。

プライマリのウェイトが 100、読み取り専用ノード 1 のウェイトが 200、読み取り専用ノード 2 のウェイトが 200 の場合の例：

サービス中断なしで読み取り専用インスタンスをオフラインにする

トラフィックを中断させることなく読み取り専用インスタンス (たとえば、プライマリ A と読み取り専用インスタンス B、C を持つクラスター内のインスタンス C) を削除するには：

1. RDS インスタンス ページに移動し、リージョンを選択して、プライマリインスタンス A の ID をクリックします。

2. 左側のナビゲーションペインで、[データベースプロキシ] をクリックします。[接続トポロジ管理] セクションで、[設定の変更] をクリックします。

3. [プロキシエンドポイント (ターミナル) 設定の変更] ダイアログで、読み取り専用ノード C の読み取りウェイトを 0 に設定します。

4. 読み取り専用インスタンス C の [モニタリングとアラート] ページに移動します。[セッション接続] セクションで、active_session メトリックをモニタリングし、それが 0 になるまで待機します。

   妥当な待機時間内に active_session が 0 にならない場合は、残りのセッションを手動で強制終了してください。

5. プライマリインスタンス A の[データベースプロキシ] タブで、プロキシエンドポイントから読み取り専用インスタンス C を削除します。

SQL ヒントを使用した特定の SQL 文のルーティング

SQL ヒントを使用して、特定のノードでステートメントを強制的に実行させることができます。これは、SELECT 内での書き込みや、常に読み取り専用インスタンスを使用する必要があるクエリに役立ちます。

High-availability Edition インスタンス：

• /*FORCE_MASTER*/ — 読み取りウェイトが 0 であっても、ステートメントをプライマリインスタンスにルーティングします

• /*FORCE_SLAVE*/ — ステートメントを読み取り専用インスタンスにルーティングします

Cluster Edition インスタンス：

• /*FORCE_MASTER*/ — 読み取りウェイトが 0 であっても、ステートメントをプライマリノードにルーティングします

• /*FORCE_SLAVE*/ — ステートメントをセカンダリノードにルーティングします

ステートメントの先頭にヒントを追加します：

/*FORCE_MASTER*/ SELECT * FROM table_name;

クロスゾーンレイテンシーの削減

単一障害点を回避するために、プライマリインスタンスに対して少なくとも 2 つの読み取り専用インスタンスを作成し、それらを異なるゾーンにデプロイします。最寄りアクセス機能を有効にして、クロスゾーンのトラフィックによるネットワークレイテンシーを最小限に抑えます。最寄りアクセス機能は、アプリケーションがプロキシに接続する方法を制御し、読み取りウェイトは、プロキシがバックエンドデータベースにリクエストをルーティングする方法を制御します。最適なパフォーマンスを得るには、両方を一緒に設定します。

読み取り専用インスタンスを追加した後も、プライマリインスタンスは読み取り可能ですか？

読み取り専用インスタンスを追加した後も、プライマリインスタンスは常に読み書き可能です。読み取り専用インスタンスを追加しても、プライマリインスタンスの読み書きの可否に影響はありません。

プライマリインスタンスには、独自の直接接続エンドポイントがあります。このエンドポイントはデータベースプロキシを経由せずにプライマリインスタンスに直接接続するため、読み取りウェイトの設定に関係なく、このエンドポイントを介してプライマリインスタンスは常に読み書き可能です。

プロキシエンドポイントは、読み書き分離に使用されます。プロキシエンドポイントを介して接続すると、読み取りおよび書き込みリクエストは、設定された読み取りウェイトに基づいてルーティングされます。プライマリインスタンスの読み取りウェイトが 0 に設定されている場合、プロキシはデフォルトで読み取りリクエストをプライマリインスタンスに転送しません。ただし、プライマリインスタンス自体は、直接接続エンドポイントを介して読み書き可能なままです。すべての読み取り専用インスタンスで遅延がしきい値を超えたり、利用できなくなったりした場合、ビジネスの継続性を確保するために、読み取りリクエストは自動的にプライマリインスタンスにルーティングされます。

プロキシエンドポイントを介した読み書きのルーティングを制御するには、[データベースプロキシ] 設定で読み取りウェイトを調整します。