AI エージェント向け: ドキュメントインデックスは https://www.mongodb.com/ja-jp/docs/llms.txt で利用できます。すべてのページの markdown バージョンは、いずれかの URL パスに .md を追加することで利用できます。
Docs Menu

クラスター メンテナンスの管理

次の項目を設定することで、Atlas がプロジェクトのメンテナンスを展開する方法を管理できます。

  • 保護時間: 標準的な更新を実行できないビジネスクリティカルな時間。

  • メンテナンスWindows: Atlas が週次メンテナンスを開始する時刻で、プロジェクト内のクラスターのレプリカセットの選挙が必要です。

  • メンテナンス 頻度:組織内のプロジェクトがメンテナンスを受信する順序。メンテナンス 証明書は、Wave 1 からLast Wave まで順番にラベル付けされます。

プロジェクション メンテナンス スケジュール ツールを使用して、メンテナンスウィンドウ、保護された時間、メンテナンスウィンドを指定して、Atlas がプロジェクトにメンテナンスをどのようにロールアウトするかを視覚化できます。

重要

メンテナンスウィンドウ、保護されている時間、メンテナンス 頻度はプロジェクトごとに構成され、専用クラスター(M10 以上)にのみ適用されます。無料クラスターと Flex クラスターの場合、Atlas はメンテナンスウィンドウを自動的に管理し、手動で設定することはできません。

メンテナンスウィンドウ、保護されている、メンテナンスウィンドを設定することをお勧めしますが、時間はすべて任意です。 Atlas は、回復力のあるアプリケーションの継続的な可用性を維持するために、メンテナンスを自動的にローリング方式で実行します。アプリケーションがレプリカセットの選挙に対して回復力があることを確認するには、Atlas でフェイルオーバーをテスト します。

詳しくは以下を参照してください。

  • 保護時間:メンテナンスウィンドウの構成に加え、Atlas が標準更新の実行を回避する時間枠である毎日の保護時間数を設定できます。保護された時間の長ウィンドウは、18 時間を超えることはできません。

    Atlas は、クラスターの再起動を実行したり、 構成されたメンテナンスウィンドウの外部でワークロードのパフォーマンスに影響しない標準的な更新を実行できますが、Atlas は常に保護された時間 を尊重します。

  • 至急のメンテナンス アクティビティ: Atlas は、設定されたメンテナンスウィンドウ、保護された時間、またはメンテナンス ウェブに関係なく、必要に応じてすぐに緊急のメンテナンス アクティビティ(ゼロ デー脆弱性に対するセキュリティ パッチなど)を実行する場合があります。

  • 継続的なメンテナンス操作: クラスターのメンテナンスウィンドウを予定すると、進行中のメンテナンス操作が完了するまで変更できません。

  • MongoDB データベースのアップグレード: メンテナンスに MongoDB マイナーバージョンまたはパッチバージョンのアップグレードが含まれる場合、Atlas は現在のバージョンと対象バージョンをコンソールに表示します。Atlas が次回のメンテナンスウィンドウ中にいずれかのクラスターの MongoDB メンテナンスバージョンをアップグレードする場合、クラスターのカードには対象の MongoDB メンテナンスバージョンが表示されます。

  • メンテナンスにはレプリカセットの選挙が必要です: Atlas は、MongoDB マニュアルで説明されているメンテナンス手順と同じ方法でメンテナンスを実行します。この手順では、レプリカセットごとに、メンテナンスウィンドウ中に少なくとも 1 回のレプリカセット選挙が必要です。アプリケーションがレプリカセットの選挙に対して回復力があることを確認するには、Atlas でフェイルオーバーをテストします

  • メンテナンスは可能な限りウィンドウの開始時間に近い時間で開始します: メンテナンスは常に可能な限り予定時刻に近い時間に開始されますが、進行中のクラスター更新や予期しないシステム問題により、開始時間が遅れる可能性があります。

  • メンテナンス中の一時的なパフォーマンス低下の可能性: ディスク IOPS が低い場合、MongoDB が WiredTiger ストレージエンジンを再構築する間、クラスターのパフォーマンスがメンテナンス中一時的に低下する可能性があります。詳しくは、「ジャーナリングと WiredTiger ストレージエンジン」をご覧ください

  • デフォルトのメンテナンス 頻度: Atlas は、次のルールを使用して、明示的な頻度の割り当てがないプロジェクトにメンテナンス レームを自動的に割り当てます。

    • Atlas は、設定されたメンテナンスウィンドウがないプロジェクトを Wave1 に割り当てます。

    • Atlas は、設定されたメンテナンスウィンドウを持つプロジェクトを Wave2 に割り当てます。

    これらの動的な割り当てをいつでも手動で変更できます。詳細については、「 メンテナンス管理設定の構成 」を参照してください。

  • メンテナンス 頻度の評価: Atlas は、メンテナンスイベントが初めて発生したときに、構成されたメンテナンス 頻度を評価します。メンテナンスイベントが開始されてから、すべての期間にわたって完了するまでの間にメンテナンス レイテンシに変更を加えると、Atlas は次の メンテナンスイベントの開始時に新しいメンテナンス レイテンシの使用を開始します。

  • メンテナンス間の時間:48 メンテナンスウィンドが設定されている場合、Atlas が 1 つの測定値にメンテナンスをロールアウトするまでに少なくとも 時間の間隔があります。 Atlas がWave 1 から始まる次のレイテンシに進む前に、特定のレイテンシに割り当てられたすべてのプロジェクトのメンテナンスが完了している必要があります。

Scheduled Maintenance Operations モーダルには、次のメンテナンス タイプが 1 つ以上表示される場合があります。

  • MongoDB 必須メンテナンス: クラスターの正常性と安定性を維持するために必要な重要なメンテナンス操作です。

  • MongoDB のバージョン更新: MongoDB のマイナー バージョン、パッチ バージョン、またはメンテナンス リリースへのアップグレード。

  • OS ポリシーバージョンの更新: 基礎のオペレーティングシステムポリシーとセキュリティパッチを更新します。

  • その他のメンテナンス操作: クラスター管理に必要な追加のメンテナンス作業です。

メンテナンス操作が完了すると、プロジェクト アクティビティフィードMaintenance window completedイベントが表示されます。

Automatically defer maintenance for one week オプションを有効にすると、Atlas が今後予定されるメンテナンスを 1 週間ごとに自動的に延期することができます。これは、メンテナンスが毎週ではなく 2 週間ごとに実行されることを意味します。これは、最初の週は毎回自動的に延期されるためです。必要な場合は、メンテナンスを手動で追加時間延期することもできます。

重要

組織内のプロジェクトに対してメンテナンス用に構成されている場合、その組織内のプロジェクトに対して自動延期するメンテナンスを構成することはできません。

Automatically defer maintenance for one weekオプションを有効にすると、Atlas は将来のメンテナンスウィンドウの自動延期を構成します。現在スケジュールされているメンテナンスを延期するには、「Defer 1 Week メンテナンスの延期 」セクションで説明されているように、 オプションを使用します。

自動デフォルトを使用すると、メンテナンス操作を 1 つのメンテナンスウィンドウに統合し、メンテナンス イベントの総数を減らすことができます。アップデートが本番環境に達する前にアップデートを検証するために、下位環境でメンテナンスをテストする場合は、自動延期を使用する代わりに メンテナンスウィンド を使用します。

自動延期を有効にするには、「 メンテナンス管理設定の構成 」を参照してください。

多くのコード開発設定は、最も一般的にはワークフローを異なる環境に分割します。

  • 開発(Dev): 開発者が最初に新しいコードを記述してテストします。

  • 品質保証(QA): テスターは、実際のワークロードをシミュレートした環境で、バグ、パフォーマンス、信頼性のコードをレビューします。

  • 本番環境(Prod): エンドユーザーがコードにアクセスして操作します。

メンテナンス 証明書は、ユーザー向け環境にロールアウトされる前にクラスターのメンテナンスが内部環境にどのように影響するかを監視できるため、環境分離されたワークフローに役立ちます。

これらの環境または同様の環境全体でプロジェクトでメンテナンス レイテンシを使用するには、各環境で同じメンテナンス レイテンシと保護された時間数を設定することをお勧めします。次に、各環境をメンテナンス ウェブで次のように割り当てます。

  • Dev toWave 1

  • QA からWave 2

  • に提供Last Wave

これにより、メンテナンス イベントが各環境にロールアウトされるまでの間隔が少なくとも 7 日間保証されます。 Last Wave に割り当てられたプロジェクトのメンテナンスを 7 日間追加で延期することもできます。

メンテナンスイベントがプロジェクトにロールアウトされるタイミングを視覚化するには、 プロジェクション メンテナンス スケジュール ツールを使用できます。このツールを使用すると、潜在的なメンテナンスウィンドウとターム、およびメンテナンス リリース日を入力できます。これらの設定とリリース日を指定すると、ツールには Atlas がプロジェクトのメンテナンスを実行する日付と時刻が各レイテンシで表示されます。

このツールは Atlas アカウントにリンクされていません。Atlas で構成した設定を読み取ったり、プロジェクトや組織の設定を構成したりすることはできません。