Utilisation des correctifs sans durée d’indisponibilité - Amazon Aurora

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.

Utilisation des correctifs sans durée d’indisponibilité

L’exécution de mises à niveau pour les clusters de bases de données Aurora MySQL implique la possibilité d’une panne lorsque la base de données est arrêtée et pendant sa mise à niveau. Par défaut, si vous démarrez la mise à niveau alors que la base de données est occupée, vous perdez toutes les connexions et transactions traitées par le cluster de bases de données. Si vous attendez que la base de données soit inactive pour effectuer la mise à niveau, vous devrez peut-être attendre longtemps.

La fonctionnalité d’application de correctifs sans durée d’indisponibilité (ZDP) tente, dans un souci d’optimisation, de conserver les connexions client tout au long de la mise à niveau d’Aurora MySQL. Si l’application de correctifs sans durée d’indisponibilité s’exécute correctement, les sessions d’application sont conservées et le moteur de base de données redémarre pendant que la mise à niveau est en cours. Le redémarrage du moteur de base de données peut entraîner une chute du débit qui dure de quelques secondes à environ une minute.

L’application de correctifs sans durée d’indisponibilité ne s’applique pas aux éléments suivants :

  • Correctifs et mises à niveau du système d’exploitation

  • Mises à niveau de version majeure.

ZDP est disponible pour toutes les versions d’Aurora MySQL et classes d’instance de base de données prises en charge.

ZDP n’est pas pris en charge pour les bases de données globales Aurora ou Aurora Serverless v1.

Note

Nous recommandons d’utiliser les classes d’instance de base de données T uniquement pour les serveurs de développement et de test, ou pour d’autres serveurs non dédiés à la production. Pour plus de détails sur les classes d’instance T, consultez Utilisation de classes d’instance T pour le développement et les tests.

Vous pouvez voir les métriques des attributs importants pendant l’application de correctifs sans durée d’indisponibilité dans le journal des erreurs MySQL. Vous pouvez également voir des informations sur les moments où Aurora MySQL utilise ZDP ou choisit de ne pas l’utiliser sur la page Events (Événements) de la AWS Management Console.

Dans Aurora MySQL, Aurora peut appliquer un correctif sans durée d’indisponibilité, que la réplication des journaux binaires soit activée ou non. Si la réplication des journaux binaires est activée, Aurora MySQL supprime automatiquement la connexion à la cible des journaux binaires pendant une opération d’application de correctifs sans durée d’indisponibilité. Aurora MySQL se reconnecte automatiquement à la cible des journaux binaires et reprend la réplication une fois le redémarrage terminé.

L’application de correctifs sans durée d’indisponibilité fonctionne également en combinaison avec les améliorations du redémarrage dans Aurora MySQL. Le correctif de l’instance de base de données d’enregistreur corrige automatiquement les lecteurs en même temps. Après avoir exécuté le correctif, Aurora restaure les connexions sur les instances de base de données d’enregistreur et de lecteur.

L’application de correctifs sans durée d’indisponibilité peut ne pas s’exécuter correctement dans les conditions suivantes :

  • Des transactions ou des requêtes de longue durée sont en cours. Si Aurora peut exécuter l’application de correctifs sans durée d’indisponibilité dans ce cas, les connexions ouvertes sont conservées.

  • Des tables temporaires, des verrous utilisateur ou des verrous de table sont utilisés, par exemple lorsque des instructions de langage de définition de données (DDL) s’exécutent. Aurora abandonne ces connexions.

  • Des modifications de paramètre sont en attente.

Si aucun créneau adéquat pour l’application de correctifs sans durée d’indisponibilité ne devient disponible en raison d’une ou de plusieurs de ces conditions, l’application de correctifs adopte de nouveau le comportement standard.

Bien que les connexions restent intactes après une opération d’application de correctifs sans durée d’indisponibilité, certaines variables et fonctions sont réinitialisées. Les types d’informations suivants ne sont pas conservés lors d’un redémarrage causé par une application de correctifs sans durée d’indisponibilité :

  • Variables globales Aurora restaure les variables de session, mais pas les variables globales après le redémarrage.

  • Variables d’état. En particulier, la valeur de disponibilité signalée par le statut du moteur est réinitialisée après un redémarrage utilisant les mécanismes ZDR ou ZDP.

  • LAST_INSERT_ID.

  • État auto_increment en mémoire pour les tables. L’état d’auto-incrémentation en mémoire est réinitialisé. Pour plus d’informations sur les valeurs d’auto-incrémentation, reportez-vous au manuel de référence MySQL.

  • Les informations de diagnostic des tableaux INFORMATION_SCHEMA et PERFORMANCE_SCHEMA. Ces informations de diagnostic apparaissent également dans la sortie de commandes telles que SHOW PROFILE et SHOW PROFILES.

Les activités suivantes liées au redémarrage sans interruption sont signalées sur la page Events (Événements) :

  • Tentative de mise à niveau de la base de données sans interruption.

  • Tentative de mise à niveau de la base de données terminée sans aucune interruption. L’événement indique combien de temps le processus a duré. L’événement indique également combien de connexions ont été préservées pendant le redémarrage et combien de connexions ont été annulées. Vous pouvez consulter le journal des erreurs de la base de données pour en savoir plus sur ce qui s’est passé pendant le redémarrage.