次の方法で共有

Azure Database for PostgreSQL - フレキシブル サーバーの読み取りレプリカ

  • [アーティクル]

適用対象: Azure Database for PostgreSQL - フレキシブル サーバー

読み取りレプリカ機能を使用すると、データを Azure Database for PostgreSQL フレキシブル サーバー インスタンスから読み取り専用レプリカにレプリケートできます。 レプリカは、PostgreSQL エンジンのネイティブの物理レプリケーション テクノロジを使用して非同期的に更新されます。 レプリケーション スロットを使用したストリーミング レプリケーションが、既定の動作モードです。 必要に応じて、遅れを取り戻すためにファイルベースのログ配布が使用されます。 プライマリ サーバーから最大 5 つのレプリカにレプリケートできます。

レプリカは、通常の Azure Database for PostgreSQL フレキシブル サーバー インスタンスと同様に管理する新しいサーバーです。 読み取りレプリカごとに、仮想コアおよびストレージのプロビジョニング済みコンピューティング (GB/月) に対して課金されます。

レプリカを作成して管理する方法を参照してください。

読み取りレプリカを使用する場合

読み取りレプリカ機能は、読み取り集中型ワークロードのパフォーマンスとスケールの向上に役立ちます。 書き込みワークロードをプライマリに振り向けながら、読み取りワークロードはレプリカに分離することができます。 読み取りレプリカは別のリージョンにデプロイすることもでき、ディザスター リカバリーが必要な場合には読み取り/書き込みサーバーとして昇格させることができます。

BI ワークロードおよび分析ワークロードでレポート用のデータ ソースとして読み取りレプリカを使用するのが、一般的なシナリオです。

レプリカは読み取り専用であるため、プライマリへの書き込み容量の負担を直接減らすことにはなりません。

考慮事項

読み取りレプリカは主に、クエリのオフロードにメリットがあり、多少の遅延には対処できるシナリオ向けに設計されています。 これらは、ほとんどのワークロードでプライマリからほぼリアルタイムで更新が提供されるように最適化されているため、読み取り負荷の高いシナリオに最適なソリューションになります。 ただし、最新のデータ精度が求められる同期レプリケーション シナリオ向けではないことを知っておくことが重要です。 レプリカ上のデータは最終的にプライマリと一致しますが、遅延が発生する可能性があり、通常は数秒から数分の範囲ですが、負荷の高いワークロードや待機時間の長いシナリオでは、遅延が数時間に及ぶことがあります。 通常、プライマリと同じリージョンの読み取りレプリカは geo レプリカよりも遅れが少なくなります。後者は地理的な距離による遅延を伴うことがよくあるためです。 geo レプリケーションのパフォーマンスへの影響の詳細については、geo レプリケーションに関する記事を参照してください。 レプリカ上のデータは、最終的にプライマリ上のデータと整合します。 この機能は、この遅延に対応できるワークロードに使用してください。

Note

ほとんどのワークロードの場合、読み取りレプリカによってプライマリからのほぼリアルタイムの更新が提供されます。 しかし、プライマリのワークロードが永続的に高負荷で、かつ書き込み集中型の場合、レプリケーションのラグが増加し続け、プライマリにしか追いつけない可能性があります。 これにより、WAL ファイルはレプリカで受信されてはじめて削除されるため、プライマリでのストレージの使用量が増加する可能性もあります。 この状況が続く場合は、書き込み集中型のワークロードが完了した後に読み取りレプリカを削除して再作成することで、ラグに関してレプリカを良好な状態に戻すことができます。 非同期読み取りレプリカは、このような負荷の高い書き込みのワークロードには適していません。 アプリケーションについて読み取りレプリカを評価するときは、ピークと非ピークのときを通してアプリの完全なワークロード サイクルについてレプリカの時間差を監視し、ワークロード サイクルのさまざまなポイントで発生する可能性がある時間差と予想される RTO/RPO を評価してください。

レプリカの作成

Azure Database for PostgreSQL フレキシブル サーバーのプライマリ サーバーは、サービスをサポートする任意のリージョンにデプロイできます。 プライマリ サーバーのレプリカは、同じリージョン内または、Azure Database for PostgreSQL フレキシブル サーバーを利用できる別のグローバル Azure リージョン間で作成できます。 レプリカを作成する機能は、現在、一部の特別な Azure リージョンにも展開されています。 レプリカを作成できる特別なリージョンの一覧については、geo レプリケーションに関する記事を参照してください。

レプリカ作成ワークフローを開始すると、空の Azure Database for PostgreSQL フレキシブル サーバー インスタンスが作成されます。 新しいサーバーには、プライマリ サーバー上のデータが設定されます。 同じリージョンでのレプリカの作成には、スナップショットの手法が使用されます。 そのため、作成の時間はデータのサイズに依存しません。 geo レプリカはプライマリ インスタンスのベース バックアップを使用して作成されてから、ネットワーク経由で送信されるため、作成時間はプライマリのサイズに応じて数分から数時間の範囲になる場合があります。

レプリカは、プライマリ インスタンスのバックアップ全体をレプリカにコピーする必要があり、トランザクション ログを 1 GB 以下のラグと同期する必要があるという 2 つの条件が満たされた場合にのみ、正常に作成されたと見なされます。

作成操作を成功させるために、トランザクション負荷が高い時間帯にレプリカを作成しないようにしてください。 たとえば、他のソースから Azure Database for PostgreSQL フレキシブル サーバーに移行するとき、または大量の一括読み込み操作中にはレプリカを作成しないようにする必要があります。 今すぐデータを移行する、または大量のデータを読み込む場合は、最初にこのタスクを完了することをお勧めします。 完了したら、レプリカの設定を開始できます。 移行または一括読み込み操作が完了したら、トランザクション ログのサイズが通常のサイズに戻ったかどうかをチェックします。 通常、トランザクション ログのサイズは、インスタンスの max_wal_size サーバー パラメーターで定義されている値に近い必要があります。 トランザクション ログ ストレージ使用量メトリックを使用して、 トランザクション ログ ストレージ のメモリ占有領域を追跡できます。これにより、トランザクション ログによって使用されるストレージの量に関する分析情報が提供されます。 このメトリックを監視することで、トランザクション ログのサイズが予想される範囲内にあり、レプリカ作成プロセスが開始される可能性があることを確認できます。

重要

読み取りレプリカは現在、General Purpose およびメモリ最適化のサーバー コンピューティング レベルでサポートされています。 バースト可能サーバー コンピューティング レベルはサポートされていません。

重要

レプリカの作成、削除、昇格の操作を実行すると、プライマリ サーバーは更新中の状態になります。 この間、サーバー パラメーターの変更、高可用性オプションの変更、ファイアウォールの追加または削除などのサーバー管理操作は使用できなくなります。 更新状態はサーバー管理操作にのみ影響し、データ プレーンの操作には影響しないことに注意してください。 つまり、データベース サーバーは引き続き完全に機能し、接続を受け入れ、読み取りおよび書き込みトラフィックを処理できます。

Azure portal で読み取りレプリカを作成する方法を確認してください。

構成管理

Azure Database for PostgreSQL フレキシブル サーバーの読み取りレプリカを設定する場合は、調整できるサーバー構成、プライマリから継承される構成、および関連する制限事項を理解することが不可欠です。

継承される構成

読み取りレプリカが作成されるときに、プライマリ サーバーから特定のサーバー構成が継承されます。 これらの構成は、レプリカの作成時または設定後に変更できます。 ただし、geo バックアップなどの特定の設定は読み取りレプリカにレプリケートされません。

レプリカ作成時の構成

  • レベル、ストレージ サイズ: "プライマリ サーバーへの昇格" 操作の場合は、プライマリと同じである必要があります。 "独立したサーバーに昇格し、レプリケーションから削除する" 操作では、プライマリと同じかそれ以上にすることができます。
  • パフォーマンス レベル (IOPS): 調整可能。
  • データ暗号化: 調整可能。サービスマネージド キーからカスタマー マネージド キーへの移行が含まれます。

作成後の構成

  • ファイアウォール規則: 追加、削除、または変更できます。
  • レベル、ストレージ サイズ: "プライマリ サーバーへの昇格" 操作の場合は、プライマリと同じである必要があります。 "独立したサーバーに昇格し、レプリケーションから削除する" 操作では、プライマリと同じかそれ以上にすることができます。
  • パフォーマンス レベル (IOPS): 調整可能。
  • 認証方法: 調整可能。オプションには、PostgreSQL 認証から Microsoft Entra への切り替えが含まれます。
  • サーバー パラメーター: ほとんどは調整可能です。 ただし、共有メモリ サイズに影響を与えるものは、特に "プライマリ サーバーへの昇格" の可能性があるシナリオでは、プライマリと一致させる必要があります。 "独立したサーバーに昇格し、レプリケーションから削除する" 操作では、これらのパラメーターはプライマリと同じかそれ以上にする必要があります。
  • メンテナンス スケジュール: 調整可能。

読み取りレプリカでサポートされていない機能

特定の機能はプライマリ サーバーに限定されており、読み取りレプリカでは設定できません。 これには以下が含まれます。

  • geo バックアップを含むバックアップ。
  • 高可用性 (HA)

ソースの Azure Database for PostgreSQL フレキシブル サーバー インスタンスがカスタマー マネージド キーで暗号化されている場合、その他の考慮事項についてはこちらのドキュメントを参照してください。

レプリカへの接続

レプリカを作成すると、プライマリ サーバーのファイアウォール規則または仮想ネットワーク サービス エンドポイントが継承されます。 これらの規則は、レプリカの作成時およびその後の任意の時点で変更できます。

レプリカの管理者アカウントは、プライマリ サーバーから継承されます。 プライマリ サーバー上のすべてのユーザー アカウントが、読み取りレプリカにレプリケートされます。 読み取りレプリカへの接続には、プライマリ サーバー上で使用可能なユーザー アカウントのみを使用できます。

レプリカに接続するには、次の 2 つの方法があります。

  • レプリカ インスタンスへ直接: 通常の Azure Database for PostgreSQL フレキシブル サーバー インスタンスの場合と同じように、レプリカのホスト名と有効なユーザー アカウントを使用して、レプリカに接続できます。 管理者ユーザー名が myadmin の myreplica というサーバーの場合、psql を使用して、レプリカに接続できます。
psql -h myreplica.postgres.database.azure.com -U myadmin postgres

メッセージが表示されたら、ユーザー アカウントのパスワードを入力します。

さらに、接続プロセスを容易にするために、Azure portal にすぐに使用できる接続文字列が用意されています。 これらは、[接続] ページにあります。 これらは、libpq 変数と、bash コンソール用に調整された接続文字列の両方を含みます。

  • 仮想エンドポイント経由 : 仮想エンドポイントに関する記事で詳しく説明しているように、仮想エンドポイントを使用する別の接続方法があります。 仮想エンドポイントを使用すると、現在レプリカ ロールを保持しているサーバーに関係なく、読み取り専用エンドポイントが常にレプリカを指し示すように構成できます。

レプリケーションを監視します

Azure Database for PostgreSQL フレキシブル サーバーの読み取りレプリカ機能は、レプリケーション スロット メカニズムに依存しています。 レプリケーション スロットの主な利点は、すべてのレプリカ サーバーで必要なトランザクション ログ (WAL セグメント) の数が自動的に調整されることです。 これにより、プライマリ上の WAL セグメントがレプリカに送信される前に削除されることが回避されるため、レプリカが同期されなくなるのを防ぐことができます。 このアプローチの欠点は、レプリケーション スロットが長期間非アクティブなままになっている場合に、プライマリの領域が不足するリスクがあることです。 そのような状況では、プライマリに WAL ファイルが蓄積され、ストレージ使用量が次第に増加します。 ストレージの使用率が 95% に達した場合、または使用可能な容量が 5 GiB 未満の場合は、ディスクがいっぱいという状況に関連するエラーを回避するために、サーバーが読み取り専用モードに自動で切り替わります。
そのため、レプリケーションのラグとレプリケーション スロットの状態の監視は、読み取りレプリカにとって非常に重要です。

ストレージ使用量またはストレージの割合、およびレプリケーションのラグが特定のしきい値を超えた場合のアラート ルールを設定することをお勧めします。これにより、事前の対処、ストレージ サイズの増加、遅れている読み取りレプリカの削除が行えます。 たとえば、ストレージの使用率が 80% を超えた場合や、レプリカのラグが 5 分を超えた場合のアラートを設定できます。 [使用されているトランザクション ログ ストレージ] メトリックは、WAL ファイルの蓄積が過度のストレージ使用の主な理由であるかどうかを示します。

Azure Database for PostgreSQL フレキシブル サーバーには、レプリケーションを監視するための 2 つのメトリックがあります。 その 2 つのメトリックは [Max Physical Replication Lag] (物理レプリケーションの最大ラグ) と [Read Replica Lag] (読み取りレプリカのラグ) です。 これらのメソッドを表示する方法については、読み取りレプリカのハウツー記事の「レプリカの監視」セクションを参照してください。

[Max Physical Replication Lag] (物理レプリケーションの最大ラグ) メトリックには、プライマリと最も遅れているレプリカの間のラグがバイト単位で表示されます。 このメトリックは、プライマリ サーバーに対してのみ適用および使用できます。また、読み取りレプリカの少なくとも 1 つがプライマリに接続されている場合にのみ使用できます。 ラグ情報は、レプリカがプライマリに追いつく過程にあるとき、レプリカの作成中、レプリケーションが非アクティブになったときにも存在します。

[Read Replica Lag] (読み取りレプリカのラグ) メトリックには、最後に再生されたトランザクションからの経過時間が表示されます。 たとえば、プライマリ サーバーでトランザクションが発生しておらず、最後のトランザクションが 5 秒前に再生された場合、[読み取りレプリカのラグ] には 5 秒の遅延が表示されます。 このメトリックは、レプリカに対してのみ適用および使用できます。

レプリカのラグがワークロードに対して許容できない値に達したときに通知するようにアラートを設定します。

さらに分析情報を得るには、プライマリ サーバーに対して直接クエリを実行して、すべてのレプリカでのレプリケーション ラグを取得します。

Note

プライマリ サーバーまたは読み取りレプリカを再起動した場合、再起動して追いつくまでにかかった時間が、Replica Lag (レプリカ ラグ) メトリックに反映されます。

レプリケーションの状態

レプリケーションと昇格操作の進行状況と状態を監視するには、Azure portal の [レプリケーションの状態] 列を参照してください。 この列はレプリケーション ページにあり、読み取りレプリカの現在の状態に関する分析情報を提供するさまざまな状態と、プライマリへのリンクが表示されます。 Azure Resource Manager API に依存しているユーザーの場合、GetReplica API を呼び出すと、状態は replica プロパティ バッグに ReplicationState として表示されます。

以下に使用可能な値を示します。

レプリケーションの状態 説明 昇格の順序 読み取りレプリカの作成順序
再構成 レプリカ プライマリ リンクの開始を待機しています。 障害などが原因でレプリカまたはそのリージョンが使用できない場合は、長く続く可能性があります。 1 該当なし
プロビジョニング 読み取りレプリカはプロビジョニング中であり、2 つのサーバー間のレプリケーションがまだ開始されていません。 プロビジョニングが完了するまで、読み取りレプリカには接続できません。 該当なし 1
更新中 昇格や読み取りレプリカの作成などのトリガーされたアクションに続いて、サーバー構成を準備中です。 2 2
キャッチアップ WAL ファイルがレプリカに適用されています。 昇格中のこのフェーズの期間は、選択したデータ同期オプション (計画済みまたは強制) によって異なります。 3 3
アクティブ 正常な状態です。読み取りレプリカがプライマリに正常に接続されたことを示します。 サーバーが停止しているが、以前に正常に接続されていた場合、状態はアクティブなままです。 4 4
接続エラー状態 異常な状態。昇格操作が失敗したか、レプリカが何らかの理由でプライマリに接続できないことを示します。 これを解決するには、レプリカを削除して、レプリカを再作成してください。 該当なし 該当なし

レプリケーションを監視する方法を確認してください。

考慮事項

このセクションでは、読み取りレプリカ機能に関する考慮事項をまとめています。 次の考慮事項が適用されます。

  • 電源操作: 開始と停止のアクションを含む電源操作は、プライマリとレプリカのサーバー両方に適用できます。 ただし、システムの整合性を維持するには、特定のシーケンスに従う必要があります。 読み取りレプリカを停止する前に、まずプライマリ サーバーが停止されていることを確認してください。 操作を開始するときは、プライマリ サーバーを起動する前に、レプリカ サーバーで開始アクションを開始します。
  • サーバーに読み取りレプリカがある場合は、プライマリ サーバーを削除する前に、最初に読み取りレプリカを削除する必要があります。
  • Azure Database for PostgreSQL フレキシブル サーバーのインプレース メジャー バージョン アップグレードでは、サーバーで現在有効になっている読み取りレプリカをすべて削除する必要があります。 レプリカが削除されると、プライマリ サーバーを目的のメジャー バージョンにアップグレードできます。 アップグレードが完了したら、レプリカを再作成してレプリケーション プロセスを再開できます。
  • Premium SSD v2: 現在のリリース時点では、プライマリ サーバーがストレージに Premium SSD v2 を使用している場合、読み取りレプリカの作成はサポートされていません。
  • 管理者パスワードのリセット: レプリカ サーバーでの管理者パスワードのリセットは、現在サポートされていません。 さらに、同じ要求での管理者パスワードの更新とレプリカの昇格操作もサポートされていません。 これを行うには、最初にレプリカ サーバーを昇格させてから、新しく昇格されたサーバーでパスワードを個別に更新する必要があります。

新しいレプリカ

読み取りレプリカは、新しい Azure Database for PostgreSQL フレキシブル サーバー インスタンスとして作成されます。 既存のサーバーをレプリカにすることはできません。 別の読み取りレプリカのレプリカを作成すること、つまり、レプリケーションのカスケードはサポートされていません。

リソースの移動

ユーザーは、プライマリとは異なるリソース グループに読み取りレプリカを作成できます。 ただし、作成後に読み取りレプリカを別のリソース グループに移動することはサポートされていません。 さらに、レプリカを別のサブスクリプションに移動すること、および読み取りレプリカを持つプライマリを別のリソース グループまたはサブスクリプションに移動することはサポートされていません。

ストレージの自動拡張

Azure Database for PostgreSQL フレキシブル サーバー インスタンスの読み取りレプリカを構成するときは、レプリカのストレージ自動拡張設定がプライマリ サーバーの設定と一致するようにすることが不可欠です。 ストレージの自動拡張機能を使用すると、データベースの停止につながる可能性がある領域不足を防ぐために、データベース ストレージを自動的に増やすことができます。 ストレージの自動拡張設定を効果的に管理する方法を次に示します。

  • プライマリ サーバーの設定に関係なく、任意のレプリカでストレージの自動拡張を有効にすることができます。
  • プライマリ サーバーでストレージ自動拡張が有効になっている場合は、ストレージのスケーリング動作の一貫性を確保するために、レプリカでも有効にする必要があります。
  • プライマリでストレージの自動拡張を有効にするには、まずレプリカで有効にする必要があります。 この操作の順序は、レプリケーションの整合性を維持するために重要です。
  • 逆に、ストレージの自動拡張を無効にする場合は、レプリケーションの複雑さを回避するために、レプリカで無効にする前にまずはプライマリ サーバーでストレージの自動拡張を無効にします。

バックアップと復元

Azure Database for PostgreSQL フレキシブル サーバー インスタンスのバックアップと復元を管理する場合、さまざまな昇格シナリオにおけるサーバーの現在および以前の役割に留意することが重要です。 注意すべき重要な点は次のとおりです。

プライマリ サーバーへの昇格

  1. 読み取りレプリカからバックアップは取得されません: バックアップは、過去のロールに関係なく、読み取りレプリカ サーバーから取得されることはありません。

  2. 過去のバックアップの保持: サーバーが以前にプライマリであり、その期間中にバックアップが作成されている場合、それらのバックアップは保持されます。 ユーザー定義の保持期間まで保持されます。

  3. 復元操作の制限: 読み取りレプリカに移行したサーバーに過去のバックアップが存在する場合でも、復元操作は制限されます。 復元操作を開始できるのは、サーバーが昇格してプライマリ ロールに戻った後のみです。

わかりやすくするために、以上の点を次の表に示します。

サーバー ロール 作成されるバックアップ 復元が許可される
プライマリ はい はい
読み取りレプリカ いいえ いいえ
プライマリに昇格された読み取りレプリカ はい はい

独立したサーバーに昇格し、レプリケーションから削除する

サーバーが読み取りレプリカである間、バックアップは作成されません。 ただし、独立したサーバーに昇格すると、昇格されたサーバーとプライマリ サーバーの両方でバックアップが作成され、両方で復元が許可されます。

ネットワーク

読み取りレプリカでは、Azure Database for PostgreSQL フレキシブル サーバーでサポートされるすべてのネットワーク オプションがサポートされます。

重要

プライマリ サーバーと読み取りレプリカ間の双方向通信は、Azure Database for PostgreSQL フレキシブル サーバーのセットアップに不可欠です。 Azure 仮想ネットワーク サブネット内の宛先ポート 5432 でトラフィックを送受信するためのプロビジョニングが必要です。

上記の要件によって、同期プロセスが容易になるだけでなく、特にプライマリへの昇格操作中、レプリカが逆の順序 (レプリカからプライマリ) で通信することが必要な場合がある昇格メカニズムの適切な動作が保証されます。 さらに、データの持続性を維持し、効率的な復旧プロセスを可能にするために、先書きログ (WAL) アーカイブを格納する Azure ストレージ アカウントへの接続を許可する必要があります。

読み取りレプリカのプライベート アクセス (仮想ネットワーク統合) を構成し、プライベート ネットワークのコンテキスト内での Azure リージョンと仮想ネットワーク全体へのレプリケーションの影響を理解する方法の詳細については、「プライベート ネットワークを使用した Azure リージョンと仮想ネットワーク間のレプリケーション」ページを参照してください。

レプリケーション スロットの問題の軽減策

まれに、レプリケーション スロットが原因の遅延が大きくなると、WAL ファイルが蓄積するために、プライマリ サーバーのストレージ使用量が増加する場合があります。 ストレージ使用量が 95% に達するか、使用可能な容量が 5 GiB を下回った場合、サーバーは自動的に読み取り専用モードに切り替えて、ディスクがいっぱいになるエラーを防ぎます。

プライマリ サーバーの正常性と機能の維持が優先されるため、このような極端なケースの場合は、プライマリ サーバーが読み取りおよび書き込みトラフィックに対して動作し続けられるように、レプリケーション スロットが削除される可能性があります。 そのため、レプリケーションはファイルベースのログ配布モードに切り替わり、レプリケーションの遅延がさらに大きくなる可能性があります。

ストレージの使用状況とレプリケーションの遅延を注意深く監視し、潜在的な問題がエスカレートする前に、軽減のために必要なアクションを実行することが重要です。

サーバー パラメーター

読み取りレプリカが作成されると、プライマリ サーバーからサーバー パラメーターが継承されます。 これは、一貫性があり信頼性の高い出発点を確保するためです。 ただし、読み取りレプリカの作成後にプライマリ サーバー上のサーバー パラメーターに対して行われた変更は、、自動的にはレプリケートされません。 この動作により、プライマリ サーバーのパラメーターを変更せずに、例えば読み取りを集中的に行う操作のパフォーマンスを向上させるなど、読み取りレプリカを個別にチューニングできるという利点があります。 これにより柔軟性とカスタマイズのオプションが提供されますが、サーバー パラメーターの均一性が重要となる場合には、プライマリとレプリカの間の整合性を維持するために、慎重にかつ手動で管理する必要もあります。

管理者は、読み取りレプリカ サーバーのサーバー パラメーターを変更し、プライマリ サーバーとは異なる値を設定できます。 唯一の例外は、レプリカの復旧に影響を与える可能性があるパラメーターです。以下の「スケーリング」セクションにも記載されています。max_connections、max_prepared_transactions、max_locks_per_transaction、max_wal_senders、max_worker_processes。 読み取りレプリカがシームレスに回復し、共有メモリの制限が発生しないようにするには、これらの特定のパラメーターは常に、プライマリ サーバーで構成されているものと同等または大きい値に設定する必要があります。

スケール

コンピューティング (仮想コア) のスケールアップとスケールダウン、サービス レベルの General Purpose からメモリ最適化 (またはその逆) への変更、ストレージのスケールアップは自由に行えますが、次の注意事項が適用されます。

コンピューティングスケーリングの場合:

  • 回復中にレプリカで共有メモリが不足しないようにするために、Azure Database for PostgreSQL フレキシブル サーバーのレプリカに関するいくつかのパラメーターは、プライマリの設定以上にする必要があります。 影響を受けるパラメーターは、max_connections、max_prepared_transactions、max_locks_per_transaction、max_wal_senders、max_worker_processes です。

  • スケールアップ: まず、レプリカのコンピューティングをスケールアップしてから、プライマリをスケールアップします。

  • スケールダウン: まず、プライマリのコンピューティングをスケールダウンしてから、レプリカをスケールダウンします。

  • プライマリのコンピューティングは、常に最小レプリカのコンピューティングと同じか小さい必要があります。

ストレージのスケーリングの場合:

  • スケールアップ: まず、レプリカのストレージをスケールアップしてから、プライマリをスケールアップします。

  • プライマリのストレージ サイズは、常に最小レプリカのストレージ サイズと同じか小さい必要があります。

関連するコンテンツ