翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
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 のメンテナンスアクション
Amazon DocumentDB クラスターには、次のメンテナンスアクションが適用されます。
-
system-update— Amazon DocumentDB クラスターのエンジンパッチをアップグレードします。詳細については、「Amazon DocumentDB エンジンの更新」を参照してください。 -
os-upgrade— ローリングアップグレードを使用して、Amazon DocumentDB クラスター内のすべての DB インスタンスのオペレーティングシステムを更新します。詳細については、「Amazon DocumentDB オペレーティングシステムの更新」を参照してください。
Amazon DocumentDB インスタンスには、次のメンテナンスアクションが適用されます。
-
system-update— Amazon DocumentDB インスタンスのオペレーティングシステムをアップグレードします。代わりにクラスターレベルのos-upgradeメンテナンスアクションを使用することをお勧めします。詳細については、「Amazon DocumentDB オペレーティングシステムの更新」を参照してください。
エンジンバージョンの番号付け
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 のスケジュールされた変更にあります。各通知には、パッチの可用性のタイミング、自動適用スケジュール、影響を受けるクラスター、リリースノートが一覧表示されます。
必要なエンジンパッチは、約 30 日間の 1 回のリードタイムに従います。リージョンでパッチが利用可能になると、Amazon DocumentDB は上記の通知を送信します。その時点で、パッチの AutoAppliedAfterDateは約 30 日後に に設定されます。その日まで、パッチは保留中のままになります。いつでも適用することも、クラスターのメンテナンスウィンドウを後日移動して延期することもできます。以降AutoAppliedAfterDate、パッチはクラスターの次のメンテナンスウィンドウ中に自動的に適用されます。
たとえば、2026 年 6 月 1 日に利用可能になる必須パッチには、2026 年 7 月 1 日頃AutoAppliedAfterDateの があります。通知は 2026 年 6 月 1 日に届きます。何もしないと、2026 年 7 月 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 つのグループにローリング方式でリーダーインスタンスにパッチを適用するため、残りのリーダーは引き続きトラフィックを処理します。ライターは、パッチ適用中は一時的に使用できません。読み取りのダウンタイムをゼロにするには、読み取り設定を設定して、読み取りがライター secondaryPreferredまたは primaryPreferred にフォールバックできるようにします。primaryまたは、secondary単独では読み取りのダウンタイムが発生する可能性があります。
| 読み取り設定モード | ライターのアップグレード中 | リーダーのアップグレード中 | 読み取りダウンタイムゼロに必要なリーダーの最小数 |
|---|---|---|---|
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 更新が利用可能になったらすぐに適用し、ビジネスニーズに合った時間にクラスターとインスタンスのメンテナンスウィンドウを設定します。
クラスターレベルのos-upgradeメンテナンスアクションを使用して、クラスター内のすべてのインスタンスに OS 更新を適用します。Amazon DocumentDB はインスタンスをローリング方式で一度に数回更新し、フェイルオーバーを最小限に抑えるためにプライマリインスタンスを最後に更新します。更新は、設定した個々のインスタンスのメンテナンスウィンドウではなく、クラスターのメンテナンスウィンドウ中に実行されます。
インスタンスが OS 更新を受信すると、バッファキャッシュは空で開始されます。ワーキングセットがストレージボリュームから再入力されるまで、そのインスタンスのクエリではレイテンシーが高くなり、 が低くなる可能性がありますBufferCacheHitRatio。
Amazon DocumentDB がプライマリインスタンスを更新すると、フェイルオーバーによってレプリカが新しいプライマリに昇格されます。クラスターエンドポイントを使用して、アプリケーションがこれを透過的に処理できるようにします。インスタンスの更新中に読み取りの可用性を維持するには、読み取り設定を secondaryPreferredまたは に設定primaryPreferredして、読み取りが使用可能なインスタンスにフォールバックできるようにします。潜在的なフェイルオーバーターゲット (優先度が最も高い階層のレプリカ) をプライマリと同じインスタンスクラスに維持します。これにより、昇格後の書き込みパフォーマンスの低下を回避できます。詳細については、「Amazon DocumentDB フェイルオーバー」を参照してください。
クラスターレベルのsystem-updateアクションos-upgradeとインスタンスレベルのアクションの両方が、使用可能なアクションdescribe-pending-maintenance-actionsとして に同時に表示される場合があります。ただし、両方を同時にスケジュールすることはできません。インスタンスレベルのsystem-updateアクションがいずれかのインスタンスでアクティブにスケジュールされている場合は、クラスターレベルのos-upgradeアクションをスケジュールする前にキャンセルまたは完了する必要があります。その逆も同様です。
重要
Amazon DocumentDB インスタンスは OS 更新のためにオフラインになります。マルチインスタンスクラスターは影響を最小限に抑えます。単一インスタンスクラスターを実行する場合は、更新用のセカンダリを一時的に追加し、後で削除できます。セカンダリが存在する間は、通常の料金が発生します。
注記
インスタンスレベルのsystem-updateアクションは、下位互換性のために引き続き使用できます。使用する必要がある場合は、まずレプリカを更新し、最後にプライマリを更新します。パッチ中のフェイルオーバーによりダウンタイムが長くなる可能性があるため、同時にパッチを適用しないでください。
新しいオプションの OS 更新が到着したときにイベントを取得するには、セキュリティパッチ適用イベントカテゴリRDS-EVENT-0230で をサブスクライブします。詳細については、「Amazon DocumentDB イベントにサブスクライブする」を参照してください。
注記
コンプライアンス上、オプションの更新と必要な更新を最新の状態に保つ必要がある場合があります。メンテナンスウィンドウ中にos-upgradeアクションを定期的に適用します。
OS 更新は特定のインスタンスクラスに関連付けられているため、異なるインスタンスは異なるタイミングで適格になります。クラスターが最新のエンジンパッチにない場合、OS の更新が表示されないことがあります。最新のエンジンパッチを最初に適用します (「」を参照Amazon DocumentDB エンジンの更新)。
更新が利用可能かどうかを確認する 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 クラスターを同じバージョンに保ちます。マネージドクロスリージョンフェイルオーバーは、すべてのクラスターが同じエンジンバージョンとパッチレベルを共有している場合にのみ、グローバルデータベースで機能します。プライマリよりも新しいエンジンバージョンを使用する新しいセカンダリを追加する場合も同様です。プライマリのバージョンに新しいセカンダリを作成してから、グローバルデータベースに結合します。
パッチ通知の後、フェイルオーバーとスイッチオーバーが機能し続けるように、できるだけ早くプライマリとセカンダリを最新バージョンにアップグレードします。フェイルオーバーまたはスイッチオーバーリクエストが拒否された場合は、クラスター間でエンジンパッチバージョンを比較します。一致しない場合は、利用可能なパッチを遅延しているクラスターに適用します。
