Databases for PostgreSQL の高可用性と災害復旧について

高可用性サービスまたは作業負荷が障害に耐え、事前に定義されたサービスレベルに従って処理能力を提供し続ける能力。サービスについては、可用性はサービスレベル契約で定義されています。可用性には、計画されたイベントと計画外のイベントの両方が含まれます。計画外のイベントには、メンテナンス、故障、災害などが含まれます。 (HA) とは、予期しない障害が発生した場合でもサービスが稼働し続け、アクセス可能になる能力です。ディザスタリカバリとはサービスの中断などの稀な重大なインシデントや広範囲にわたる障害から、サービスや作業負荷が回復する能力。これには、地域全体に影響を及ぼす物理的な災害、データベースの破損、作業負荷に寄与するサービスの損失などが含まれます。その影響は、高可用性設計の処理能力を超えている。、サービスインスタンスを稼動状態に回復させるプロセスである。

Databases for PostgreSQL は、標準プランで定義されたサービスレベル目標（SLO ）を満たす地域サービスである。詳しくは、サービス・レベル・アグリーメント（SLA ）を参照。 site.data.keyword.databases-for-postgresql で利用可能な IBM Cloud リージョンとデータセンターの詳細については、ロケーション別のサービスおよびインフラの可用性を参照してください。

高可用性アーキテクチャ

Databases for PostgreSQL は、レプリケーション、フェイルオーバー、および高可用性機能を提供し、インフラストラクチャのメンテナンス、アップグレード、および一部の障害からデータベースとデータを保護します。デプロイメントには、リーダーとレプリカの2つのデータメンバーを持つクラスタが含まれます。レプリカは非同期レプリケーションを使って最新の状態に保たれる。クラスタの状態を維持し、フェイルオーバーを処理するために、分散コンセンサスメカニズムが使用される。リーダが到達不能になった場合、クラスタはフェイルオーバーを開始し、レプリカはリーダに昇格し、新しいレプリカがレプリカとしてクラスタに再参加します。リーダーとレプリカは常にMZRの異なるゾーンにいる。レプリカが失敗すると、新しいレプリカが作成される。ゾーン障害によってメンバーが失敗した場合、新しいレプリカは生き残ったゾーンに作成される。

PostgreSQL メンバをクラスタに追加してリージョン内の冗長性を高めたり、読み取り専用のレプリカをプロビジョニングしてリージョンをまたいだフェイルオーバーや読み取りオフロードを行うことで、高可用性をさらに拡張できます。

PostgreSQL、レプリケーション技術に関するドキュメントを確認し、デフォルトで導入されている非同期レプリケーション戦略に関連する制約とトレードオフを理解する。

リーダー上でサーバーがクラッシュするなど、データベースが致命的に不健全になるシナリオでは、 Databases for PostgreSQL、フェイルオーバーを試みる。この自動フェイルオーバー機能は、リーダーからレプリカへのデータラグが16MBを上限とし（ PostgreSQL データオーバーヘッドの多くを占める数行のデータ）、ラグしきい値を超えた場合は実行されない。 16MBのデータ損失の可能性がアプリケーションにとって耐えられない場合は、以下の同期レプリケーションを参照してください。

プログラムでクラスタにアクセスするワークロードは、可用性を維持するためにクライアントの可用性再試行ロジックに従う必要があります。

このサービスは、通常の運用では、制御されたフェイルオーバーを行うこともある。これらのフェイルオーバーはデータ損失はないが、アクティブなコネクションのリセットをもたらす。最大 15 秒の、再接続が失敗する期間があります。時には、運用環境における予期せぬ出来事により、計画外のフェイルオーバーが発生することがある。最大45秒かかることもあるが、通常は30秒以内だ。例えば、サービスのメンテナンスは、制御されたフェイルオーバーを引き起こす。

高可用性機能

Databases for PostgreSQL は以下の高可用性機能をサポートしている：

高可用性機能
特長	説明	考慮事項
自動フェイルオーバー	すべてのクラスタに標準装備され、ゾーンや単一メンバーの障害に強い
メンバー数	最少催行人数：2名デフォルトは標準的な2人のメンバー配置。 2つのメンバーで構成されるクラスタは、単一のインスタンスまたはゾーンの障害から自動的に回復します（ラグしきい値までのデータ損失があります）。新しいレプリカのためのデータ同期中に、クラスタはデータ損失の原因となる2番目の障害にさらされます。 PostgreSQL、同じ故障期間中に2つの故障が発生しても、3人のメンバーであれば耐えられる	同期レプリケーションに必要な3人のメンバー
同期複製	データ書き込みパスにリモートメンバー同期を追加し、RPOを改善。以下の同期レプリケーションを参照。	パフォーマンスへの影響とコスト。
読み取り専用レプリカ	読み取り専用のレプリカは、リモート・リージョンでのローカル・アクセスを提供し、潜在的なネットワーク遅延や接続性の問題に対する可用性を向上させることができる。	すべてのWriteリクエストは、read-replicaに関連するread-writeクラスタにのみ向けられなければならない

同期レプリケーション Databases for PostgreSQL

デフォルトでは、ストリーミング複製は非同期です。リーダーがクラッシュした場合、コミットされたトランザクションの一部がレプリカに同期されず、データロスを引き起こす可能性がある。 Cloud Databases、データロスは実質的に最小限に抑えられる。しかし、同期レプリケーションは、トランザクションによるすべての変更がレプリカに同期されたことを確認する機能を提供する。これにより、クラスタ全体の一貫性が確保される。この一貫性は、 success で接続クライアントに戻る前に、書き込みがセカンダリに書き込まれたことを確認することによる。同期レプリケーションに関する変数については synchronous_commit を参照してください。

同期複製により、レプリカの可用性が 1 次書き込みパスに取り込まれます。書き込みを承認するレプリカがない場合、レプリカが利用可能になるまでハングする。同期複製は 2 メンバー・デプロイメントではサポートされないため、これには少なくとも 3 つのメンバーが確実に機能する必要があります。同期レプリケーションを有効にする前に、少なくとも3つのメンバーに水平スケールする_必要が_あります。 PostgreSQL メンバーの追加を参照。

可能性は低いが、複数のレプリカが同時に利用できなくなる可能性はある。この場合、1 次データベースは、レプリカがオンラインに戻るまで書き込みを完了できません。これにより、データベースへのすべての書き込みトラフィックが事実上ブロックされます。同期レプリケーションの利用を決定する際には、データの耐久性が向上することと、潜在的な可用性の問題との相対的なコストとメリットを比較検討する。

同期レプリケーションを設定すると、書き込みレイテンシが大幅に増加し、全体のスループットが低下する可能性がある。パフォーマンスを最適化するには、最高度のデータ耐久性を必要とする特定のデータベースやワークロードにのみ同期レプリケーションを使用することをお勧めします。

災害復旧アーキテクチャ

災害復旧の一般的な戦略は、以下の Restore データベースのように、新しいデータベースを作成することです。新しいデータベースの内容は、災害前に作成されたソース・データベースのバックアップでもよい。本番データベースが利用可能であれば、ポイント・イン・タイム機能を使って新しいデータベースを作成することができる。

ディザスターリカバリー機能

Databases for PostgreSQL は、以下のディザスタリカバリ機能をサポートしている：

ディザスターリカバリー機能
特長	説明	考慮事項
バックアップ・リストア	Cloud Databases バックアップの管理を参照してください。	復元されたデータベースの新しい接続文字列は、ワークロード全体で参照されなければならない。
ポイント・イン・タイム・リストア	ポイント・イン・タイム・リカバリーを使用して、本番環境からデータベースを作成する	これは、アクティブなデータベースが利用可能で、RPO（災害）がサポートされているウィンドウ内にある場合にのみ可能である。本番クラスタが利用できない場合は役に立ちません。復元されたデータベースの新しい接続文字列は、ワークロード全体で参照されなければならない。
レプリカの販売促進	同じリージョンまたはリモートリージョンで災害を計画する場合は、読み取り専用のレプリカを作成する。災害から復旧するために、読み取り専用のレプリカをプロモートする。	以前に作成されたリードレプリカが利用可能でなければならない。復元されたデータベースの新しい接続文字列は、ワークロード全体で参照されなければならない。

災害復旧の計画

災害復旧の手順は、定期的に実践されなければならない。計画を立てる際には、次のような失敗のシナリオと解決策を検討してください。

失敗のシナリオと解決策
失敗	解決方法
ハードウェア障害（シングルポイント）	IBM は、ゾーン内の単一ハードウェア障害から回復力のあるデータベースを提供します。
ゾーン障害	自動フェイルオーバー(#postgresql-high-availability)。データベースのメンバーはゾーン間で分散される。 3つのメンバーを設定することで、複数のゾーン障害に対する耐障害性がさらに向上する。同期レプリケーションはパフォーマンスを犠牲にしてRPOを削減する。
データ破損	バックアップ・リストア。リストアしたデータベースを本番環境またはソース・データで使用し、リストアしたデータベースの破損を修正する。ポイントインタイム・リストア。リストアしたデータベースを本番環境またはソース・データで使用し、リストアしたデータベースの破損を修正する。
地域的な失敗	バックアップ・リストア。リストアしたデータベースを本番環境で使用する。レプリカを読むことを推進する。読み取り専用レプリカを読み取り/書き込みデータベースにプロモートする。リストアしたデータベースを本番環境で使用する

アプリケーション・レベルの高可用性

ネットワークとクラウド・サービスを介して通信するアプリケーションは、一時的な接続障害の影響を受けます。アプリケーションを設計する際には、デプロイメントまたは IBM Cloud への接続が一時的に失われてエラーが発生した場合に接続を再試行するように設計することができます。

Databases for PostgreSQL はマネージド・サービスであるため、定期的な更新とデータベースのメンテナンスは通常業務の一環として行われる。これにより、データベースを使用できなくなる、短時間の中断が発生することがあります。また、データベースが正常なフェイルオーバー、再試行、および再接続をトリガーする場合もあります。レプリカであるメンバーとリーダーであるメンバーをデータベースが判別するのに短い時間がかかるため、短い接続の中断が発生する可能性があります。フェイルオーバーにかかる時間は通常、30 秒未満です。

アプリケーションを設計する際には、データベースへの一時的な割り込みの処理、失敗したデータベース・コマンドのエラー処理の実装、一時的な中断から復旧するための再試行ロジックの実装を含める必要があります。

データベースを使用できない状態や接続の中断が数分に及ぶことは想定されていません。接続できない時間が1分以上ある場合は、詳細を添えてサポート・ケースを作成してください。

接続制限

Databases for PostgreSQL は、PostgreSQL データベースへの接続の最大数を 115 に設定します。スーパーユーザーがデータベースの状態と保全性を維持するために 15 個の接続が予約され、ユーザーとアプリケーションが 100 個の接続を使用できます。接続制限に達した後、新しい接続を開始しようとするとエラーになる。接続で配備を圧迫しないようにするには、接続プーリングを使用するか、配備を拡張して接続の上限を増やします。詳しくは、 PostgreSQL 接続の管理のページをご覧ください。

HAとDRの責任

以下の情報は、HAとDRのプランを作成し、継続的に実践するのに役立つ。

バックアップからデータベースをリストアする場合、またはポイントインタイム・リストアを使用する場合、新しい接続文字列で新しいデータベースが作成されます。既存のワークロードとプロセスは、新しい接続文字列を消費するように調整されなければならない。リードレプリカをクラスタに昇格させる場合も同様の影響がありますが、ワークロードの既存のリードオンリー部分は影響を受けません。

復旧したデータベースは、障害データベースと同じように、顧客が作成した依存関係を必要とする場合があります：

IBM® Key Protect for IBM Cloud®
Hyper Protect Crypto Services

データベースを削除すると、関連するバックアップも削除されることを忘れないでください。しかし、削除されたデータベースは、限られた時間枠内であれば復元できる可能性がある。データベースの復旧手順の詳細については、マニュアルを参照してください。

IBM Cloud、バックアップをコピーすることはできないため、追加のバックアップにはデータベース固有のツールを使用することを検討してください。悪意のあるデータベースの削除に続き、データベースの再削除からの復旧が必要になる場合があります。データベースへのIAMアクセスを注意深く管理することで、この問題にさらされる機会を減らすことができる。

各特徴に関連する以下のチェックリストは、プランの作成と実践に役立つ。

バックアップ・リストア
- RPO要件を満たすために、望ましい頻度でバックアップが利用可能であることを確認する。 Cloud Databases バックアップの管理は、バックアップの頻度を文書化する。 IBM Cloud® Code Engine 使用したスクリプトを検討してください。データベースの重要度とサイズが許す場合は、定期的なタイマー(cron)イベントプロデューサーと連携して追加のオンデマンドバックアップを作成し、RPO を改善します。しかし、 PostgreSQL's PITRの能力を考慮し、追加バックアップの必要性を慎重に評価する。
- データベースのリストア領域にはいくつかの制限があります。リストアの目標が達成できるかどうかは、 Cloud Databases バックアップの管理を参照してください。
- バックアップの保存期間が要件を満たしていることを確認する。
- テストリストアを定期的にスケジュールし、実際のリストア時間が定義されたRTOを満たしていることを検証する。データベースのサイズはリストア時間に大きく影響することを忘れないでください。大規模なデータベースをより小さく管理しやすい単位に分割したり、未使用のデータをパージするなど、リストア時間を最小化する戦略をご検討ください。
- Key Protect サービスを確認する。
ポイント・イン・タイム・リストア
- 先に説明した手順を確認する。
- 目的のバックアップがウィンドウ内にあることを確認する。
レプリカの販売促進
- リカバリ領域にリードレプリカが存在することを確認する。
- 希望するリージョンに一時的なリードレプリカを作成する。一時的なレプリカを読み取り/書き込みに昇格させ、本番環境にほとんど影響を与えることなくテストを行うことができます。

Databases for PostgreSQL を使用する際の顧客と IBM Cloud との間の責任分担については、 Cloud Databases の責任分担を参照のこと。

最新情報： IBM

顧客のワークロードに影響を与えるアップデートは、 IBM Cloud の通知を通じて知らされる。本サービスに関連する計画的なメンテナンス、アナウンスメント、リリースノートに関する情報は、モニタリングの通知とステータスのページをご参照ください。さらに、バージョン・ポリシーのページを定期的に確認し、End-of-Lifeのバージョンと日付に関する最新のアップデートを確認してください。