Azure Database for PostgreSQL (単一サーバー) の読み取りレプリカ

適用対象: Azure Database for PostgreSQL - 単一サーバー

重要

Azure Database for PostgreSQL - シングル サーバーは廃止パスにあります。 Azure Database for PostgreSQL - フレキシブル サーバーにアップグレードすることを強くお勧めします。 Azure Database for PostgreSQL - フレキシブル サーバーへの移行の詳細については、Azure Database for PostgreSQL 単一サーバーの現状に関するページを参照してください。

読み取りレプリカ機能を使用すると、Azure Database for PostgreSQL サーバーから、読み取り専用サーバーにデータをレプリケートできます。 レプリカは、PostgreSQL エンジンのネイティブの物理レプリケーション テクノロジを使用して非同期的に更新されます。 プライマリ サーバーから最大 5 つのレプリカにレプリケートできます。

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

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

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

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

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

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

考慮事項

この機能は、ラグが許容され、クエリのオフロードに適したシナリオを対象としています。 レプリカ データが最新の状態であることが求められる同期レプリケーションのシナリオには適していません。 プライマリとレプリカの間には測定可能な遅延が発生します。 ワークロード、およびプライマリとレプリカの間の待機時間によっては、数分または数時間に及ぶこともあります。 レプリカ上のデータは、最終的にプライマリ上のデータと整合します。 この機能は、この遅延に対応できるワークロードに使用してください。

Note

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

Note

自動バックアップは、最大 4 TB のストレージ構成されたレプリカ サーバーに対して実行されます。

リージョン間レプリケーション

プライマリ サーバーとは別のリージョンに読み取りレプリカを作成できます。 リージョン間レプリケーションは、ディザスター リカバリー計画や、データをユーザーの所在地の近くに配置するなどのシナリオに役立ちます。

Note

Basic レベルのサーバーは、同じリージョンのレプリケーションのみをサポートしています。

任意の Azure Database for PostgreSQL リージョンにプライマリ サーバーを作成できます。 プライマリ サーバーは、ペアになっているリージョンまたはユニバーサル レプリカ リージョンにレプリカを持つことができます。 次の図は、プライマリ リージョンに応じて使用できるレプリカ リージョンを示しています。

ユニバーサル レプリカ リージョン

プライマリ サーバーが配置されている場所に関係なく、次のいずれかのリージョンに読み取りレプリカをいつでも作成できます。 ユニバーサル レプリカ リージョンは次のとおりです。

オーストラリア東部、オーストラリア南東部、ブラジル南部、カナダ中部、カナダ東部、米国中部、東アジア、米国東部、米国東部 2、東日本、西日本、韓国中部、韓国南部、米国中北部、北ヨーロッパ、米国中南部、東南アジア、英国南部、英国西部、西ヨーロッパ、米国西部、米国西部 2、米国中西部。

ペアになっているリージョン

ユニバーサル レプリカ リージョンに加えて、プライマリ サーバーの Azure のペアになっているリージョンに読み取りレプリカを作成できます。 リージョンのペアがわからない場合は、Azure のペアになっているリージョンに関する記事を参照してください。

ディザスター リカバリー計画にリージョン間レプリカを使用している場合、レプリカの作成場所は別のリージョンのいずれか 1 つではなく、ペアになっているリージョンにすることをお勧めします。 ペアになっているリージョンでは、同時更新を避け、物理的な分離とデータの保存に優先順位を付けます。

考慮すべきいくつかの制限があります。

• 一方向のペア:一部の Azure リージョンは一方向にのみペアになっています。 これらのリージョンには、インド西部とブラジル南部が含まれます。 これは、インド西部のプライマリ サーバーでインド南部のレプリカを作成できることを意味します。 ただし、インド南部のプライマリ サーバーでインド西部のレプリカを作成することはできません。 この理由は、インド西部のセカンダリ リージョンはインド南部ですが、インド南部のセカンダリ リージョンはインド西部ではないためです。

レプリカの作成

レプリカ作成ワークフローを開始すると、空の Azure Database for PostgreSQL サーバーが作成されます。 新しいサーバーには、プライマリ サーバー上にあったデータが設定されます。 作成時間は、プライマリ上のデータ量と、最後の週次完全バックアップからの経過時間に依存します。 時間の範囲は、数分から数時間になる可能性があります。

すべてのレプリカでストレージの自動拡張が有効になっています。 自動拡張機能により、レプリカはレプリケートされるデータに追従していくことができ、ストレージ不足エラーによって発生するレプリケーションの中断が防止されます。

読み取りレプリカ機能では、PostgreSQL の (論理レプリケーションではなく) 物理レプリケーションが使用されます。 レプリケーション スロットを使用したストリーミング レプリケーションが、既定の動作モードです。 必要に応じて、遅れを取り戻すためにログ配布が使用されます。

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

ソース PostgreSQL サーバーがカスタマー マネージド キーで暗号化されている場合、追加の考慮事項についてはこちらのドキュメントを参照してください。

レプリカへの接続

作成されたレプリカでは、プライマリ サーバーのファイアウォール規則または VNet サービス エンドポイントは継承されません。 これらの規則は、レプリカに対して個別に設定する必要があります。

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

通常の Azure Database for PostgreSQL サーバーの場合と同じように、レプリカのホスト名と有効なユーザー アカウントを使用して、レプリカに接続できます。 管理ユーザー名が myadmin で my replica という名前のサーバーの場合は、次の psql を使用してレプリカに接続できます。

psql -h myreplica.postgres.database.azure.com -U myadmin@myreplica -d postgres

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

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

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

[Max lag across replicas](レプリカ間の最大ラグ) メトリックは、プライマリと最も遅れているレプリカの間のラグをバイト単位で示します。 このメトリックは、プライマリ サーバーでのみ適用および使用でき、読み取りレプリカの少なくとも 1 つがプライマリに接続されており、プライマリがストリーミング レプリケーション モードである場合にのみ使用できます。 ファイル配布レプリケーション モードが有効なプライマリのアーカイブ ログを使用してレプリカがプライマリに追いつく過程にある場合、ラグ情報には詳細が表示されません。

[Replica Lag](レプリカのラグ) メトリックでは最後に再生されたトランザクションからの時間が表示されます。 プライマリ サーバーでトランザクションが発生していない場合、メトリックにはこのタイム ラグが反映されます。 このメトリックは、レプリカ サーバーのみに適用および使用可能です。 レプリカのラグは、pg_stat_wal_receiver ビューから計算されます。

SELECT EXTRACT (EPOCH FROM now() - pg_last_xact_replay_timestamp());

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

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

Note

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

レプリケーションの停止/レプリカの昇格

プライマリとレプリカの間のレプリケーションはいつでも停止できます。 この停止アクションにより、レプリカが再起動され、独立したスタンドアロンの読み取りと書き込みが可能なサーバーとして昇格します。 スタンドアロン サーバー内のデータは、レプリケーションが停止された時点でレプリカ サーバーで使用可能だったデータです。 プライマリにおける後続の更新は、レプリカに反映されません。 ただし、レプリカ サーバーには、まだ適用されていない蓄積されたログが含まれている場合があります。 再起動プロセスの一環として、レプリカでクライアント接続を受け入れる前に保留中のすべてのログが適用されます。

Note

レプリカ サーバーでの管理者パスワードのリセットは、現在サポートされていません。 さらに、同じ要求での管理者パスワードの更新とレプリカの昇格操作もサポートされていません。 これを行うには、最初にレプリカ サーバーを昇格させてから、新しく昇格されたサーバーのパスワードを個別に更新する必要があります。

考慮事項

• 読み取りレプリカのレプリケーションを停止する前に、レプリケーションのラグを確認して、必要なすべてのデータがレプリカにあることを確認してください。
• 読み取りレプリカは、スタンドアロン サーバーにする前にすべての保留中のログを適用する必要があるので、書き込みの多いワークロードでは、レプリカに大きな遅延が発生する可能性があり、レプリケーションが停止した際に RTO が高くなる可能性があります。 レプリカの昇格を計画するときは、この点に注意してください。
• 昇格されたレプリカ サーバーをもう一度レプリカにすることはできません。
• レプリカをプライマリ サーバーに昇格した場合、古いプライマリ サーバーへのレプリケーションを確立することはできません。 以前のプライマリ リージョンに戻る場合は、新しい名前で新しいレプリカ サーバーを作成するか、古いプライマリを削除して、古いプライマリ名を使用してレプリカを作成します。
• 複数の読み取りレプリカがある場合、そのうちの 1 つをプライマリ サーバーに昇格すると、他のレプリカ サーバーは引き続き古いプライマリに接続されます。 昇格された新しいサーバーからレプリカを再作成することが必要になる場合があります。

レプリケーションを停止すると、レプリカでは以前のプライマリと他のレプリカへのリンクがすべて失われます。

レプリカへのレプリケーションを停止する方法を確認します。

レプリカへのフェールオーバー

プライマリ サーバーで障害が発生した場合、読み取りレプリカに自動的にフェールオーバーされることはありません。

レプリケーションは非同期であるため、プライマリとレプリカの間にかなりのラグが生じる可能性があります。 ラグの程度は、プライマリ サーバーで実行されているワークロードの種類や、プライマリ サーバーとレプリカ サーバー間の待機時間など、さまざまな要因の影響を受けます。 標準的な書き込みワークロードの場合、レプリカのラグは数秒から数分の間であると予想されます。 ただし、プライマリで非常に負荷の高い書き込みワークロードが実行されており、レプリカが十分な速度で追いついていない場合は、ラグが非常に大きくなる可能性があります。 各レプリカのレプリケーションのラグを追跡するには、"レプリカ ラグ" メトリックを使用します。 このメトリックを使用すると、レプリカで最後に再生されたトランザクションからの時間が表示されます。 長期間にわたってレプリカのラグを観察し、平均ラグを特定することをお勧めします。 予想される範囲を外れた場合に通知を受け取って対処できるよう、レプリカのラグにアラートを設定できます。

ヒント

レプリカにフェールオーバーする場合、プライマリからレプリカのリンクを解除したときのラグによって、どれだけのデータが失われたかを示します。

レプリカにフェールオーバーすることを決定したら、次の操作を行います。

1. レプリカへのレプリケーションを停止する
   このステップは、レプリカ サーバーをスタンドアロン サーバーにして書き込みを受け入れることができるようにするために必要です。 このプロセスの一環として、レプリカ サーバーが再起動され、プライマリからリンクが解除されます。 レプリケーションの停止を開始すると、通常、まだ適用されていない残留ログを適用し、データベースを読み書き可能なサーバーとして開くためのバックエンド プロセスに数分かかります。 このアクションの影響を理解するには、この記事の「レプリケーションの停止」セクションを参照してください。

2. ご利用のアプリケーションが (以前の) レプリカを指すように設定する
   各サーバーには一意の接続文字列があります。 プライマリではなく、(以前の) レプリカを指定するように、アプリケーションの接続文字列を更新します。

ご利用のアプリケーションで読み取りと書き込みが正常に処理されると、フェールオーバーが完了します。 アプリケーションで経験するダウンタイムは、問題を検出し、上記の手順 1 と 2 を完了したタイミングによって異なります。

障害復旧

可用性ゾーン レベルまたは局地的な障害などの重大な障害イベントが発生した場合は、読み取りレプリカを昇格させることでディザスター リカバリー操作を実行できます。 UI ポータルから、読み取りレプリカ サーバーに移動できます。 次に、[レプリケーション] タブを選択し、レプリカを停止して、独立したサーバーに昇格させることができます。 または、Azure CLI を使用して、レプリカ サーバーの停止と昇格を行うこともできます。

考慮事項

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

前提条件

読み取りレプリカと論理デコードはどちらも、情報を Postgres 書き込み先行ログ (WAL) に依存しています。 これらの 2 つの機能には、Postgres とは異なるレベルのログが必要です。 論理デコードには、読み取りレプリカよりも高いレベルのログが必要です。

適切なレベルのログを構成するには、Azure レプリケーション サポート パラメーターを使用します。 Azure レプリケーション サポートには、次の 3 つの設定オプションがあります。

• オフ - 最小限の情報を WAL に格納します。 この設定は、ほとんどの Azure Database for PostgreSQL サーバーでは使用できません。
• レプリカ - [オフ] よりも冗長です。 これは、読み取りレプリカを機能させるために必要な最小レベルのログです。 ほとんどのサーバーでは、この設定が既定値です。
• 論理 - [レプリカ] よりも冗長です。 これは、論理デコードを機能させるための最小レベルのログです。 読み取りレプリカはこの設定でも機能します。

新しいレプリカ

読み取りレプリカは、新しい Azure Database for PostgreSQL サーバーとして作成されます。 既存のサーバーをレプリカにすることはできません。 別の読み取りレプリカのレプリカを作成することはできません。

レプリカ構成

レプリカは、プライマリと同じコンピューティングとストレージの設定を使用して作成されます。 レプリカの作成後、ストレージやバックアップの保持期間など、いくつかの設定を変更できます。

ファイアウォール規則、仮想ネットワーク規則、パラメーター設定は、レプリカの作成後、プライマリ サーバーからレプリカに継承されることはありません。

Scaling

仮想コアのスケーリングまたは汎用とメモリ最適化の間のスケーリング。

• PostgreSQL では、セカンダリ サーバー上の max_connections の設定が、プライマリ サーバー上の設定以上であることが要求されます。それ以外の場合、セカンダリ サーバーは起動しません。
• Azure Database for PostgreSQL では、接続にメモリが使用されるため、各サーバーで許可される最大接続数はコンピューティング sku に固定されます。 max_connections とコンピューティング sku のマッピングの詳細について確認してください。
• スケールアップ: まず、レプリカのコンピューティングをスケールアップしてから、プライマリをスケールアップします。 この順序により、エラーが発生して max_connections 要件に違反するのを防ぎます。
• スケールダウン: まず、プライマリのコンピューティングをスケールダウンしてから、レプリカをスケールダウンします。 プライマリよりも低いレプリカをスケーリングしようとすると、エラーが発生します。これは max_connections 要件に違反するためです。

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

• すべてのレプリカで、ストレージ全体のレプリカからのレプリケーションの問題を防ぐために、ストレージの自動拡張が有効になっています。 この設定を無効にすることはできません。
• 他のサーバーの場合と同様に、ストレージを手動でスケールアップすることもできます。

Basic レベル

Basic レベルのサーバーは、同じリージョンのレプリケーションのみをサポートしています。

max_prepared_transactions

読み取りレプリカの max_prepared_transactions パラメーターの値をプライマリの値以上にすることが PostgreSQL では必要です。そうしないと、レプリカが起動しません。 プライマリで max_prepared_transactions を変更する場合、まずレプリカで変更します。

停止されたレプリカ

プライマリ サーバーと読み取りレプリカの間のレプリケーションを停止した場合、変更を適用するためにレプリカが再起動されます。 停止したレプリカは、読み取りと書き込みの両方を受け入れるスタンドアロン サーバーになります。 スタンドアロン サーバーをもう一度レプリカにすることはできません。

削除されたプライマリおよびスタンドアロンのサーバー

プライマリ サーバーを削除すると、そのすべての読み取りレプリカがスタンドアロン サーバーになります。 この変更を反映するため、レプリカは再起動されます。

次のステップ

• Azure portal で読み取りレプリカを作成および管理する方法を確認する。
• Azure CLI と REST API で読み取りレプリカの作成と管理を行う方法について確認してください。