Gestion d'Amazon DocumentDB

Amazon DocumentDB effectue régulièrement deux types de maintenance :

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 les mêmes notifications et le même comportement 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 une mise à niveau manuellement. Les catégories sont les suivantes :

Les correctifs du moteur sont publiés dans une seule catégorie (facultatifs, obligatoires ou obligatoires) et y restent. Progression des mises à jour du système d'exploitation : la plupart commencent comme facultatives et, si elles ne sont pas appliquées, passent à obligatoires puis forcées. Le calendrier exact dépend du correctif et est publié dans la notification AHD et dans les champs de date renvoyés par describe-pending-maintenance-actions (voirDates d'application). Les notes de mise à jour d'Amazon DocumentDB utilisent ces noms de catégories lorsqu'elles annoncent des modifications apportées au moteur.

L'application d'un correctif de moteur met brièvement le cluster hors ligne. La suite de cette rubrique explique le fonctionnement des fenêtres de maintenance, la recherche des tâches en attente, l'application de correctifs de moteur et de versions mineures, le fonctionnement des mises à jour du système d'exploitation et la gestion spéciale des clusters globaux.

Actions de maintenance pour Amazon DocumentDB

Les actions de maintenance suivantes s'appliquent aux clusters Amazon DocumentDB :

Les actions de maintenance suivantes s'appliquent aux instances Amazon DocumentDB :

Numérotation des versions du moteur

Amazon DocumentDB utilise deux identifiants de version distincts :

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.

Pour vérifier la version du correctif exécutée par votre cluster, connectez-vous et exécutezdb.runCommand({getEngineVersion: 1}).

Pour la liste des versions de correctifs du moteur publiées et le contenu de chacune d'elles, consultezNotes de mise à jour.

Gestion de vos fenêtres de maintenance Amazon DocumentDB

Chaque cluster et chaque instance disposent de leur propre fenêtre 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 aucune fenêtre lors de la création de la ressource, Amazon DocumentDB en attribue une au hasard dans un bloc quotidien de 8 heures défini pour la région, un jour sélectionné de manière aléatoire. 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 blocs horaires par défaut par région.

Modifier 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 votre trafic. Le cluster ou l'instance n'est pas disponible pendant la fenêtre uniquement si une modification du système (une opération de stockage à grande échelle ou un changement de classe d'instance, par exemple) nécessite une interruption, et uniquement aussi longtemps que cette modification est réellement nécessaire.

Notifications relatives aux correctifs du moteur Amazon DocumentDB

Lorsqu'un correctif moteur requis est disponible dans une AWS région, chaque AWS compte comportant un cluster Amazon DocumentDB concerné dans cette région reçoit une notification via le Tableau de bord Health (AHD) et par e-mail (envoyée à l'adresse utilisateur root du AWS compte). Une notification est envoyée par version du moteur Amazon DocumentDB concernée. Vous pouvez les trouver dans la section Changements planifiés de l'AHD. Chaque notification répertorie le calendrier de disponibilité des correctifs, le calendrier d'application automatique, les clusters concernés et les notes de version.

Les correctifs requis pour le moteur sont effectués dans un délai unique d'environ 30 jours. Lorsqu'un correctif est disponible dans votre région, Amazon DocumentDB envoie la notification décrite ci-dessus. À ce stade, le patch AutoAppliedAfterDate est réglé sur environ 30 jours plus tard. Jusqu'à cette date, le correctif reste en attente : vous pouvez l'appliquer à tout moment, ou le reporter en reportant la fenêtre de maintenance de votre cluster à une date ultérieure. À compter duAutoAppliedAfterDate, le correctif s'applique automatiquement lors de la prochaine fenêtre de maintenance du cluster.

Par exemple, un correctif requis qui devient disponible le 1er juin 2026 a une date approximative AutoAppliedAfterDate du 1er juillet 2026. Vous recevez la notification le 1er juin 2026, et si vous ne prenez aucune mesure, le correctif s'applique automatiquement lors de la première fenêtre de maintenance de votre cluster à compter du 1er juillet 2026.

Après avoir reçu la notification, deux options s'offrent à vous : appliquer vous-même le correctif avant la date d'application automatique ou attendre qu'il s'applique automatiquement lors d'une prochaine fenêtre de maintenance (par défaut). Pour vous inscrire vous-même, ouvrez l'onglet Maintenance et sauvegardes du cluster et recherchez l'entrée de typesystem-update.

Les correctifs optionnels et les nouvelles versions mineures ne génèrent pas de notifications AHD ou par e-mail. Pour les suivre, consultez les notes de publication 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 fenêtre de maintenance. L'exemple de synchronisation d'application automatique ci-dessus ne s'applique donc pas.

Réagir aux notifications de correctifs par programmation

AWS Health s'intègre à Amazon EventBridge, qui vous permet de créer des applications pilotées par des événements sur plus de 20 cibles, y compris AWS Lambda Amazon Simple Queue Service (SQS). Pour réagir par programmation à la disponibilité des correctifs du moteur, configurez EventBridge en fonction de l'événement. AWS_DOCDB_DB_PATCH_UPGRADE_MAINTENANCE_SCHEDULED À partir de là, vous pouvez capturer les données des é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 de l'AWS_DOCDB_DB_PATCH_UPGRADE_MAINTENANCE_CANCELLEDévénement avec Amazon EventBridge pour gérer ce cas. Pour en savoir plus sur la rédaction de règles, consultez le guide de EventBridge l'utilisateur Amazon.

Affichage des actions de maintenance Amazon DocumentDB en attente

Utilisez le Console de gestion AWS ou 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'actionsystem-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 :

La fenêtre de maintenance contrôle le moment où les opérations en attente démarrent, et non leur durée.

Dates d'application

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 réservés null à la maintenance facultative.

Pour reporter une action en attente, reportez votre fenêtre de maintenance à la veilleAutoAppliedAfterDate. Une fois AutoAppliedAfterDate terminée, l'action s'appliquera automatiquement lors de la prochaine fenêtre de maintenance. Une ForcedApplyDate fois passé, aucun autre report n'est possible. La fenêtre de report exacte varie d'un patch à l'autre ; 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, appliquez l'une des procédures suivantes pour l'appliquer ou le planifier. Vous pouvez exécuter ces procédures à partir du Console de gestion AWS ou du AWS CLI.

Disponibilité de la lecture pendant 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 comporte plusieurs instances. Amazon DocumentDB corrige les instances de lecteurs de manière continue, en trois groupes, afin que les lecteurs restants continuent à gérer le trafic. L'enregistreur est momentanément indisponible pendant la mise à jour. Pour éviter tout temps d'arrêt de lecture, définissez vos préférences de lecture de manière à ce que les lectures puissent être confiées à l'auteur : secondaryPreferred ou primaryPreferred fonctionnent ; primary ou secondary seules, cela peut entraîner une interruption de lecture.

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 supprimez-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 moteur entraîne une interruption plus longue qui affecte à la fois les lectures et les écritures. Pour passer à une version majeure qui le fasse, consultezMise à niveau de la version majeure d'Amazon DocumentDB sur place.

Durée d'indisponibilité des correctifs

Engine-patch les temps d'arrêt varient. Les principaux facteurs sont l'utilisation du processeur et la pression de la mémoire sur l'instance au moment de la mise à jour. Il est donc important de dimensionner correctement vos instances. Pour minimiser les temps d'arrêt, exécutez la dernière version du moteur principal d'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 interrompt 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 programmée correspondante dans le est supprimée. Tableau de bord Health Les clusters qui exécutent déjà la version concernée continuent de fonctionner normalement et ne nécessitent aucune action de votre part.

Une mise à jour sera bientôt disponible. Lorsqu'il sera disponible dans votre région, vous recevrez une nouvelle notification par e-mail, comme décrit dansNotifications relatives aux correctifs du moteur Amazon DocumentDB. 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 à la version 5.0. Les versions mineures se comportent différemment des correctifs de moteur requis et optionnels :

En savoir plus :Mise à niveau de la version mineure d'Amazon DocumentDB.

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 ; à la différence des 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 les fenêtres de maintenance de votre cluster et de votre instance à des horaires adaptés aux besoins de votre entreprise.

Utilisez l'action de os-upgrade maintenance au niveau du cluster pour appliquer les mises à jour du système d'exploitation à toutes les instances d'un cluster. Amazon DocumentDB met à jour les instances de manière continue, quelques-unes à la fois, et met à jour l'instance principale en dernier afin de minimiser les basculements. La mise à jour s'exécute pendant la fenêtre de maintenance du cluster, et non pendant la fenêtre de maintenance de chaque instance, que vous configurez.

Une fois qu'une instance reçoit une mise à jour du système d'exploitation, sa mémoire tampon commence à être vide. Tant que l'ensemble de travail n'est pas repeuplé à partir du volume de stockage, les requêtes sur cette instance peuvent connaître une latence plus élevée et une plus faibleBufferCacheHitRatio.

Lorsqu'Amazon DocumentDB met à jour l'instance principale, un basculement fait d'une réplique la nouvelle instance principale. Utilisez le point de terminaison du cluster pour que votre application gère cela de manière transparente. Pour maintenir la disponibilité en lecture pendant la mise à jour des instances, définissez vos préférences de lecture sur secondaryPreferred ou de primaryPreferred manière à ce que les lectures puissent revenir à une instance disponible. Conservez les cibles de basculement potentielles (répliques avec le niveau de priorité le plus élevé) dans la même classe d'instance que la classe d'instance principale. Cela permet d'éviter une dégradation des performances d'écriture après la promotion. Pour en savoir plus, consultez Basculement d'Amazon DocumentDB.

Les actions au niveau du cluster os-upgrade et au niveau de l'instance peuvent apparaître simultanément dans system-update les actions disponibles. describe-pending-maintenance-actions Cependant, vous ne pouvez pas programmer les deux en même temps. Si des system-update actions au niveau de l'instance sont planifiées activement sur une instance, vous devez les annuler ou les terminer avant de planifier l'os-upgradeaction au niveau du cluster, et vice versa.

Pour recevoir un événement lors de l'arrivée d'une nouvelle mise à jour optionnelle du système d'exploitation, inscrivez-vous RDS-EVENT-0230 dans la catégorie Événement d'application de correctifs de sécurité. Pour de plus amples informations, veuillez consulter Abonnement aux événements Amazon DocumentDB.

Les mises à jour du système d'exploitation sont liées à des classes d'instances spécifiques, de sorte que différentes instances deviennent éligibles à des moments différents. Si votre cluster n'utilise pas le dernier correctif moteur, la mise à jour du système d'exploitation risque de ne pas apparaître. Appliquez d'abord le dernier correctif moteur (voirMises à jour du moteur Amazon DocumentDB).

Utilisez le Console de gestion AWS ou AWS CLI pour vérifier si une mise à jour est disponible.

User-initiated mises à jour

Vous pouvez effectuer certaines modifications vous-même, par exemple, remplacer une classe d'instance par une classe avec plus ou moins de mémoire, ou modifier le groupe de paramètres du cluster. Amazon DocumentDB les traite différemment des mises à jour qu'il initie. Pour plus d’informations, voir :

Pour répertorier les modifications initiées par l'utilisateur qui sont toujours en attente :

aws docdb describe-db-instances \
    --query 'DBInstances[*].[DBClusterIdentifier,DBInstanceIdentifier,PendingModifiedValues]'

aws docdb describe-db-instances ^
    --query 'DBInstances[*].[DBClusterIdentifier,DBInstanceIdentifier,PendingModifiedValues]'

[
    [
        "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 une notification AHD et par e-mail. Les correctifs facultatifs et les nouvelles versions mineures ne génèrent pas de notifications ; consultez les notes de version d'Amazon DocumentDB à ce sujet.

Si vous vous appliquez vous-même, appliquez toujours le patch secondaire en premier et le patch principal en dernier. Cette commande permet de maintenir la disponibilité du basculement et de la commutation tout au long du déploiement.

Si vous n'agissez pas, le correctif s'applique automatiquement lors de la prochaine fenêtre de maintenance de chaque cluster : les secondaires d'abord, puis le correctif principal dans sa fenêtre une fois les secondaires terminées.

Conservez les clusters de bases de données principal et secondaire sur la même version. Le basculement interrégional géré ne fonctionne que sur une base de données globale lorsque chaque cluster partage la même version du moteur et le même niveau de correctif. Il en va de même si vous ajoutez un nouveau secondaire qui utilise une version de moteur plus récente que la version principale : créez de nouveaux secondaires sur la version principale avant de les joindre à la base de données globale.

Après avoir reçu une notification de correctif, effectuez la mise à niveau principale et secondaire vers la dernière version dès que possible pour que le basculement et le basculement continuent de fonctionner. Si une demande de basculement ou de basculement est rejetée, comparez les versions des correctifs du moteur entre les clusters ; si elles ne correspondent pas, appliquez le correctif disponible sur les clusters en retard.