翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Amazon DocumentDB のメンテナンス
Amazon DocumentDB は定期的に 2 種類のメンテナンスを実行します。
-
クラスターメンテナンスはデータベースエンジンを更新します。エンジンの更新には、セキュリティ修正、バグ修正、新機能、その他のエンジンの機能強化が含まれています。
-
インスタンスメンテナンスは、インスタンスのオペレーティングシステム (OS) を更新します。
エンジンパッチと OS 更新では、オプション、必須、強制の 3 つのライフサイクルカテゴリが同じ通知で使用され、各カテゴリの動作が適用されます。エンジンリリースには、手動でアップグレードするマイナーバージョンという 4 番目のカテゴリもあります。カテゴリは次のとおりです。
-
オプション — 重要でない改善が含まれています。自動適用日や AHD 通知はありません。必要に応じて適用されます。(OS の更新については、 にサブスクライブ
RDS-EVENT-0230して、利用可能になったときに通知を受け取ることができます）。 -
必須 — セキュリティやその他の重要な修正が含まれています。( Health Dashboard AHD) と E メールを通じて通知を受け取ります。必要なアクションは、クラスターまたはインスタンスのメンテナンスウィンドウの後に自動適用されます
AutoAppliedAfterDate。その日付より前にメンテナンスウィンドウを変更することで、延期できます。 -
強制的 — まれで重要度の高い修正。の後にメンテナンスウィンドウ外に自動的に適用されます
ForcedApplyDate。Amazon DocumentDB は、他のオプションが利用できない場合にのみ強制されるアクションを指定します。 -
マイナーバージョン (エンジンリリースのみ) — メジャーバージョン (例: ) 上の番号付きエンジンリリース
5.0.1。ユーザー主導: クラスターのエンジンバージョンを変更してアップグレードします。自動適用しないでください。AHD 通知はありません。マイナーバージョンは、5.0 より前のメジャーバージョンでは公開されません。
エンジンパッチは 1 つのカテゴリ (オプション、必須、または強制) にリリースされ、そこに留まります。OS 更新の進行状況: ほとんどの はオプションとして開始され、適用されていない場合は必須に移行し、最終的に強制されます。正確なタイミングはパッチによって異なり、AHD 通知と によって返される日付フィールドで公開されます describe-pending-maintenance-actions (「」を参照日付の適用)。Amazon DocumentDB リリースノートは、エンジンの変更を発表するときにこれらのカテゴリ名を使用します。
エンジンパッチを適用すると、クラスターは短時間オフラインになります。このトピックの残りの部分では、メンテナンスウィンドウの仕組み、保留中の作業の検索方法、エンジンパッチとマイナーバージョンの適用方法、OS 更新の仕組み、グローバルクラスターの特別な処理について説明します。
トピック
エンジンバージョンの番号付け
Amazon DocumentDB は 2 つの個別のバージョン識別子を使用します。
-
エンジンバージョン — 形式の 3 つの部分からなる番号
major.major.minor5.0.0または5.0.1)。最初の 2 つのパート (5.0) は MongoDB 互換バージョンです。3 番目のパートはマイナーバージョンで、Amazon DocumentDB がバグ修正と大幅な改善を含むマイナーリリースを発行するときに増加します。これは、クラスターを作成またはアップグレードするときに指定するバージョンです。 -
エンジンパッチバージョン — クラスターに適用されるパッチレベルを識別するフォーム内の個別の 3 つの部分からなる番号
major.0.patch3.0.17983)。中間の数字は常に です0。パッチバージョンには、重要なセキュリティと安定性の修正が含まれています。
次の表に示すように、エンジンパッチバージョンのプレフィックスからエンジンバージョンを確認できます。
| エンジンパッチバージョンのプレフィックス | Amazon DocumentDB エンジンバージョン |
|---|---|
1.0. |
3.6 |
2.0. |
4.0 |
3.0. |
5.0 |
4.0. |
8.0 |
クラスターが実行中のパッチバージョンを確認するには、 を接続して実行しますdb.runCommand({getEngineVersion: 1})。
リリースされたエンジンパッチバージョンのリストと各バージョンに含まれるものについては、「」を参照してくださいリリースノート。
Amazon DocumentDB メンテナンスウィンドウの管理する
各クラスターと各インスタンスには、スケジュールされた変更とソフトウェアパッチ適用が実行される期間である、週 30 分の独自のメンテナンスウィンドウがあります。ほとんどのイベントは 30 分以内に完了します。大きなイベントはより長く実行できます。
リソースの作成時にウィンドウを選択しない場合、Amazon DocumentDB は、ランダムに選択された日に、リージョンに定義された 8 時間の 1 日あたりのブロック内でランダムに 1 つを割り当てます。たとえば、夜や週末など、アプリケーションへの影響を最小限に抑えるウィンドウを選択します。
データベースエンジンのアップグレードの場合、Amazon DocumentDB は個々のインスタンスのウィンドウではなく、クラスターのウィンドウを使用します。
次の表は、リージョンごとのデフォルトのタイムブロックを示しています。
| リージョン名 | リージョン | UTC 時間帯 |
|---|---|---|
| 米国東部 (オハイオ) | us-east-2 | 03:00 ～ 11:00 |
| 米国東部 (バージニア北部) | us-east-1 | 03:00 ～ 11:00 |
| 米国西部 (オレゴン) | us-west-2 | 06:00 ～ 14:00 |
| アフリカ (ケープタウン) | af-south-1 | 03:00 ～ 11:00 |
| アジアパシフィック (香港) | ap-east-1 | 06:00 ～ 14:00 |
| アジアパシフィック (ハイデラバード) | ap-south-2 | 06:30 ～ 14:30 |
| アジアパシフィック (マレーシア) | ap-southeast-5 | 13:00 ～ 21:00 |
| アジアパシフィック (ムンバイ) | ap-south-1 | 06:00 ～ 14:00 |
| アジアパシフィック (大阪) | ap-northeast-3 | 12:00 ～ 20:00 |
| アジアパシフィック (ソウル) | ap-northeast-2 | 13:00 ～ 21:00 |
| アジアパシフィック (シンガポール) | ap-southeast-1 | 14:00 ～ 22:00 |
| アジアパシフィック (シドニー) | ap-southeast-2 | 12:00 ～ 20:00 |
| アジアパシフィック (ジャカルタ) | ap-southeast-3 | 08:00～16:00 |
| アジアパシフィック (メルボルン) | ap-southeast-4 | 11:00～19:00 |
| アジアパシフィック (タイ) | ap-southeast-7 | 15:00 ～ 23:00 |
| アジアパシフィック (東京) | ap-northeast-1 | 13:00 ～ 21:00 |
| カナダ (中部) | ca-central-1 | 03:00 ～ 11:00 |
| カナダ西部 (カルガリー) | ca-west-1 | 18:00～02:00 |
| 中国 (北京) | cn-north-1 | 06:00 ～ 14:00 |
| 中国 (寧夏) | cn-northwest-1 | 06:00 ～ 14:00 |
| 欧州 (フランクフルト) | eu-central-1 | 21:00 ～ 05:00 |
| 欧州 (チューリッヒ) | eu-central-2 | 02:00 ～ 10:00 |
| 欧州 (アイルランド) | eu-west-1 | 22:00 ～ 06:00 |
| 欧州 (ロンドン) | eu-west-2 | 22:00 ～ 06:00 |
| 欧州 (ミラノ) | eu-south-1 | 02:00 ～ 10:00 |
| 欧州 (パリ) | eu-west-3 | 23:59 ～ 07:29 |
| 欧州 (スペイン) | eu-south-2 | 02:00 ～ 10:00 |
| 欧州 (ストックホルム) | eu-north-1 | 04:00 ～ 12:00 |
| メキシコ (中部) | mx-central-1 | 03:00 ～ 11:00 |
| 中東 (UAE) | me-central-1 | 05:00 ～ 13:00 |
| 南米 (サンパウロ） | sa-east-1 | 00:00 ～ 08:00 |
| イスラエル (テルアビブ) | il-central-1 | 04:00 ～ 12:00 |
| AWS GovCloud (米国東部) | us-gov-east-1 | 17:00 ～ 01:00 |
| AWS GovCloud (米国西部) | us-gov-west-1 | 06:00 ～ 14:00 |
Amazon DocumentDB メンテナンスウィンドウを変更する
可能な最低トラフィックウィンドウを選択し、トラフィックパターンの変化に応じて時間の経過とともに調整します。クラスターまたはインスタンスは、スケールストレージオペレーションやインスタンスクラスの変更などのシステム変更が停止を必要とする場合にのみ、その変更が実際に必要である限り、ウィンドウ中に使用できなくなります。
メンテナンスウィンドウを変更するには
-
クラスターの場合には、「Amazon DocumentDB クラスターの変更」を参照してください。
-
インスタンスの場合には、「Amazon DocumentDB インスタンスの変更」を参照してください。
Amazon DocumentDB エンジンパッチの通知
必要なエンジンパッチが AWS リージョンで利用可能になると、そのリージョン内の影響を受ける Amazon DocumentDB クラスターを持つすべての AWS アカウントは、 Health Dashboard (AHD) と E メール ( AWS アカウントのルートユーザーアドレスに送信される) を通じて通知を受け取ります。影響を受ける Amazon DocumentDB エンジンのバージョンごとに 1 つの通知が配信されます。これらは、AHD のスケジュールされた変更にあります。各通知には、パッチの可用性のタイミング、自動適用スケジュール、影響を受けるクラスター、リリースノートが一覧表示されます。
自動適用ウィンドウが開く約 2 日前に通知が出力されます。たとえば、月曜日の 00:00 UTC にリリースされた必要なパッチは、水曜日の 00:00 UTC に自動適用の対象となります。クラスターのメンテナンスウィンドウが水曜日の 12:00 UTC の場合、パッチはその水曜日に自動適用します。自動適用ウィンドウが開いてから約 12 時間後です。メンテナンスウィンドウが火曜日の 12:00 UTC の場合、パッチは自動適用まで 1 週間待機します。
通知を受け取った後、2 つのオプションがあります。自動適用日より前にパッチを自己適用するか、次回のメンテナンスウィンドウ (デフォルト) 中にパッチが自動適用されるまで待機します。自己適用するには、クラスターのメンテナンスとバックアップタブを開き、タイプ のエントリを探しますsystem-update。
注記
AHD の通知のステータスは、Amazon DocumentDB が新しいパッチバージョンで別のエンジンパッチをリリースするまで、進行中のままです。
パッチを適用すると、クラスターのエンジンパッチバージョンが通知のバージョンと一致するように更新されます。を実行して新しいバージョンを確認しますdb.runCommand({getEngineVersion: 1})。
オプションのパッチと新しいマイナーバージョンでは、AHD または E メール通知は生成されません。これらを追跡するには、Amazon DocumentDB リリースノートをご覧ください。
強制パッチ (最も重要なセキュリティ修正のために予約された最もまれなカテゴリ) も、AHD と E メールで発表されます。必要なパッチとは異なり、メンテナンスウィンドウ外に適用されるため、上記の自動適用タイミングの例は適用されません。
プログラムによるパッチ通知への対応
AWS Health は Amazon EventBridge と統合されており、 AWS Lambda や Amazon Simple Queue Service (SQS) など、20 を超えるターゲットでイベント駆動型アプリケーションを構築できます。プログラムでエンジンパッチの可用性に対応するには、AWS_DOCDB_DB_PATCH_UPGRADE_MAINTENANCE_SCHEDULEDイベントに対して EventBridge を設定します。そこから、イベントデータをキャプチャしたり、追加のイベントを発生させたり、 経由でプッシュ通知を送信したり AWS Console Mobile Application、その他の必要なアクションを実行したりできます。
Amazon DocumentDB がパッチをキャンセルした場合 (まれ）、AHD 通知とキャンセルに関する E メールが送信されます。Amazon EventBridge でAWS_DOCDB_DB_PATCH_UPGRADE_MAINTENANCE_CANCELLEDイベントコードを使用して、このケースを処理します。ルールの記述の詳細については、「Amazon EventBridge ユーザーガイド」を参照してください。
実施待ちの Amazon DocumentDB メンテナンスアクションを確認する
AWS マネジメントコンソール または を使用して AWS CLI 、クラスターまたはインスタンスで保留中のメンテナンスを確認します。
保留中の更新はsystem-update、エンジンパッチと OS 更新の両方をカバーするアクションタイプ で表示されます。
更新が保留中の場合、次のことができます。
-
すぐに適用します。
-
次のメンテナンスウィンドウにスケジュールします。
-
より前にメンテナンスウィンドウを変更して、これを延期します (エンジンパッチと OS 更新のみ)
AutoAppliedAfterDate。その日付が過ぎると、アクションは次のメンテナンスウィンドウ中に自動的に適用されます。ForcedApplyDate合格すると、それ以上の延期はできません。
注記
アクションを実行しない場合、必要なエンジンパッチなどの必要なメンテナンスアクションは、今後のメンテナンスウィンドウ中に自動的に適用されます。オプションのパッチとマイナーバージョンは自動適用されません。
メンテナンスウィンドウは、保留中のオペレーションが開始されるタイミングを制御し、完了までにかかる時間を制御します。
日付の適用
保留中の各メンテナンスアクションには、最大 3 つの適用日があります。これらは の AWS CLI 出力に表示されdescribe-pending-maintenance-actions、アクションが実行されるタイミングを示します。フィールドはオプションのメンテナンスnull用です。
-
CurrentApplyDate— 現在または次のメンテナンスウィンドウのいずれかで、アクションの実行がスケジュールされている場合。必須アクションと強制アクションに入力します。 -
AutoAppliedAfterDate— クラスターまたはインスタンスのメンテナンスウィンドウ中に自動適用が開始される日付。必要なアクションに入力します。 -
ForcedApplyDate— 厳しい期限。この日付を過ぎると、メンテナンスウィンドウに関係なくアクションが自動的に実行されます。強制アクションに設定されます。
保留中のアクションを延期するには、メンテナンスウィンドウを の翌日に移動しますAutoAppliedAfterDate。がAutoAppliedAfterDate過ぎると、アクションは次のメンテナンスウィンドウ中に自動的に適用されます。ForcedApplyDate 合格すると、それ以上の延期はできません。正確な遅延ウィンドウはパッチによって異なります。日付は AHD 通知と AWS CLI 出力で公開されます。
Amazon DocumentDB エンジンの更新
保留中のエンジンパッチを特定したら、次のいずれかの手順を使用して適用またはスケジュールします。これらの手順は、 AWS マネジメントコンソール または から実行できます AWS CLI。
パッチ適用中の読み取り可用性
Amazon DocumentDB エンジン 5.0 および 8.0 は、クラスターに複数のインスタンスがある場合、パッチ適用中の読み取り可用性を維持します。Amazon DocumentDB は、3 つのグループにローリング方式でリーダーインスタンスにパッチを適用するため、残りのリーダーは引き続きトラフィックを処理します。ライターは、パッチ適用中は一時的に使用できません。読み取りダウンタイムをゼロにするには、読み取り設定を設定して、読み取りがライターにフォールバックしたり、primaryPreferred機能secondaryPreferredしたり、primarysecondary単独で読み取りダウンタイムが発生したりします。
| 読み取り設定モード | ライターのアップグレード中 | リーダーのアップグレード中 | 読み取りダウンタイムゼロに必要なリーダーの最小数 |
|---|---|---|---|
primary |
読み取り/書き込みのダウンタイム | 影響なし | 該当なし |
primaryPreferred |
書き込みダウンタイム | 影響なし | 1 |
secondary |
書き込みダウンタイム | 読み取りダウンタイム (リーダーが 1 つだけの場合) | 2 |
secondaryPreferred |
書き込みダウンタイム | 影響なし | 1 |
nearest |
書き込みダウンタイム | 影響なし | 1 |
リーダーがパッチを適用している間、クラスター全体の読み取りスループットは一時的に低下します。スループットを安定させるには、アップグレード前に追加のリーダーをプロビジョニングし、完了後に削除します。
エンジン 3.6 および 4.0 では、これらの読み取り可用性機能は適用されません。エンジンパッチにより、読み取りと書き込みの両方に影響するダウンタイムが長くなります。が実行するメジャーバージョンにアップグレードするには、「」を参照してくださいAmazon DocumentDB のインプレースメジャーバージョンアップグレード。
パッチのダウンタイムの長さ
エンジンパッチのダウンタイムはさまざまです。最も大きな要因は、パッチ適用時のインスタンスの CPU 使用率とメモリ負荷であるため、インスタンスの適切なサイズ設定が重要です。ダウンタイムを最小限に抑えるには、最新の Amazon DocumentDB メジャーエンジンバージョンを実行し、複数のアベイラビリティーゾーンにインスタンスを分散します。
パッチの更新と置換
Amazon DocumentDB は、リリース後にパッチをモニタリングします。まれに問題が特定された場合、Amazon DocumentDB は更新バージョンの準備中にロールアウトを一時停止します。この場合、パッチをまだ受け取っていないクラスターは、パッチを使用可能なメンテナンスアクションと見なさなくなり、 の対応するスケジュールされた変更通知 Health Dashboard が取り消されます。影響を受けるバージョンをすでに実行しているクラスターは引き続き正常に動作するため、ユーザーによるアクションは必要ありません。
更新されたパッチは間もなく続きます。リージョンで利用可能になると、「」で説明されているように、 Health Dashboard と E メールを通じて新しい通知が送信されますAmazon DocumentDB エンジンパッチの通知。
マイナーバージョンのアップグレード
Amazon DocumentDB は、メジャーバージョン 5.0 以降 ( など5.0.1) 上にマイナーバージョンを発行します。マイナーバージョンは、5.0 より前のメジャーバージョンでは公開されません。マイナーバージョンの動作は、必須およびオプションのエンジンパッチとは異なります。
-
保留中のメンテナンスアクションとしては表示されず、自動適用もされません。
-
AHD または E メール通知は生成されません。新しいマイナーバージョンは、Amazon DocumentDB リリースノートで発表されています。
-
アップグレードするには、クラスターのエンジンバージョンを変更します (即時または次のメンテナンスウィンドウ中に）。マイナーバージョンのアップグレードには短いダウンタイムが必要で、一方通行です。以前のマイナーバージョンにダウングレードすることはできません。グローバルクラスターの場合は、プライマリクラスターの前にセカンダリクラスターをアップグレードします。
詳細については、「」を参照してくださいAmazon DocumentDB マイナーバージョンアップグレード。
Amazon DocumentDB オペレーティングシステムの更新
インスタンスには OS 更新が必要になる場合があります。Amazon DocumentDB は OS を更新してパフォーマンスを向上させ、セキュリティを強化します。OS の更新により、クラスターエンジンのバージョンとインスタンスクラスは変更されません。エンジンパッチと同様に、OS 更新では、このトピックの上部で説明されているオプション/必須/強制ライフサイクルが使用されます。エンジンパッチとは異なり、OS 更新を延期すると、時間の経過とともにこれらのカテゴリに移行する可能性があります。OS 更新が利用可能になったらすぐに適用し、インスタンスのメンテナンスウィンドウをビジネスに適した時間に設定します。
新しいオプションの更新が到着したときにイベントを取得するには、セキュリティパッチ適用イベントカテゴリRDS-EVENT-0230で をサブスクライブします。詳細については、「Amazon DocumentDB イベントにサブスクライブする」を参照してください。通知を受け取ったら、OS パッチを各インスタンスに自己適用できます。
クラスターにパッチを適用するときは、最初にリーダーインスタンスを更新し、最後にライターを更新します。リーダーとライターに同時にパッチを適用しないでください。パッチ中のフェイルオーバーによりダウンタイムが長くなる可能性があります。プライマリインスタンスのメンテナンスはフェイルオーバーをトリガーするため、クラスターごとに複数のインスタンスを実行して可用性を維持します。詳細については、「Amazon DocumentDB フェイルオーバー」を参照してください。
重要
Amazon DocumentDB インスタンスは OS アップグレードのためにオフラインになります。マルチインスタンスクラスターは影響を最小限に抑えます。単一インスタンスクラスターを実行する場合は、アップグレード用のセカンダリを一時的に追加し、後で削除できます。セカンダリが存在する間は、通常の料金が発生します。
注記
コンプライアンス上、オプションの更新と必要な更新を最新の状態に保つ必要がある場合があります。メンテナンスウィンドウ中に、利用可能な更新を定期的に適用します。
OS の更新は特定のエンジンバージョンとインスタンスクラスに関連付けられているため、異なるインスタンスは異なるタイミングで対象になります。インスタンスが適格である場合、更新はコンソールに表示されます。また、 コマンドまたは DescribePendingMaintenanceActions API を使用して AWS CLI describe-pending-maintenance-actions確認できます。
注記
クラスターが Amazon DocumentDB エンジンの最新パッチリリースにない場合、OS 更新が使用可能として表示されないことがあります。最新のエンジンパッチを最初に適用してから、もう一度確認してください。
更新が利用可能かどうかを確認する AWS CLI には、 AWS マネジメントコンソール または を使用します。
ユーザーが起動する更新
インスタンスクラスをメモリが多かれ少なかれあるインスタンスクラスにスワップしたり、クラスターのパラメータグループを変更したりするなど、いくつかの変更を自分で開始します。Amazon DocumentDB では、これらの処理は、開始する更新とは異なります。詳細については、以下を参照してください。
保留中のユーザー主導の変更を一覧表示するには:
例
インスタンスの保留中のユーザー主導の変更を一覧表示するには
Linux、macOS、Unix の場合:
aws docdb describe-db-instances \ --query 'DBInstances[*].[DBClusterIdentifier,DBInstanceIdentifier,PendingModifiedValues]'
Windows の場合:
aws docdb describe-db-instances ^ --query 'DBInstances[*].[DBClusterIdentifier,DBInstanceIdentifier,PendingModifiedValues]'
このオペレーションによる出力は、次のようになります (JSON 形式)。
この例では、 sample-cluster-instanceには への保留中の変更がありdb.r5.xlarge、 sample-cluster-instance-2 には何もありません。
[
[
"sample-cluster",
"sample-cluster-instance",
{
"DBInstanceClass": "db.r5.xlarge"
}
],
[
"sample-cluster",
"sample-cluster-instance-2",
{}
]
]グローバルクラスターのパッチ適用
グローバルクラスターでは、プライマリおよびセカンダリの各メンバークラスターは、独自のメンテナンスウィンドウ中にアップグレードされます。必要なエンジンパッチがすべてのリージョンで利用可能になると、AHD と E メール通知が送信されます。オプションのパッチと新しいマイナーバージョンは通知を生成しません。Amazon DocumentDB リリースノートを確認してください。
自己適用の場合は、常に最初にセカンダリにパッチを適用し、最後にプライマリにパッチを適用します。この順序により、ロールアウト全体でフェイルオーバーとスイッチオーバーが維持されます。
重要
誤って最初にプライマリにパッチを適用する場合は、すべてのセカンダリをできるだけ早く同じバージョンにします。フェイルオーバーとスイッチオーバーは、すべてのクラスターが同じバージョンになるまで無効のままになります。
アクションを実行しない場合、パッチは各クラスターの次のメンテナンスウィンドウに自動的に適用されます。最初にセカンダリ、次にセカンダリが完了した後のウィンドウでプライマリです。
プライマリ DB クラスターとセカンダリ DB クラスターを同じバージョンに保ちます。マネージドクロスリージョンフェイルオーバーは、すべてのクラスターが同じエンジンバージョンとパッチレベルを共有している場合にのみ、グローバルデータベースで機能します。プライマリよりも新しいエンジンバージョンを使用する新しいセカンダリを追加する場合も同様です。プライマリのバージョンで新しいセカンダリを作成してから、グローバルデータベースに結合します。
パッチ通知後、フェイルオーバーとスイッチオーバーが機能し続けるように、できるだけ早くプライマリとセカンダリを最新バージョンにアップグレードします。フェイルオーバーまたはスイッチオーバーリクエストが拒否された場合は、クラスター間でエンジンパッチバージョンを比較します。一致しない場合は、利用可能なパッチを遅延しているクラスターに適用します。
