Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Gestion d'Amazon DocumentDB Amazon DocumentDB effectue régulièrement deux types de maintenance : + La **maintenance du cluster** met à jour le moteur de base de données. Les mises à jour du moteur incluent des correctifs de sécurité, des corrections de bogues, de nouvelles fonctionnalités et d'autres améliorations du moteur. + La **maintenance de l'instance** met à jour le système d'exploitation (OS) de l'instance. Les correctifs du moteur et les mises à jour du système d'exploitation utilisent les trois mêmes catégories de cycle de vie (*facultatif*, *obligatoire* et *forcé*) avec le même comportement de notification et d'application pour chaque catégorie. Les versions du moteur comportent également une quatrième catégorie : *les versions mineures*, vers lesquelles vous pouvez effectuer la mise à niveau manuellement. Les catégories sont les suivantes : + **Facultatif** : contient des améliorations non critiques. Pas de date d'application automatique ni de notification AHD ; postulez quand cela vous convient. (Pour les mises à jour du système d'exploitation, vous pouvez vous abonner `RDS-EVENT-0230` pour être averti dès qu'une mise à jour sera disponible.) + **Obligatoire** : contient des correctifs de sécurité et d'autres correctifs critiques. Vous recevez une notification par le biais du Tableau de bord Health (AHD) et par e-mail. Une action obligatoire s'applique automatiquement pendant la fenêtre de maintenance de votre cluster ou de votre instance après celle-ci`AutoAppliedAfterDate`. Vous pouvez différer en modifiant la fenêtre de maintenance avant cette date. + **Forcé** : une solution rare et extrêmement critique. Auto-applies en dehors de votre fenêtre de maintenance une fois celle-ci terminée`ForcedApplyDate`. Amazon DocumentDB désigne uniquement une action forcée lorsqu'aucune autre option n'est disponible. + **Version mineure** (versions du moteur uniquement) : version du moteur numérotée au-dessus d'une version majeure (par exemple,`5.0.1`). User-driven: vous effectuez la mise à niveau en modifiant la version du moteur du cluster. Ne s'applique jamais automatiquement ; aucune notification AHD. Les versions mineures ne sont pas publiées pour les versions majeures antérieures à 5.0. Les correctifs du moteur sont publiés dans une seule catégorie (facultatifs, obligatoires ou forcés) et restent dans cette catégorie. Progrès des mises à jour du système d'exploitation : la plupart des mises à jour sont facultatives et, si elles ne sont pas appliquées, passent à l'état obligatoire et finalement forcées. L'heure exacte dépend du correctif et est publiée dans la notification AHD et dans les champs de date renvoyés `describe-pending-maintenance-actions` (voir[Appliquer les dates](#db-instance-updates-apply-date)). Les [notes de version](https://docs.aws.amazon.com/documentdb/latest/devguide/release-notes.html) d'Amazon DocumentDB utilisent ces noms de catégories lorsqu'elles annoncent les modifications apportées au moteur. L'application d'un correctif moteur met brièvement le cluster hors ligne. Le reste de cette rubrique explique le fonctionnement des fenêtres de maintenance, comment trouver les tâches en attente, comment appliquer les correctifs du moteur et les versions mineures, comment fonctionnent les mises à jour du système d'exploitation et comment traiter les clusters globaux de manière spécifique. **Topics** + [Numérotation des versions du moteur](#engine-version-numbering) + [Gestion de vos fenêtres de maintenance Amazon DocumentDB](#maintenance-window) + [Notifications relatives aux correctifs du moteur Amazon DocumentDB](#patch-notifications) + [Affichage des actions de maintenance Amazon DocumentDB en attente](#view-pending-maintenance) + [Mises à jour du moteur Amazon DocumentDB](#db-instance-updates-apply) + [Mises à niveau de version mineure.](#minor-version-upgrades) + [Mises à jour du système d'exploitation Amazon DocumentDB](#os-system-updates) + [User-initiated mises à jour](#user-initiated-updates) + [Application de correctifs aux clusters mondiaux](#global-clusters-patching) ## Numérotation des versions du moteur Amazon DocumentDB utilise deux identifiants de version distincts : + **Version du moteur** : numéro en trois parties sous la forme `{{major}}.{{major}}.{{minor}}` (par exemple, `5.0.0` ou`5.0.1`). Les deux premières parties (`5.0`) sont la version compatible avec MongoDB ; la troisième est la version mineure, incrémentée lorsqu'Amazon DocumentDB publie une version mineure contenant des corrections de bogues et des améliorations permanentes. Il s'agit de la version que vous spécifiez lors de la création ou de la mise à niveau d'un cluster. + **Version du correctif du moteur** : numéro en trois parties distinct dans le formulaire `{{major}}.0.{{patch}}` (par exemple,`3.0.17983`) qui identifie le niveau de correctif appliqué à votre cluster. Le chiffre du milieu est toujours`0`. Les versions de correctif contiennent des correctifs de sécurité et de stabilité essentiels. Vous pouvez déterminer la version du moteur à partir du préfixe de la version du correctif du moteur, comme indiqué dans le tableau suivant. | Préfixe de version du correctif du moteur | Version du moteur Amazon DocumentDB | | --- | --- | | 1.0.{{x}} | 3.6 | | 2.0.{{x}} | 4.0 | | 3.0.{{x}} | 5.0 | | 4.0.{{x}} | 8.0 | Pour vérifier la version du correctif exécutée par votre cluster, connectez-vous et lancez-le`db.runCommand({getEngineVersion: 1})`. Pour obtenir la liste des versions de correctifs du moteur publiées et le contenu de chacune d'elles, consultez[Notes de mise à jour](release-notes.md). ## Gestion de vos fenêtres de maintenance Amazon DocumentDB Chaque cluster et chaque instance ont leur propre période de maintenance hebdomadaire de 30 minutes, période pendant laquelle les modifications planifiées et les correctifs logiciels sont exécutés. La plupart des événements se terminent en 30 minutes ; les plus importants peuvent durer plus longtemps. Si vous ne choisissez pas de fenêtre lors de la création de la ressource, Amazon DocumentDB en attribue une au hasard dans un intervalle quotidien de 8 heures défini pour la région, un jour sélectionné au hasard. Choisissez des fenêtres qui minimisent l'impact sur votre application, le soir ou le week-end, par exemple. Pour les mises à niveau du moteur de base de données, Amazon DocumentDB utilise la fenêtre du cluster, et non les fenêtres des instances individuelles. Le tableau suivant indique les plages horaires par défaut par région. | Nom de la région | Région | Bloc horaire UTC | | --- | --- | --- | | USA Est (Ohio) | us-east-2 | 3 h 00-11 h 00 | | USA Est (Virginie du Nord) | us-east-1 | 3 h 00-11 h 00 | | USA Ouest (Oregon) | us-west-2 | 6 h 00-14 h 00 | | Afrique (Le Cap) | af-south-1 | 03 H 00 — 11 H 00 | | Asie-Pacifique (Hong Kong) | ap-east-1 | 6 h 00-14 h 00 | | Asie-Pacifique (Hyderabad) | ap-south-2 | 6 H 30 — 14 H 30 | | Asie-Pacifique (Malaisie) | ap-southeast-5 | 13 h 00-21 h 00 | | Asie-Pacifique (Mumbai) | ap-south-1 | 6 h 00-14 h 00 | | Asie-Pacifique (Osaka) | ap-northeast-3 | 12h00-20h00 | | Asie-Pacifique (Séoul) | ap-northeast-2 | 13 h 00-21 h 00 | | Asie-Pacifique (Singapour) | ap-southeast-1 | 14h00-22h00 | | Asie-Pacifique (Sydney) | ap-southeast-2 | 12h00-20h00 | | Asie-Pacifique (Jakarta) | ap-southeast-3 | 08h00-16h00 | | Asie-Pacifique (Melbourne) | ap-southeast-4 | 11:00-19:00 | | Asie-Pacifique (Thaïlande) | ap-southeast-7 | 15h00-23h00 | | Asie-Pacifique (Tokyo) | ap-northeast-1 | 13 h 00-21 h 00 | | Canada (Centre) | ca-central-1 | 3 h 00-11 h 00 | | Canada-Ouest (Calgary) | ca-west-1 | 18:00-02:00 | | Chine (Beijing) | cn-north-1 | 6 h 00-14 h 00 | | Chine (Ningxia) | cn-northwest-1 | 6 h 00-14 h 00 | | Europe (Francfort) | eu-central-1 | 21 h 00 - 5 h 00 | | Europe (Zurich) | eu-central-2 | 02:00-10:00 | | Europe (Irlande) | eu-west-1 | 22 h 00-6 h 00 | | Europe (Londres) | eu-west-2 | 22 h 00-6 h 00 | | Europe (Milan) | eu-south-1 | 02:00-10:00 | | Europe (Paris) | eu-west-3 | 23:59-07:29 | | Europe (Espagne) | eu-south-2 | 02H00 — 10H00 | | Europe (Stockholm) | eu-north-1 | 04 H 00 — 12 H 00 | | Mexique (Centre) | mx-central-1 | 3 h 00-11 h 00 | | Moyen-Orient (EAU) | me-central-1 | 05 H 00 — 13 H 00 | | Amérique du Sud (São Paulo) | sa-east-1 | 00:00-08:00 | | Israël (Tel Aviv) | il-central-1 | 04h00-12h00 | | AWS GovCloud (US-East) | us-gov-east-1 | 17:00-01:00 | | AWS GovCloud (US-West) | us-gov-west-1 | 6 h 00-14 h 00 | ### Modification de vos fenêtres de maintenance Amazon DocumentDB Choisissez la fenêtre la moins fréquentée possible et ajustez-la au fil du temps en fonction de l'évolution de vos habitudes de trafic. Le cluster ou l'instance n'est pas disponible pendant la fenêtre uniquement si une modification du système (opération de stockage à grande échelle ou modification de classe d'instance, par exemple) nécessite une panne, et uniquement pendant la durée réellement nécessaire à cette modification. **Pour modifier la fenêtre de maintenance** + Pour un cluster, veuillez consulter [Modification d'un cluster Amazon DocumentDB](db-cluster-modify.md). + Pour une instance, veuillez consulter [Modification d'une instance Amazon DocumentDB](db-instance-modify.md). ## Notifications relatives aux correctifs du moteur Amazon DocumentDB Lorsqu'un correctif moteur *requis* est disponible dans une AWS région, chaque AWS compte associé à un cluster Amazon DocumentDB concerné dans cette région reçoit une notification par le biais du Tableau de bord Health (AHD) et par e-mail (envoyée à l'adresse utilisateur racine du AWS compte). Une notification est envoyée par version du moteur Amazon DocumentDB concernée. Vous pouvez les trouver sous **Modifications planifiées** dans l'AHD. Chaque notification indique le calendrier de disponibilité des correctifs, le calendrier d'application automatique, les clusters concernés et les notes de publication. ![La console Amazon DocumentDB affiche l'onglet Modifications planifiées pour les mises à niveau des correctifs du moteur.](http://docs.aws.amazon.com/fr_fr/documentdb/latest/devguide/images/scheduled-changes.png) Les notifications sont envoyées environ deux jours avant l'ouverture de la fenêtre d'application automatique. Par exemple, un correctif obligatoire publié le lundi à 00h00 UTC peut être appliqué automatiquement le mercredi à 00h00 UTC. Si la fenêtre de maintenance de votre cluster est le mercredi à 12 h UTC, le correctif s'applique automatiquement ce mercredi, soit environ 12 heures après l'ouverture de la fenêtre d'application automatique. Si votre fenêtre de maintenance est le mardi à 12h00 UTC, le correctif attend une semaine complète avant de s'appliquer automatiquement. Après avoir reçu la notification, deux options s'offrent à vous : appliquer automatiquement le correctif avant la date d'application automatique ou attendre qu'il s'applique automatiquement lors d'une prochaine période de maintenance (par défaut). Pour vous auto-appliquer, ouvrez l'onglet **Maintenance et sauvegardes** du cluster et recherchez le type `system-update` d'entrée. **Note** L'**état** de la notification dans l'AHD reste **en cours** jusqu'à ce qu'Amazon DocumentDB publie un autre correctif moteur avec une nouvelle version du correctif. Une fois le correctif appliqué, la version du correctif du moteur du cluster est mise à jour pour correspondre à la version indiquée dans la notification. Vérifiez la nouvelle version en exécutant`db.runCommand({getEngineVersion: 1})`. Les correctifs facultatifs et les nouvelles versions mineures ne génèrent pas de notifications AHD ni de notifications par e-mail. Pour les suivre, consultez les notes de [mise](https://docs.aws.amazon.com/documentdb/latest/devguide/release-notes.html) à jour d'Amazon DocumentDB. Les correctifs forcés (la catégorie la plus rare, réservée aux correctifs de sécurité les plus critiques) sont également annoncés via AHD et par e-mail. Contrairement aux correctifs obligatoires, ils s'appliquent en dehors de votre période de maintenance, de sorte que l'exemple de calendrier d'application automatique ci-dessus ne s'applique pas. ### Réagir aux notifications de correctifs de manière programmatique AWS Health s'intègre à Amazon EventBridge, qui vous permet de créer des applications axées sur les événements sur plus de 20 cibles, dont AWS Lambda Amazon Simple Queue Service (SQS). Pour réagir à la disponibilité des correctifs du moteur de manière programmatique, configurez EventBridge en fonction de cet événement. `AWS_DOCDB_DB_PATCH_UPGRADE_MAINTENANCE_SCHEDULED` À partir de là, vous pouvez capturer des données sur les événements, créer des événements supplémentaires, envoyer des notifications push via le AWS Console Mobile Application ou prendre toute autre action dont vous avez besoin. Si Amazon DocumentDB annule un correctif (rare), vous recevez une notification AHD et un e-mail concernant l'annulation. Utilisez le code `AWS_DOCDB_DB_PATCH_UPGRADE_MAINTENANCE_CANCELLED` d'événement associé EventBridge à Amazon pour traiter ce cas. Pour en savoir plus sur les règles de rédaction, consultez le [guide de EventBridge l'utilisateur Amazon](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rules.html). ## Affichage des actions de maintenance Amazon DocumentDB en attente Utilisez le AWS Management Console ou le AWS CLI pour vérifier quelle maintenance est en attente pour un cluster ou une instance. Les mises à jour en attente apparaissent avec le type d'action`system-update`, qui couvre à la fois les correctifs du moteur et les mises à jour du système d'exploitation. Lorsqu'une mise à jour est en attente, vous pouvez : + Appliquez-le immédiatement. + Programmez-le pour la prochaine fenêtre de maintenance. + Différez-la (correctifs du moteur et mises à jour du système d'exploitation uniquement) en modifiant votre fenêtre de maintenance au préalable`AutoAppliedAfterDate`. Une fois cette date passée, l'action s'appliquera automatiquement lors de la prochaine fenêtre de maintenance. Une `ForcedApplyDate` fois passé, aucun autre report n'est possible. **Note** Si vous ne prenez aucune mesure, les actions de maintenance requises, telles que les correctifs moteur requis, s'appliquent automatiquement lors d'une prochaine fenêtre de maintenance. Les correctifs facultatifs et les versions mineures ne s'appliquent jamais automatiquement. La fenêtre de maintenance contrôle le moment où les opérations en attente *commencent*, et non le temps qu'elles prennent pour se terminer. ------ #### [ Using the AWS Management Console ] 1. Connectez-vous à la AWS Management Console console Amazon DocumentDB et ouvrez-la à l'adresse. [https://console.aws.amazon.com/docdb](https://console.aws.amazon.com/docdb) 1. Dans le panneau de navigation, choisissez **Clusters**. 1. La colonne **Maintenance** du cluster indique **Disponible**, **Obligatoire** ou **Fenêtre suivante** lorsqu'une mise à jour est en attente. ![La console Amazon DocumentDB affiche la colonne Maintenance pour les clusters.](http://docs.aws.amazon.com/fr_fr/documentdb/latest/devguide/images/db-cluster-maintenance-updates-status.png) 1. Ouvrez le cluster, puis choisissez **Maintenance et sauvegardes** pour voir les éléments de **maintenance en attente** et agir en conséquence. ![La console Amazon DocumentDB affiche la fenêtre de maintenance du cluster.](http://docs.aws.amazon.com/fr_fr/documentdb/latest/devguide/images/cluster-maint-3.png) ------ #### [ Using the AWS CLI ] Courez `describe-pending-maintenance-actions` pour voir ce qui est en attente. L'exemple suivant montre un compte sans actions en attente. ``` aws docdb describe-pending-maintenance-actions ``` La sortie de cette opération ressemble à ceci (format JSON). ``` { "PendingMaintenanceActions": [] } ``` Un compte dont une action est en attente renvoie un résultat qui ressemble à ceci : ``` { "PendingMaintenanceActions": [ { "ResourceIdentifier": "arn:aws:rds:us-east-1:123456789012:cluster:sample-cluster", "PendingMaintenanceActionDetails": [ { "Action": "system-update", "Description": "db-version-upgrade", "CurrentApplyDate": "2026-05-15T03:01:00Z", "AutoAppliedAfterDate": "2026-05-15T03:01:00Z" } ] } ] } ``` Vous pouvez étendre la liste à des clusters spécifiques avec`--filters`, dans le formulaire`Name={{filter-name}},Values={{resource-id}},...`. Le filtre accepté `Name` est`db-cluster-id`, qui prend une liste d'identifiants de cluster ou d'ARN. **Example** Pour Linux, macOS ou Unix : ``` aws docdb describe-pending-maintenance-actions \ --filters Name=db-cluster-id,Values={{sample-cluster1}},{{sample-cluster2}} ``` Pour Windows : ``` aws docdb describe-pending-maintenance-actions ^ --filters Name=db-cluster-id,Values={{sample-cluster1}},{{sample-cluster2}} ``` ------ ### Appliquer les dates Chaque action de maintenance en attente comporte jusqu'à trois dates d'application. Ils apparaissent dans la AWS CLI sortie pour `describe-pending-maintenance-actions` et indiquent quand l'action sera exécutée. Les champs sont `null` destinés à une maintenance facultative. + **CurrentApplyDate**—lorsque l'exécution de l'action est planifiée, soit maintenant, soit lors de la prochaine fenêtre de maintenance. Rempli pour les actions obligatoires et forcées. + **AutoAppliedAfterDate**: la date à partir de laquelle l'application automatique commence pendant la fenêtre de maintenance du cluster ou de l'instance. Rempli pour les actions requises. + **ForcedApplyDate**—le délai strict. Après cette date, l'action s'exécute automatiquement, quel que soit votre créneau de maintenance. Peuplé pour les actions forcées. Pour reporter une action en attente, reportez votre fenêtre de maintenance à une date ultérieure la veille`AutoAppliedAfterDate`. Une fois `AutoAppliedAfterDate` passée, l'action s'appliquera automatiquement lors de la fenêtre de maintenance suivante. Une `ForcedApplyDate` fois passé, aucun autre report n'est possible. La fenêtre de report exacte varie en fonction du correctif ; les dates sont publiées dans la notification AHD et dans le AWS CLI résultat. ## Mises à jour du moteur Amazon DocumentDB Lorsque vous avez identifié un correctif moteur en attente, utilisez l'une des procédures suivantes pour l'appliquer ou le planifier. Vous pouvez exécuter ces procédures à partir du AWS Management Console ou du AWS CLI. ------ #### [ Using the AWS Management Console ] **Pour gérer une mise à jour pour un cluster** 1. Connectez-vous à la AWS Management Console console Amazon DocumentDB et ouvrez-la à l'adresse. [https://console.aws.amazon.com/docdb](https://console.aws.amazon.com/docdb) 1. Dans le panneau de navigation, choisissez **Clusters**. 1. Sélectionnez le cluster que vous souhaitez mettre à jour. 1. Dans le menu **Actions**, choisissez l'une des options suivantes : + Effectuez la **mise à niveau maintenant** : exécutez immédiatement la maintenance en attente. + **Effectuez la mise à niveau à la fenêtre suivante** : exécutez-la lors de la fenêtre de maintenance suivante du cluster. Vous pouvez également utiliser **Appliquer maintenant** ou **Appliquer à la fenêtre de maintenance suivante** dans la section **Maintenance en attente** de l'onglet **Maintenance et sauvegardes** du cluster (voir[Affichage des actions de maintenance Amazon DocumentDB en attente](#view-pending-maintenance)). **Note** Si rien n'est en attente, toutes ces options sont inactives. ------ #### [ Using the AWS CLI ] Appliquez une mise à jour en attente avec`apply-pending-maintenance-action`. **Parameters** + **--resource-identifier**—le nom de ressource Amazon DocumentDB (ARN) Amazon DocumentDB de la ressource ciblée par l'action en attente. + **--apply-action**—l'action de maintenance en attente à appliquer. Valeurs valides : `system-update`, `db-upgrade`. + **--opt-in-type**: le type de demande d'adhésion, ou s'il faut en annuler une. Valeurs valides : + `immediate`—postulez dès maintenant. Ne peut pas être annulé une fois soumis. + `next-maintenance`: s'appliquent lors de la prochaine fenêtre de maintenance de la ressource. + `undo-opt-in`—annuler un `next-maintenance` opt-in existant. **Example** Pour Linux, macOS ou Unix : ``` aws docdb apply-pending-maintenance-action \ --resource-identifier arn:aws:rds:us-east-1:{{123456789012}}:db:{{sample-cluster-instance-1}} \ --apply-action system-update \ --opt-in-type immediate ``` Pour Windows : ``` aws docdb apply-pending-maintenance-action ^ --resource-identifier arn:aws:rds:us-east-1:{{123456789012}}:db:{{sample-cluster-instance-1}} ^ --apply-action system-update ^ --opt-in-type immediate ``` ------ ### Consultez la disponibilité lors de l'application des correctifs Les moteurs Amazon DocumentDB 5.0 et 8.0 préservent la disponibilité en lecture lors de l'application de correctifs lorsque le cluster possède plusieurs instances. Amazon DocumentDB corrige les instances des lecteurs de manière continue, en trois groupes, afin que les autres lecteurs continuent à gérer le trafic. Le rédacteur est brièvement indisponible pendant la mise à jour. Pour éviter toute interruption de lecture, définissez vos préférences de lecture de manière à ce que les lectures puissent être confiées à l'auteur, `secondaryPreferred` soit `primaryPreferred` fonctionner, `primary` soit entraîner une interruption de lecture à `secondary` elles seules. | Mode de préférence de lecture | Pendant la mise à niveau du grav | Pendant la mise à niveau du lecteur | Nombre minimum de lecteurs nécessaires pour éviter toute interruption de lecture | | --- | --- | --- | --- | | primary | Read/write temps d'arrêt | Aucun impact | N/A | | primaryPreferred | Temps d'arrêt d'écriture | Aucun impact | 1 | | secondary | Temps d'arrêt d'écriture | Interruption de lecture (s'il n'y a qu'un seul lecteur) | 2 | | secondaryPreferred | Temps d'arrêt d'écriture | Aucun impact | 1 | | nearest | Temps d'arrêt d'écriture | Aucun impact | 1 | Pendant que les lecteurs appliquent des correctifs, le débit de lecture global du cluster diminue temporairement. Pour maintenir un débit stable, configurez des lecteurs supplémentaires avant la mise à niveau et retirez-les une fois celle-ci terminée. Sur les moteurs 3.6 et 4.0, ces fonctionnalités de disponibilité en lecture ne s'appliquent pas : un correctif du moteur entraîne des temps d'arrêt plus longs qui affectent à la fois les lectures et les écritures. Pour effectuer une mise à niveau vers une version majeure qui le fait, voir[Mise à niveau sur place de la version majeure d'Amazon DocumentDB](docdb-mvu.md). ### Durée d'indisponibilité des correctifs Engine-patch les temps d'arrêt varient. Les facteurs les plus importants sont l'utilisation du processeur et la pression de la mémoire sur l'instance au moment du correctif. Il est donc important de bien dimensionner vos instances. Pour minimiser les temps d'arrêt, exécutez la dernière version majeure du moteur Amazon DocumentDB et répartissez les instances sur plusieurs zones de disponibilité. ### Mises à jour et remplacements de correctifs Amazon DocumentDB surveille les correctifs après leur publication. Dans les rares cas où un problème est identifié, Amazon DocumentDB suspend le déploiement pendant qu'il prépare une version mise à jour. Dans ce cas, les clusters qui n'ont pas encore reçu le correctif ne le considèrent plus comme une action de maintenance disponible et la notification de modification planifiée correspondante est supprimée. Tableau de bord Health Les clusters exécutant déjà la version affectée continuent de fonctionner normalement et ne nécessitent aucune action de votre part. Un correctif mis à jour suivra sous peu. Lorsqu'il sera disponible dans votre région, vous recevrez une nouvelle notification par e-mail, comme décrit dans[Notifications relatives aux correctifs du moteur Amazon DocumentDB](#patch-notifications). Tableau de bord Health ## Mises à niveau de version mineure. Amazon DocumentDB publie des versions mineures en plus de la version majeure 5.0 et des versions ultérieures (par exemple,`5.0.1`). Les versions mineures ne sont pas publiées pour les versions majeures antérieures à 5.0. Les versions mineures se comportent différemment des correctifs de moteur obligatoires et facultatifs : + Ils n'apparaissent pas comme une action de maintenance en attente et ne s'appliquent jamais automatiquement. + Ils ne génèrent pas d'AHD ni de notifications par e-mail. Les nouvelles versions mineures sont annoncées dans les notes de [publication](https://docs.aws.amazon.com/documentdb/latest/devguide/release-notes.html) d'Amazon DocumentDB. + Pour effectuer la mise à niveau, vous modifiez la version du moteur du cluster (immédiatement ou lors de la fenêtre de maintenance suivante). Les mises à niveau des versions mineures nécessitent de brèves interruptions de service et sont unidirectionnelles : vous ne pouvez pas rétrograder vers une version mineure antérieure. Pour les clusters globaux, mettez à niveau les clusters secondaires avant les clusters principaux. En savoir plus :[Mise à niveau de la version mineure d'Amazon DocumentDB](docdb-minor-version-upgrade.md). ## Mises à jour du système d'exploitation Amazon DocumentDB Les instances nécessitent parfois des mises à jour du système d'exploitation. Amazon DocumentDB met à jour le système d'exploitation pour améliorer les performances et renforcer la sécurité. Les mises à jour du système d'exploitation laissent la version du moteur de cluster et la classe d'instance inchangées. À l'instar des correctifs de moteur, les mises à jour du système d'exploitation utilisent le cycle de vie optionnel, obligatoire ou forcé décrit en haut de cette rubrique ; contrairement aux correctifs du moteur, une mise à jour du système d'exploitation peut passer d'une catégorie à l'autre au fil du temps si vous la reportez. Appliquez les mises à jour du système d'exploitation dès qu'elles sont disponibles et définissez la période de maintenance de votre instance à une date adaptée à votre entreprise. Pour obtenir un événement lors de l'arrivée d'une nouvelle mise à jour facultative, abonnez-vous `RDS-EVENT-0230` à la catégorie des événements relatifs aux correctifs de sécurité. Pour plus de détails, consultez la section [Abonnement aux abonnements aux événements Amazon DocumentDB.](https://docs.aws.amazon.com/documentdb/latest/devguide/event-subscriptions.subscribe.html) Après avoir reçu une notification, vous pouvez appliquer automatiquement le correctif du système d'exploitation à chaque instance. Lorsque vous appliquez des correctifs à un cluster, mettez à jour les instances du lecteur en premier et celles du rédacteur en dernier. Évitez d'appliquer des correctifs aux lecteurs et au rédacteur en même temps, car un basculement pendant le correctif peut prolonger le temps d'arrêt. La maintenance de l'instance principale déclenche un basculement. Par conséquent, exécutez plusieurs instances par cluster pour rester disponible. Pour en savoir plus, consultez [Basculement d'Amazon DocumentDB](failover.md). **Important** Votre instance Amazon DocumentDB est mise hors ligne pour la mise à niveau du système d'exploitation. Multi-instance les clusters minimisent l'impact. Si vous exécutez un cluster à instance unique, vous pouvez ajouter temporairement un cluster secondaire pour la mise à niveau et le supprimer ensuite. Le secondaire encourt les frais habituels tant qu'il existe. **Note** Pour des raisons de conformité, il peut être nécessaire de se tenir au courant des mises à jour facultatives et obligatoires. Appliquez régulièrement les mises à jour disponibles pendant vos fenêtres de maintenance. Les mises à jour du système d'exploitation sont liées à des versions de moteur et à des classes d'instances spécifiques, de sorte que différentes instances deviennent éligibles à des moments différents. Lorsqu'une instance est éligible, la mise à jour apparaît dans la console ; vous pouvez également la voir via la AWS CLI `describe-pending-maintenance-actions` commande ou l'`DescribePendingMaintenanceActions`API. **Note** Si votre cluster ne dispose pas de la dernière version de correctif de son moteur Amazon DocumentDB, il se peut qu'une mise à jour du système d'exploitation ne soit pas disponible. Appliquez d'abord le dernier correctif moteur, puis vérifiez à nouveau. Utilisez le AWS Management Console ou AWS CLI pour vérifier si une mise à jour est disponible. ------ #### [ Using the AWS Management Console ] Pour vérifier l'existence d'une mise à jour du système d'exploitation depuis la console : 1. Connectez-vous à la AWS Management Console console Amazon DocumentDB et ouvrez-la à l'adresse. [https://console.aws.amazon.com/docdb](https://console.aws.amazon.com/docdb) 1. Dans le panneau de navigation, choisissez **Clusters**. La liste affiche à la fois les clusters et les instances qu'ils contiennent, distingués par la colonne **Rôle**. 1. Sélectionnez la ligne dont le **rôle** est **Instance** (et non la ligne du cluster). Les mises à jour du système d'exploitation s'appliquent aux instances et non aux clusters. 1. Choisissez **Maintenance**. 1. Consultez la section **Maintenance en attente** pour la mise à jour du système d'exploitation. ![La console Amazon DocumentDB affiche la colonne Maintenance pour les clusters.](http://docs.aws.amazon.com/fr_fr/documentdb/latest/devguide/images/maintenance-available-1.png) **Dans la section Maintenance en attente**, sélectionnez la mise à jour du système d'exploitation et choisissez **Appliquer maintenant** ou **Appliquer à la fenêtre de maintenance suivante**. Si la valeur de maintenance est la **fenêtre suivante**, vous pouvez différer la mise à jour avec **Defer upgrade** tant qu'elle n'a pas encore commencé. Vous pouvez également le faire à partir de la liste des **clusters : dans le volet de navigation, choisissez Clusters**, sélectionnez la ligne dont le **rôle** est **Instance**, puis choisissez **Appliquer maintenant** ou **Appliquer à la prochaine fenêtre de maintenance** dans le menu **Actions**. ------ #### [ Using the AWS CLI ] À partir du AWS CLI, exécutez `describe-pending-maintenance-actions` : ``` aws docdb describe-pending-maintenance-actions ``` ``` { "PendingMaintenanceActions": [ { "ResourceIdentifier": "arn:aws:rds:us-east-1:123456789012:db:sample-cluster-instance-1", "PendingMaintenanceActionDetails": [ { "Action": "system-update", "Description": "New Operating System update is available" } ] } ] } ``` ------ ## User-initiated mises à jour Vous pouvez effectuer certaines modifications vous-même, par exemple en remplaçant une classe d'instance par une classe avec plus ou moins de mémoire, ou en modifiant le groupe de paramètres du cluster. Amazon DocumentDB les traite différemment des mises à jour qu'il initie. Pour plus d’informations, voir : + [Modification d'un cluster Amazon DocumentDB](db-cluster-modify.md) + [Modification d'une instance Amazon DocumentDB](db-instance-modify.md) Pour répertorier les modifications initiées par l'utilisateur qui sont toujours en attente : **Example** **Pour répertorier les modifications en attente initiées par l'utilisateur pour vos instances** Pour Linux, macOS ou Unix : ``` aws docdb describe-db-instances \ --query 'DBInstances[*].[DBClusterIdentifier,DBInstanceIdentifier,PendingModifiedValues]' ``` Pour Windows : ``` aws docdb describe-db-instances ^ --query 'DBInstances[*].[DBClusterIdentifier,DBInstanceIdentifier,PendingModifiedValues]' ``` La sortie de cette opération ressemble à ceci (format JSON). Dans cet exemple, une modification `sample-cluster-instance` est en attente de `db.r5.xlarge` ; n'en `sample-cluster-instance-2` a aucune. ``` [ [ "sample-cluster", "sample-cluster-instance", { "DBInstanceClass": "db.r5.xlarge" } ], [ "sample-cluster", "sample-cluster-instance-2", {} ] ] ``` ## Application de correctifs aux clusters mondiaux Dans un cluster global, chaque cluster membre (principal et secondaire) est mis à niveau au cours de sa propre fenêtre de maintenance. Lorsqu'un correctif moteur requis est disponible dans chaque région, vous recevez un AHD et une notification par e-mail. Les correctifs facultatifs et les nouvelles versions mineures ne génèrent pas de notifications ; consultez les [notes de publication d'Amazon DocumentDB pour les connaître](https://docs.aws.amazon.com/documentdb/latest/devguide/release-notes.html). Si vous postulez vous-même, appliquez toujours le correctif secondaire en premier et le correctif principal en dernier. Cette commande permet de maintenir le basculement et le basculement disponibles tout au long du déploiement. **Important** Si vous patchez la première version par erreur, installez la même version sur toutes les versions secondaires dès que possible. Le basculement et le basculement restent désactivés jusqu'à ce que chaque cluster utilise la même version. Si vous n'effectuez aucune action, le correctif s'applique automatiquement lors de la fenêtre de maintenance suivante de chaque cluster : les secondaires d'abord, puis le correctif principal à sa fenêtre une fois les secondaires terminés. Conservez les clusters de base de données principal et secondaire sur la même version. Le basculement interrégional géré ne fonctionne sur une base de données globale que lorsque chaque cluster partage la même version de moteur et le même niveau de correctif. Il en va de même si vous ajoutez un nouveau secondaire qui utilise une version du moteur plus récente que le principal : créez de nouveaux secondaires sur la version du moteur principal avant de les joindre à la base de données globale. Après avoir reçu une notification de correctif, effectuez la mise à niveau des versions principale et secondaire vers la dernière version dès que possible afin de garantir le bon fonctionnement du basculement et du basculement. Si une demande de basculement ou de basculement est rejetée, comparez les versions du correctif du moteur entre les clusters ; si elles ne correspondent pas, appliquez le correctif disponible sur les clusters en retard.