Mise à niveau de la version mineure ou du niveau de correctif d'un cluster de base de données Aurora MySQL

Vous pouvez utiliser les méthodes suivantes pour mettre à niveau la version mineure d'un cluster de base de données ou appliquer un correctif à un cluster de base de données :

• Mise à niveau d'Aurora MySQL par modification de la version du moteur (pour Aurora MySQL versions 2 et 3)

• Activation des mises à niveau automatiques entre versions mineures Aurora MySQL

Pour plus d'informations sur la façon dont l'application de correctifs sans interruption peut réduire les interruptions pendant le processus de mise à niveau, veuillez consulter Utilisation des correctifs sans temps d'arrêt.

Avant d'effectuer une mise à niveau d'une version mineure

Nous vous recommandons d'effectuer les actions suivantes afin de réduire le temps d'arrêt lors d'une mise à niveau de version mineure :

• La maintenance du cluster de base de données Aurora doit être effectuée pendant une période de faible trafic. Utilisez Performance Insights pour identifier ces périodes afin de configurer correctement les fenêtres de maintenance. Pour plus d'informations sur Performance Insights, consultez la section Surveillance de la charge de base de données avec Performance Insights sur Amazon RDS. Pour plus d'informations sur la fenêtre de maintenance du cluster de bases de données,Ajustement du créneau de maintenance préféré pour un cluster de base de données.

• Utilisez AWS des SDK qui prennent en charge le recul et l'instabilité exponentiels en tant que meilleure pratique. Pour plus d'informations, consultez Exponential Backoff And Jitter.

Prévérifications de mise à niveau des versions mineures pour Aurora MySQL

Lorsque vous lancez une mise à niveau d'une version mineure, Amazon Aurora exécute automatiquement des prévérifications.

Ces vérifications préalables sont obligatoires. Vous ne pouvez pas choisir de les ignorer. Elles offrent les avantages suivants :

• Elles vous permettent d'éviter les temps d'arrêts non planifiés pendant la mise à niveau.

• En cas d'incompatibilités, Amazon Aurora empêche la mise à niveau et fournit un journal pour que vous puissiez en savoir plus. Vous pouvez ensuite utiliser le journal pour préparer votre base de données pour la mise à niveau en réduisant les incompatibilités. Pour des informations détaillées sur la suppression des incompatibilités, consultez Préparation de votre installation pour la mise à niveau dans la documentation MySQL.

Les vérifications préalables s'exécutent avant que l'instance de base de données soit arrêtée pour la mise à niveau, ce qui signifie que leur exécution n'entraîne aucun temps d'arrêt. Si les prévérifications révèlent une incompatibilité, Aurora annule automatiquement la mise à niveau avant que l'instance de base de données ne soit arrêtée. Aurora génère également un événement pour l'incompatibilité. Pour plus d'informations sur les événements Amazon Aurora, consultezUtiliser la notification d'événements d'Amazon RDS.

Aurora enregistre des informations détaillées sur chaque incompatibilité dans le fichier PrePatchCompatibility.log journal. Dans la plupart des cas, l'entrée de journal inclut un lien vers la documentation MySQL permettant de corriger l'incompatibilité. Pour de plus amples informations sur l'affichage des fichiers journaux, veuillez consulter Liste et affichage des fichiers journaux de base de données.

En raison de la nature des vérifications préalables, elle analysent les objets dans votre base de données. L'analyse entraîne la consommation de ressources et augmente le temps nécessaire pour la mise à niveau.

Mise à niveau d'Aurora MySQL par modification de la version du moteur

La mise à niveau de la version mineure d'un cluster de base de données Aurora MySQL applique des correctifs supplémentaires et de nouvelles fonctionnalités à un cluster existant.

Ce type de mise à niveau s'applique aux clusters Aurora MySQL où la version d'origine et la version mise à niveau possèdent toutes deux la même version majeure d'Aurora MySQL, soit 2 soit 3. Le processus est rapide et simple car il n'implique ni conversion pour les métadonnées Aurora MySQL, ni réorganisation de vos données de table.

Vous effectuez ce type de mise à niveau en modifiant la version du moteur du cluster de base de données à l'aide de AWS Management Console AWS CLI, ou de l'API RDS. Par exemple, si votre cluster exécute Aurora MySQL 2.x, choisissez une version 2.x supérieure.

Si vous effectuez une mise à niveau mineure sur une base de données Aurora globale, mettez à niveau tous les clusters secondaires avant de mettre à niveau le cluster principal.

Note

Pour effectuer une mise à niveau de version mineure vers Aurora MySQL version 3.03.* ou ultérieure, ou version 2.12.*, procédez comme suit :

1. Supprimez toutes les régions secondaires du cluster global. Suivez les étapes de Dissociation d'un cluster d'une base de données Amazon Aurora globale.

2. Mettez à niveau la version du moteur de la région principale vers la version 3.03.* ou ultérieure, ou vers la version 2.12.*, selon le cas. Suivez les étapes de To modify the engine version of a DB cluster.

3. Ajoutez des régions secondaires au cluster global. Suivez les étapes de Ajout d'une Région AWS à une base de données Amazon Aurora globale.

Pour modifier la version du moteur d'un cluster de base de données

• Avec la console – Modifiez les propriétés de votre cluster. Dans la fenêtre Modifier le cluster de base de données, modifiez la version du moteur Aurora MySQL dans la zone Version du moteur de base de données. Si vous n'êtes pas familier avec la procédure générale de modification d'un cluster, suivez les instructions à l'adresse Modification du cluster de bases de données à partir de la console, de l'CLI (CLI) et de l'API.

• À l'aide de la commande AWS CLI— Appelez la AWS CLI commande modify-db-cluster et spécifiez le nom de votre cluster de base de données pour l'--db-cluster-identifieroption et la version du moteur pour l'option. --engine-version

  Par exemple, pour effectuer une mise à niveau vers la version 2.12.1 d'Aurora MySQL, définissez l'--engine-versionoption sur. 5.7.mysql_aurora.2.12.1 Spécifiez l'option --apply-immediately pour mettre à jour immédiatement la version du moteur de votre cluster de base de données.

• Avec l'API RDS – Appelez l'opération de l'API ModifyDBCluster et spécifiez le nom de votre cluster de base de données pour le paramètre DBClusterIdentifier et la version du moteur pour le paramètre EngineVersion. Définissez le paramètre ApplyImmediately sur true pour mettre à jour immédiatement la version du moteur du cluster de base de données.

Activation des mises à niveau automatiques entre versions mineures Aurora MySQL

Pour un cluster de base de données Amazon Aurora MySQL, vous pouvez spécifier qu'Aurora met automatiquement à niveau le cluster de base de données vers de nouvelles versions mineures. Pour ce faire, définissez la AutoMinorVersionUpgrade propriété (Mise à niveau automatique des versions mineures dans le AWS Management Console) du cluster de base de données.

Des mises à niveau automatiques se produisent dans la fenêtre de maintenance. Si les différentes instances de base de données du cluster de base de données ont des fenêtres de maintenance différentes de la fenêtre de maintenance du cluster, cette dernière est prioritaire.

La mise à niveau automatique des versions mineures ne s'applique pas aux types de clusters Aurora MySQL suivants :

• Clusters faisant partie d'une base de données globale Aurora

• Clusters ayant des réplicas entre régions

La durée de l'indisponibilité varie en fonction de la charge de travail, de la taille du cluster, de la quantité de données du journal binaire et de la possibilité pour Aurora d'utiliser la fonction d'application de correctifs sans temps d'arrêt. Aurora redémarre le cluster de base de données. Une courte période d'indisponibilité est donc possible avant que vous puissiez reprendre l'utilisation de votre cluster. En particulier, la quantité de données consignées dans le journal binaire affecte la durée de récupération. L'instance de base de données traite les données de journal binaire pendant la restauration. Ainsi, un volume élevé de données de journal binaire augmente le temps de restauration.

Note

Aurora n'effectue des mises à niveau automatiques que si le AutoMinorVersionUpgrade paramètre est activé pour toutes les instances de base de données de votre cluster de base de données. Pour plus d'informations sur son paramétrage et son fonctionnement lorsqu'il est appliqué au niveau du cluster et de l'instance, consultez Mises à niveau automatiques des versions mineures pour les clusters de base de données Aurora.

Ensuite, s'il existe un chemin de mise à niveau pour les instances du cluster de bases de données vers une version mineure du moteur de base de données AutoUpgrade définie sur true, la mise à niveau aura lieu. Le AutoUpgrade paramètre est dynamique et est défini par RDS.

Des mises à niveau automatiques de version mineure sont effectuées vers la version mineure par défaut.

Vous pouvez utiliser une commande CLI telle que la suivante pour vérifier le statut du paramètre AutoMinorVersionUpgrade pour toutes les instances de base de données figurant dans vos clusters Aurora MySQL.

aws rds describe-db-instances \
  --query '*[].{DBClusterIdentifier:DBClusterIdentifier,DBInstanceIdentifier:DBInstanceIdentifier,AutoMinorVersionUpgrade:AutoMinorVersionUpgrade}'

Le résultat de cette commande est semblable à ce qui suit :

[
  {
      "DBInstanceIdentifier": "db-t2-medium-instance",
      "DBClusterIdentifier": "cluster-57-2020-06-03-6411",
      "AutoMinorVersionUpgrade": true
  },
  {
      "DBInstanceIdentifier": "db-t2-small-original-size",
      "DBClusterIdentifier": "cluster-57-2020-06-03-6411",
      "AutoMinorVersionUpgrade": false
  },
  {
      "DBInstanceIdentifier": "instance-2020-05-01-2332",
      "DBClusterIdentifier": "cluster-57-2020-05-01-4615",
      "AutoMinorVersionUpgrade": true
  },
... output omitted ...

Dans cet exemple, la paramètre Activer la mise à niveau automatique des versions mineures est désactivé pour le cluster de base de données cluster-57-2020-06-03-6411, car il est désactivé pour l'une des instances de base de données du cluster.

Utilisation des correctifs sans temps d'arrêt

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 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 fonction d'application de correctifs sans temps d'arrêt (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 temps d'arrêt 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 temps d'arrêt 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 et classes d'instance de base de données d'Aurora MySQL 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 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 voir les métriques des attributs importants pendant l'application de correctifs sans temps d'arrêt 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 versions 2.10 et ultérieures et dans la version 3, Aurora peut effectuer un correctif sans temps d'arrêt que la réplication du journal binaire soit activée ou non. Si la réplication du journal binaire est activée, Aurora MySQL supprime automatiquement la connexion à la cible des journaux binaires pendant une opération d'application de correctifs sans temps d'arrêt. 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 temps d'arrêt fonctionne également en combinaison avec les améliorations du redémarrage dans Aurora MySQL versions 2.10 et 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 MySQL version 2.10, l'application de correctifs sans temps d'arrêt s'appliquait uniquement à l'instance de base de données d'enregistreur d'un cluster.

L'application de correctifs sans temps d'arrêt 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 ZDP dans ce cas, les transactions ouvertes sont annulées.

• Des tables temporaires 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. Si Aurora peut exécuter ZDP dans ce cas, les transactions ouvertes sont annulées.

• Des modifications de paramètre sont en attente.

Si aucun créneau adéquat pour l'application de correctifs sans temps d'arrêt ne devient disponible en raison d'une ou de plusieurs de ces conditions, l'application de correctifs adopte de nouveau le comportement standard.

Note

Pour la version 2 d'Aurora MySQL inférieure à 2.11.0 et la version 3 inférieure à 3.04.0, ZDP peut ne pas fonctionner correctement lorsque des connexions SSL (Secure Socket Layer) ou TLS (Transport Layer Security) sont ouvertes.

Bien que les connexions restent intactes après une opération d'application de correctifs sans temps d'arrêt, 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 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é 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.

Technique alternative de mise à niveau bleu/vert

Dans certains cas, votre priorité absolue est d'effectuer une commutation immédiate de l'ancien cluster vers un cluster mis à niveau. Dans de telles situations, vous pouvez utiliser un processus en plusieurs étapes qui exécute les anciens et les nouveaux clusters side-by-side. Dans ce cas, répliquez les données de l'ancien cluster au nouveau jusqu'à ce que ce dernier soit prêt à prendre le relais. Pour plus d'informations, consultez Utilisation des déploiements bleu/vert Amazon RDS pour les mises à jour de base de données.