Databases for MongoDB の高可用性と災害復旧について
高可用性サービスまたは作業負荷が障害に耐え、事前に定義されたサービスレベルに従って処理能力を提供し続ける能力。 サービスについては、可用性はサービスレベル契約で定義されています。 可用性には、計画されたイベントと計画外のイベントの両方が含まれます。計画外のイベントには、メンテナンス、故障、災害などが含まれます。 (HA) とは、予期しない障害が発生した場合でもサービスが稼働し続け、アクセス可能になる能力です。 ディザスタリカバリとはサービスの中断などの稀な重大なインシデントや広範囲にわたる障害から、サービスや作業負荷が回復する能力。 これには、地域全体に影響を及ぼす物理的な災害、データベースの破損、作業負荷に寄与するサービスの損失などが含まれます。 その影響は、高可用性設計が処理できる能力を超えています。、サービスインスタンスを稼動状態に回復させるプロセスである。
Databases for MongoDB は、スタンダードプランとエンタープライズプランで定義された サービスレベル目標（SLO ）を満たす地域サービスである。 詳しくは、 サービス・レベル・アグリーメント（SLA ）を参照。 Databases for MongoDB で利用可能な IBM Cloud リージョンとデータセンターの詳細については、 ロケーション別のサービスとインフラの可用性を 参照してください。
高可用性アーキテクチャ
Databases for MongoDB は、レプリケーション、フェイルオーバー、および高可用性機能を提供し、インフラストラクチャのメンテナンス、アップグレード、および一部の障害からデータベースとデータを保護します。 デプロイメントには、3つのデータ・メンバー（1つのプライマリ・メンバーと2つのセカンダリ・メンバー）を持つクラスタが含まれます。 2つのメンバーのレプリカセットは、非同期レプリケーションを使って最新の状態に保たれる。 分散コンセンサスメカニズムは、クラスタの状態を維持し、フェイルオーバーを処理するために使用される。 プライマリが利用できない場合、レプリカセットはセカンダリをプライマリとして選択し、通常の運用を継続する。 元の 1 次ノードは、使用可能になるとセットに再参加します。 プライマリーメンバーとセカンダリーメンバーは、常にMZRの異なるゾーンにいる。 ゾーン障害によってメンバーが失敗した場合、新しいレプリカは生き残ったゾーンに作成される。
高可用性機能
Databases for MongoDB は以下の高可用性機能をサポートしている。
| 特長 | 説明 |
|---|---|
| 自動フェイルオーバー | すべてのクラスタに標準装備され、ゾーンや単一メンバーの障害に強い。 |
| メンバー数 | 最低3名。 デフォルトは標準的な3人のメンバー配置。 3メンバーのクラスタは、単一のインスタンスまたはゾーンの障害から自動的に回復する（ラグしきい値までのデータ損失）。 |
| 非同期複製 | セカンダリはプライマリのオペレーションを複製し、そのオペレーションを非同期にデータセットに適用する。 セカンダリのデータセットにプライマリのデータセットを反映させることで、レプリカセットは1人以上のメンバーが故障しても機能し続けることができる。 |
災害復旧アーキテクチャ
災害復旧の一般的な戦略は、次のような新しいデータベースを作成することである MongoDB Restore データベース。 新しいデータベースの内容は、災害前に作成されたソース・データベースのバックアップでもよい。 Enterpriseプランのポイントインタイム機能を使用して、本番データベースが利用可能であれば、新しいデータベースを作成することができます。
ディザスターリカバリー機能
Databases for MongoDB は、以下のディザスタリカバリ機能をサポートしている。
| 特長 | 説明 | 考慮事項 |
|---|---|---|
| バックアップ・リストア | Cloud Databases バックアップの管理 を参照してください。 | 復元されたデータベースの新しい接続文字列は、ワークロード全体で参照されなければならない。 |
| ポイント・イン・タイム・リストア | ポイント・イン・タイム・リカバリを 使用して、本番環境からデータベースを作成します。 | これは、Enterpriseプランで、アクティブなデータベースが利用可能で、RPO（災害）がサポートされるウィンドウ内にある場合にのみ可能です。 本番クラスタが利用できない場合は役に立ちません。 復元されたデータベースの新しい接続文字列は、ワークロード全体で参照されなければならない。 |
災害復旧の計画
災害復旧の手順は、定期的に実践されなければならない。 計画を立てる際には、次のような失敗のシナリオと解決策を検討してください。
| 失敗 | 解決方法 |
|---|---|
| ハードウェア障害（シングルポイント） | IBM は、ゾーン内の単一ハードウェア障害から回復力のあるデータベースを提供します。 |
| ゾーン障害 | 自動フェイルオーバー。 データベースのメンバーはゾーン間で分散される。 3つのメンバーを構成することで、複数のゾーン障害に対する耐障害性がさらに向上する。 |
| データ破損 | バックアップ・リストア。 リストアしたデータベースを本番環境またはソース・データで使用し、リストアしたデータベースの破損を修正する。
ポイントインタイム・リストア。 リストアしたデータベースを本番環境またはソース・データで使用し、リストアしたデータベースの破損を修正する。 |
| 地域的な失敗 | バックアップ・リストア。 リストアしたデータベースを本番環境で使用する。 |
アプリケーション・レベルの高可用性
ネットワークとクラウド・サービスを介して通信するアプリケーションは、一時的な接続障害の影響を受けます。 アプリケーションを設計する際には、デプロイメントまたは IBM Cloud への接続が一時的に失われてエラーが発生した場合に接続を再試行するように設計することができます。
アプリケーションを設計する際には、データベースへの一時的な割り込みの処理、失敗したデータベース・コマンドのエラー処理の実装、一時的な中断から復旧するための再試行ロジックの実装を含める必要があります。
データベースを使用できない状態や接続の中断が数分に及ぶことは想定されていません。 接続できない時間が1分以上ある場合は、詳細を添えて サポート・ケースを 作成してください。
HAとDRの責任
以下の情報は、HAとDRのプランを作成し、継続的に実践するのに役立つ。
バックアップからデータベースをリストアする場合、またはポイントインタイム・リストアを使用する場合、新しい接続文字列で新しいデータベースが作成されます。 既存のワークロードとプロセスは、新しい接続文字列を消費するように調整されなければならない。 リードレプリカをクラスタに昇格させる場合も同様の影響がありますが、ワークロードの既存のリードオンリー部分は影響を受けません。
復旧したデータベースは、災害データベースと同じように、顧客が作成した依存関係を必要とする場合があります：
- IBM® Key Protect for IBM Cloud®
データベースを削除すると、関連するバックアップも削除されることを忘れないでください。 しかし、削除されたデータベースは、限られた時間枠内であれば復元できる可能性がある。 データベース復旧手順の具体的な詳細については、 FAQ バックアップのドキュメントを 参照してください。
IBM Cloud、バックアップをコピーすることはできないため、追加のバックアップにはデータベース固有のツールを使用することを検討してください。 悪意のあるデータベースの削除に続き、データベースの再削除からの復旧が必要になる場合があります。 データベースへのIAMアクセスを注意深く管理することで、この問題にさらされる機会を減らすことができる。
各特徴に関連する以下のチェックリストは、プランの作成と実践に役立つ。
- バックアップ・リストア
- RPO要件を満たすために、望ましい頻度でバックアップが利用可能であることを確認する。 Cloud Databases バックアップの管理は、バックアップの頻度を文書化する。 IBM Cloud® Code Engine を使用したスクリプトを検討してください - データベースの重要度とサイズが許せば、定期タイマー(cron)イベント プロデューサーと連携して 追加のオンデマンド バックアップを作成し、RPO を改善します。
- データベースのリストア領域にはいくつかの制限があります。 Cloud Databases バックアップの管理を 読んで、リストア目標が達成できることを確認してください。
- バックアップの保存期間が要件を満たしていることを確認する。
- テストリストアを定期的にスケジュールし、実際のリストア時間が定義されたRTOを満たしていることを検証する。 データベースのサイズはリストア時間に大きく影響することを忘れないでください。 大規模なデータベースをより小さく管理しやすい単位に分割し、未使用のデータを消去するなど、リストア時間を最短化する戦略を検討する。
- Key Protect サービスを確認する。
- ポイント・イン・タイム・リストア
- 先に説明した手順を確認する。
- 目的のバックアップがウィンドウ内にあることを確認する。
Databases for MongoDB を使用する際の顧客と IBM Cloud との間の責任分担の詳細については、 Cloud Databases の責任分担を 参照のこと。
最新情報： IBM
顧客のワークロードに影響を与えるアップデートは、 IBM Cloud 通知を通じて通知される。 このサービスに関する計画的なメンテナンス、アナウンスメント、リリースノートに関する情報を入手するには、 監視通知とステータスを 参照してください。 さらに、 バージョンポリシーを 定期的に見直し、使用終了バージョンと日付の最新情報を確認する。