Azure Cosmos DB for PostgreSQL の読み取りレプリカ

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

レプリカとは、通常のクラスターと同様に管理する新しいクラスターです。 読み取りレプリカごとに、プロビジョニング済みのコンピューティング (仮想コア単位) とストレージ (GiB/月) に対して課金されます。 レプリカ クラスターのコンピューティングとストレージのコストは、通常のクラスターの場合と同じです。

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

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

読み取りレプリカ機能は、読み取り集中型ワークロードのパフォーマンスとスケールの向上に役立ちます。 書き込みワークロードをプライマリに振り向けながら、読み取りワークロードはレプリカに分離することができます。

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

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

考慮事項

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

レプリカの作成

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

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

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

レプリカへの接続

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

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

通常のクラスターの場合と同じように、ホスト名と有効なユーザー アカウントを使用してレプリカのコーディネーター ノードに接続できます。 たとえば、管理ユーザー名が citus で my replica という名前のサーバーの場合は、次の psql を使用してレプリカのコーディネーター ノードに接続できます。

psql -h c-myreplica.12345678901234.postgres.cosmos.azure.com -U citus@myreplica -d postgres

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

独立したクラスターへのレプリカの昇格

読み取り可能で書き込み可能な独立したクラスターにレプリカを昇格させることができます。 昇格したレプリカは元のレプリカから更新を受信しなくなり、昇格を元に戻すことはできません。 昇格したレプリカには、独自のレプリカを含めることができます。

レプリカを昇格させる一般的なシナリオは 2 つあります。

1. ディザスター リカバリー プライマリまたはリージョン全体で問題が発生した場合は、緊急時の手順として書き込み用に別のクラスターを開くことができます。

2. 別のリージョンへの移行。 別のリージョンに移動する場合は、新しいリージョンにレプリカを作成し、データが移行されるのを待ってから、レプリカを昇格させます。 昇格時にデータが失われる可能性を回避するために、レプリカが作成された後に、元のクラスターへの書き込みを無効にすることができます。

   replication_lag メトリックを使用してレプリカがどの程度作成されたかを確認できます。 詳しくは、メトリックに関する記事をご覧ください。

考慮事項

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

新しいレプリカ

読み取りレプリカが新しいクラスターとして作成されます。 既存のサーバーをレプリカにすることはできません。 別の読み取りレプリカのレプリカを作成することはできません。

レプリカ構成

レプリカは、プライマリからコンピューティング、ストレージ、およびワーカー ノードの設定を継承します。 レプリカの一部の設定は変更できますが、すべてを変更することはできません。 たとえば、コンピューティング、パブリック アクセスのファイアウォール規則、プライベート アクセス用のプライベート エンドポイントを変更できます。 ストレージ サイズやワーカー ノードの数を変更することはできません。

必ず、プライマリから到着した変更を保持するのに十分な能力を持つレプリカを確保するようにしてください。 たとえば、コンピューティング能力をプライマリでアップスケールしている場合は、必ず、レプリカでもアップスケールしてください。

ファイアウォール規則およびパラメーター設定は、レプリカの作成時や作成後に、プライマリ サーバーからレプリカに継承されることはありません。

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

読み取りレプリカは、プライマリ クラスターのリージョン、または Azure Cosmos DB for PostgreSQL でサポートされているその他のリージョンに作成できます。 クラスターごとに 5 つのレプリカの制限は、すべてのリージョンでカウントされます。つまり、リージョンごとに 5 つではなく、合計 5 個です。

次のステップ

• Azure portal で読み取りレプリカを作成および管理する方法を確認する。