読み取り専用レプリカ

高可用性の読み取り専用レプリカ

高可用性のDatabases for PostgreSQL 読み取り専用レプリカは、読み取りスケーラビリティの向上、可用性の向上、読み取り待ち時間の短縮、バックアップとディザスタリカバリ機能、読み取りトラフィックの効率的な分散機能などの利点を提供します。 これは、アプリケーションのための、より堅牢で応答性の高いデータベース・インフラストラクチャに貢献します。 詳細については、高可用性読み取り専用レプリカ を参照してください。

リーダー

デプロイメント Databases for PostgreSQL の 「読み取り専用レプリカ 」タブでは、読み取り専用レプリカがプロビジョニングされる前に、中央ペインに「読み取り専用レプリカが存在しません」と表示され、 「作成 」ボタンが提供されます。

デプロイメントがリーダーであり、既に読み取り専用レプリカが接続されている場合、_「複製」_ペインには、レプリカ・デプロイメントのリストと、各デプロイメントへのリンクが表示されます。 読み取り専用レプリカのデプロイメント名の右側にある歯車アイコンをクリックして管理します。

読み取り専用レプリカのプロビジョニング

PostgreSQL デプロイメントのリソースはデプロイメントごとに割り振られ、通常のデプロイメントには 2 つのメンバーがあります。 読み取り専用レプリカはメンバーが1つしか存在せず、プロビジョニングでは現在メモリとストレージの要求値の半分を使用するため、プロビジョニングが失敗する可能性があります。 Web UIではストレージの値を変更できず、自動的にリーダーデプロイメントの値（半減された値）が使用されます。 データが収まらない場合は、APIまたはCLIを使用して、プロビジョニングしたいストレージ容量の2倍を指定する必要があります。 （メモリについても同様ですが、メモリ容量が少なくても復元が成功しないとは限りません。） この状態を修正するための更新が進行中です。

ibmcloud resource service-instance-create <REPLICA_NAME_OR_CRN> databases-for-postgresql standard <REGION> \
-p \ '{
  "remote_leader_id": "crn:v1:bluemix:public:databases-for-postgresql:us-south:a/54e8ffe85dcedf470db5b5ee6ac4a8d8:1b8f53db-fc2d-4e24-8470-f82b15c71819::",
  "members_memory_allocation_mb": "2048",
  "members_disk_allocation_mb": "10240"
}'

curl -X POST \
  https://resource-controller.cloud.ibm.com/v2/resource_instances \
  -H 'Authorization: Bearer <>' \
  -H 'Content-Type: application/json' \
    -d '{
    "name": "<REPLICA_NAME_OR_CRN>",
    "target": "<REGION>",
    "resource_group": "<RESOURCE_GROUP_ID>",
    "resource_plan_id": "databases-for-postgresql-standard",
    "parameters": {
      "remote_leader_id": "crn:v1:bluemix:public:databases-for-postgresql:us-south:a/54e8ffe85dcedf470db5b5ee6ac4a8d8:1b8f53db-fc2d-4e24-8470-f82b15c71819::",
      "members_memory_allocation_mb": "2048",
      "members_disk_allocation_mb": "10240"
    }
  }'

読み取り専用レプリカ

_読み取り_専用レプリカのリディレプリカタブでは、 _レプリケーションには_その名前とリージョン、およびそのリーダーの名前とリージョンが含まれます。 また、読み取り専用レプリカを再同期するボタンや、プロモートするボタンもあります。

SELECT * from pg_stat_replication;

読み取り専用レプリカの再同期

読み取り専用レプリカを再同期する必要がある場合は、**「読み取り専用レプリカの再同期 (Resync Read-Only Replica)」**ボタンをクリックします。 再同期は中断を伴う操作です。再同期を実行すると、読み取り専用レプリカのデータは解体されて最初から再構築されます。 再同期の実行中は、読み取り専用レプリカで他の操作を実行することも、照会を実行することもできません。 照会の宛先がリーダーに変更されることはないので、読み取り専用レプリカへの接続は、再同期が完了するまで失敗します。

読み取り専用レプリカの再同期にかかる時間はそれぞれに異なりますが、長い時間がかかるプロセスになる可能性があります。

ibmcloud cdb read-replica-resync <DEPLOYMENT_NAME_OR_CRN>

curl -X POST \
  https://api.{region}.databases.cloud.ibm.com/v4/ibm/deployments/{id}/remotes/resync \
  -H 'Authorization: Bearer <>'

読み取り専用レプリカのプロモート

読み取り専用レプリカを、読み取り操作だけでなく書き込み操作も受け入れる独立したクラスターにプロモートすることができます。 リーダーのデプロイメントに問題が発生した場合に、読み取り専用レプリカをスタンドアロン・クラスターにプロモートして、アプリケーションからの書き込みの受け入れを開始することができます。 read-replicaクラスタにすでに複数のデータメンバが存在する場合、read-replicaクラスタをスタンドアロンクラスタに昇格させる方が速くなります。

プロモーションが行われると、読み取り専用レプリカはリーダーへの接続を終了し、スタンドアロンの Databases for PostgreSQL のデプロイメントになります。 このデプロイメントは読み取り操作と書き込み操作の受け入れと実行を開始できます。バックアップが有効になり、独自の管理者ユーザーが発行されます。 新規データ・メンバーが 1 台追加されるので、デプロイメントはデータ・メンバー 2 台のクラスターになります。 これによってコストは増えますが (メンバーの使用量を基準とする同じ料金が課金されるため)、デプロイメントのメンバーは 1 台ではなく 2 台になります。

読み取り専用レプリカをプロモートするときに、通常はプロモート時に取得する初期バックアップをスキップすることができます。 初期バックアップをスキップすると、レプリカはより早く使用可能になりますが、即時バックアップは利用できません。 プロモーションのプロセスが完了したら、オンデマンド・バックアップを開始できます。

独立したデプロイメントにプロモートした読み取り専用レプリカは、読み取り専用レプリカに戻すことも、リーダーに再参加させることもできなくなります。

読み取り専用レプリカに関する考慮事項

• 読み取り専用レプリカは、ソース構成と同じリージョンに置くことも、別のリージョンに置いて、リージョンをまたいでデータを複製することもできます。

• 読み取り専用レプリカは、リーダーと同じメジャー・バージョンでなければなりません。

• 読み取り専用レプリカではバックアップは無効になっています。 バックアップは、リーダーのデプロイメントでのみ取得されます。

• レプリカは他のリージョンに復元可能ですが、EUクラウド対応リージョン（現在 eu-de および par-01）は互いにのみ復元可能です（例： par-01 のレプリカは に復元可能 eu-de、その逆も同様）。

• リーダーごとに読み取り専用レプリカは5つまでです。

• 読み取り専用レプリカはリーダー・クラスターのリーダー/フォロワーの選択に関与しないので、読み取り専用レプリカへのフェイルオーバーは自動化されません。 読み取り専用レプリカのフル・デプロイメントへのプロモーションは、ユーザーが開始して手動で行う作業です。

• 読み取り専用レプリカの最小サイズは、2 GB の RAM および 10 GB のディスクです。 リーダーのデプロイメントがこれより小さくても、この最小サイズは変わりません。

• 読み取り専用レプリカが、リーダーに合わせて自動的にスケーリングされることはありません。 保管するデータの量がデプロイメントに割り振られているディスクの量を超える場合は、読み取り専用レプリカのディスクをスケーリングしてから、リーダーのディスクをスケーリングしてください。 読み取り専用レプリカを最初にスケーリングすることで、読み取り専用レプリカのスペースが枯渇しないようにします。 スペースではなくパフォーマンスのためにリーダーのディスクをスケーリングした場合は、読み取り専用レプリカのスケーリングは必須ではありません。

• レプリケーションは非同期で行われるので、レプリケーションに遅れが生じることがあります。 デフォルトでは、プライマリとレプリカ間の一貫した通信は行われません。 再同期が必要になるほど、読み取り専用のレプリカが遅れる可能性があります。 リーダーから地理的に遠く離れたリージョンにレプリカを置くと、レプリケーションの遅れが大きくなります。

• 読み取り専用レプリカは、単一のデータメンバーを持つデプロイメントであり、内部的な高可用性を一切備えていません。 メンテナンス時には一時的な中断やダウンタイムが発生しがちです。 読み取り専用レプリカに依存するアプリケーションがある場合は、失敗した照会を再試行するロジックや、複数の読み取り専用レプリカに負荷を分散させるロジックを実装してください。