Utilisation des correctifs sans temps d'arrêt

L'exécution de mises à niveau pour les clusters Aurora My SQL DB 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 base 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é patching (ZDP) sans interruption de service tente, dans la mesure du possible, de préserver les connexions des clients grâce à une mise à niveau d'Aurora My. SQL En cas ZDP de réussite, les sessions d'application sont préservé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.

ZDPne s'applique pas aux situations suivantes :

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

• Mises à niveau de version majeure.

ZDPest disponible pour toutes les SQL versions et classes d'instances de base de données Aurora My prises en charge.

ZDPn'est pas pris en charge pour Aurora Serverless v1 ou bases de données globales Aurora.

Note

Nous recommandons d'utiliser uniquement les classes d'instance de base de données T 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'instances T pour le développement et les tests.

Vous pouvez consulter les statistiques relatives aux attributs importants ZDP dans le journal des erreurs de Mon journal des SQL erreurs. Vous pouvez également consulter des informations sur les cas dans lesquels Aurora My SQL utilise ZDP ou choisit de ne pas utiliser ZDP sur la page Événements du AWS Management Console.

Dans les SQL versions 2.10 et supérieures d'Aurora My et dans la version 3, Aurora peut appliquer un correctif sans interruption de service, que la réplication des journaux binaires soit activée ou non. Si la réplication du journal binaire est activée, Aurora My supprime SQL automatiquement la connexion à la cible du journal binaire au cours d'une ZDP opération. Aurora My se reconnecte SQL automatiquement à la cible du journal binaire et reprend la réplication une fois le redémarrage terminé.

ZDPfonctionne également en combinaison avec les améliorations apportées au redémarrage dans Aurora My SQL 2.10 et versions ultérieures. 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. Avant Aurora My SQL 2.10, ZDP s'applique uniquement à l'instance de base de données d'écriture d'un cluster.

ZDPrisque de 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 fonctionner ZDP dans ce cas, toutes les transactions ouvertes sont annulées mais leurs connexions sont conservées.

• Des tables temporaires, des verrous utilisateur ou des verrous de table sont utilisés, par exemple lors de l'exécution des instructions du langage de définition des données (DDL). Aurora supprime ces connexions.

• Des modifications de paramètre sont en attente.

Si aucune fenêtre temporelle adaptée à l'exécution n'est ZDP disponible en raison d'une ou de plusieurs de ces conditions, le comportement standard de l'application des correctifs est rétabli.

Note

Pour SQL la version 2 d'Aurora My inférieure à 2.11.0 et la version 3 inférieure à 3.04.0, l'exécution ZDP peut échouer lorsque des connexions Secure Socket Layer (SSL) ou Transport Layer Security (TLS) sont ouvertes.

Bien que les connexions restent intactes après une ZDP opération réussie, certaines variables et fonctionnalités 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 temps d'arrêt :

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

• Variables de statut. En particulier, la valeur de disponibilité indiquée par l'état du moteur est réinitialisée après un redémarrage utilisant les ZDP mécanismes ZDR OR.

• 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'incrémentation automatique, consultez Mon manuel de SQL référence.

• 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.