Comment effectuer une mise à niveau sur place - Amazon Aurora
Comment les mises à niveau sur place affectent les groupes de paramètres d’un clusterModifications apportées aux propriétés du cluster entre les versions d’Aurora MySQLMises à niveau majeures sur place des bases de données globalesMises à niveau sur place avec réplicas en lecture entre régions

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.

Comment effectuer une mise à niveau sur place

Nous vous conseillons de passer en revue la documentation dans Fonctionnement de la mise à niveau sur place d’une version majeure de Aurora MySQL.

Effectuez la planification et les tests préalables nécessaires à la mise à niveau, comme décrit dans Planification d’une mise à niveau de version majeure d’un cluster Aurora MySQL.

L’exemple suivant met à niveau le cluster de bases de données mydbcluster-cluster vers Aurora MySQL version 3.04.1.

Pour mettre à niveau la version majeure d’un cluster de bases de données Aurora MySQL

  1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l’adresse https://console.aws.amazon.com/rds/.

  2. Si vous avez utilisé un groupe de paramètres personnalisé avec le cluster de bases de données d’origine, créez un groupe de paramètres correspondant compatible avec la nouvelle version majeure. Apportez les modifications nécessaires aux paramètres de configuration de ce nouveau groupe de paramètres. Pour plus d’informations, consultez Comment les mises à niveau sur place affectent les groupes de paramètres d’un cluster.

  3. Dans la panneau de navigation, choisissez Databases (Bases de données).

  4. Dans la liste, sélectionnez le cluster de bases de données à modifier.

  5. Sélectionnez Modify.

  6. Pour Version, sélectionnez une nouvelle version majeure d’Aurora MySQL.

    Nous conseillons généralement d’utiliser la dernière version mineure de la version majeure. Ici, nous choisissons la version par défaut actuelle.

    Mise à niveau sur place d’un cluster de bases de données Aurora MySQL de la version 2 vers la version 3

  7. Choisissez Continuer.

  8. Sur la page suivante, indiquez quand effectuer la mise à niveau. Sélectionnez During the next scheduled maintenance window (Pendant la fenêtre de maintenance planifiée suivante) ou Immediately (Immédiatement).

  9. (Facultatif) Examinez régulièrement la page Events (Événements) de la console RDS pendant la mise à niveau pour mieux surveiller la progression de la mise à niveau et identifier les problèmes éventuels. Si la mise à niveau rencontre des problèmes, consultez Dépannage de la mise à niveau sur place d’Aurora MySQL pour connaître les étapes à suivre.

  10. Si vous avez créé un nouveau groupe de paramètres au début de cette procédure, associez le groupe de paramètres personnalisé à votre cluster mis à niveau. Pour plus d’informations, consultez Comment les mises à niveau sur place affectent les groupes de paramètres d’un cluster.

    Note

    Pour effectuer cette étape, vous devez redémarrer le cluster afin d’appliquer le nouveau groupe de paramètres.

  11. (Facultatif) Après avoir terminé les tests postérieurs à la mise à niveau, supprimez l’instantané manuel créé par Aurora au début de la mise à niveau.

Pour mettre à niveau la version majeure d’un cluster de bases de données Aurora MySQL, utilisez la commande de l’AWS CLI modify-db-cluster avec les paramètres requis suivants :

  • --db-cluster-identifier

  • --engine-version

  • --allow-major-version-upgrade

  • --apply-immediately ou --no-apply-immediately

Si votre cluster utilise des groupes de paramètres personnalisés, incluez également l’une des options suivantes ou les deux :

  • --db-cluster-parameter-group-name, si le cluster utilise un groupe de paramètres de cluster personnalisé

  • --db-instance-parameter-group-name, si des instances du cluster utilisent un groupe de paramètres de base de données personnalisé

L’exemple suivant met à niveau le cluster de bases de données sample-cluster vers Aurora MySQL version 3.04.1. La mise à niveau se produit immédiatement, au lieu d’attendre la fenêtre de maintenance suivante.

Exemple

Pour Linux, macOS ou Unix :

aws rds modify-db-cluster \
          --db-cluster-identifier sample-cluster \
          --engine-version 8.0.mysql_aurora.3.04.1 \
          --allow-major-version-upgrade \
          --apply-immediately

Pour Windows :

aws rds modify-db-cluster ^
          --db-cluster-identifier sample-cluster ^
          --engine-version 8.0.mysql_aurora.3.04.1 ^
          --allow-major-version-upgrade ^
          --apply-immediately

Vous pouvez combiner d’autres commandes de la CLI avec modify-db-cluster pour créer un processus automatisé de bout en bout permettant d’effectuer et de vérifier les mises à niveau. Pour plus d’informations et d’exemples, consultez Tutoriel de mise à niveau sur place d’Aurora MySQL.

Note

Si votre cluster fait partie d’une base de données Aurora globale, la procédure de mise à niveau sur place est légèrement différente. Vous appelez l’opération de commande modify-global-cluster au lieu de modify-db-cluster. Pour plus d’informations, consultez Mises à niveau majeures sur place des bases de données globales.

Pour mettre à niveau la version majeure d’un cluster de bases de données Aurora MySQL, utilisez l’opération d’API RDS ModifyDBCluster avec les paramètres requis suivants :

  • DBClusterIdentifier

  • Engine

  • EngineVersion

  • AllowMajorVersionUpgrade

  • ApplyImmediately (défini sur true ou false).

Note

Si votre cluster fait partie d’une base de données Aurora globale, la procédure de mise à niveau sur place est légèrement différente. Appelez l’opération ModifyGlobalCluster au lieu de ModifyDBCluster. Pour plus d’informations, consultez Mises à niveau majeures sur place des bases de données globales.

Comment les mises à niveau sur place affectent les groupes de paramètres d’un cluster

Les groupes de paramètres Aurora ont différents ensembles de paramètres de configuration pour les clusters compatibles avec MySQL 5.7 ou 8.0. Lorsque vous effectuez une mise à niveau sur place, le cluster mis à niveau et toutes ses instances doivent utiliser les groupes de paramètres de cluster et d’instance correspondants :

Votre cluster et vos instances peuvent utiliser les groupes de paramètres compatibles avec la version 5.7 par défaut. Si tel est le cas, le cluster mis à niveau et l’instance commencent par les groupes de paramètres compatibles avec la version 8.0 par défaut. Si votre cluster et vos instances utilisent des groupes de paramètres personnalisés, assurez-vous de créer des groupes de paramètres correspondants compatibles avec la version 8.0. Assurez-vous également de les spécifier au cours du processus de mise à niveau.

Note

Pour la plupart des paramètres, vous pouvez choisir le groupe de paramètres personnalisé à deux points. C’est lorsque vous créez le cluster ou que vous associez le groupe de paramètres au cluster ultérieurement.

Toutefois, si vous utilisez un autre paramètre que le paramètre par défaut pour lower_case_table_names, vous devez configurer le groupe de paramètres personnalisés avec ce paramètre à l’avance. Spécifiez ensuite le groupe de paramètres lorsque vous effectuez la restauration des instantanés pour créer le cluster. Les modifications apportées au paramètre lower_case_table_names n’ont aucun effet après la création du cluster.

Nous vous recommandons d’utiliser le même paramètre pour lower_case_table_names lorsque vous passez de la version 2 à la version 3 de Aurora MySQL.

Avec une base de données globale Aurora basée sur Aurora MySQL, vous ne pouvez effectuer une mise à niveau sur place d’Aurora MySQL version 2 vers la version 3 que si le paramètre lower_case_table_names est défini sur sa valeur par défaut et si vous redémarrez la base de données globale. Pour plus d’informations sur les méthodes que vous pouvez utiliser, consultez Mises à niveau de version majeure..

Modifications apportées aux propriétés du cluster entre les versions d’Aurora MySQL

Lorsque vous effectuez une mise à niveau d’Aurora MySQL version 2 vers la version 3, veillez à vérifier les applications et les scripts que vous utilisez pour configurer ou gérer des clusters et des instances de base de données Aurora MySQL.

En outre, modifiez le code qui manipule les groupes de paramètres afin qu’il tienne compte du fait que les noms de groupes de paramètres par défaut sont différents pour les clusters compatibles avec 5.7 et 8.0. Les noms des groupes de paramètres par défaut pour des clusters Aurora MySQL versions 2 et 3 sont default.aurora-mysql5.7 et default.aurora-mysql8.0, respectivement.

Par exemple, vous pouvez avoir un code semblable au suivant qui s’applique à votre cluster avant une mise à niveau.

# Check the default parameter values for MySQL 5.7–compatible clusters.
aws rds describe-db-parameters --db-parameter-group-name default.aurora-mysql5.7 --region us-east-1

Après la mise à niveau de la version majeure du cluster, modifiez ce code comme suit.

# Check the default parameter values for MySQL 8.0–compatible clusters.
aws rds describe-db-parameters --db-parameter-group-name default.aurora-mysql8.0 --region us-east-1

Mises à niveau majeures sur place des bases de données globales

Pour une base de données Aurora globale, mettez à niveau le cluster de bases de données globale. Aurora met automatiquement à niveau tous les clusters en même temps et s’assure qu’ils utilisent tous la même version du moteur. Cette exigence est due au fait que toutes les modifications apportées aux tables système, aux formats de fichiers de données et autres éléments sont automatiquement répliquées sur tous les clusters secondaires.

Suivez les instructions de la section Fonctionnement de la mise à niveau sur place d’une version majeure de Aurora MySQL. Lorsque vous spécifiez ce qui doit être mis à niveau, veillez à choisir le cluster de bases de données global plutôt que l’un des clusters qu’il contient.

Si vous utilisez l’AWS Management Console, choisissez l’élément avec le rôle Global database (Base de données globale).

Mise à niveau du cluster de bases de données

Si vous utilisez l’AWS CLI ou l’API RDS, lancez le processus de mise à niveau en appelant la commande modify-global-cluster ou l’opération ModifyGlobalCluster. Vous utilisez l’un d’entre eux au lieu de modify-db-cluster ou ModifyDBCluster.

Note

Vous ne pouvez pas spécifier un groupe de paramètres personnalisés pour le cluster de bases de données globale pendant que vous effectuez une mise à niveau majeure de la version de cette base de données globale Aurora. Créez vos groupes de paramètres personnalisés dans chaque région du cluster global. Appliquez-les ensuite manuellement aux clusters régionaux après la mise à niveau.

Pour mettre à niveau la version majeure d’un cluster de bases de données Aurora MySQL global à l’aide de l’interface AWS CLI, utilisez la commande modify-global-cluster avec les paramètres requis suivants :

  • --global-cluster-identifier

  • --engine aurora-mysql

  • --engine-version

  • --allow-major-version-upgrade

L’exemple suivant met à niveau le cluster de bases de données global vers Aurora MySQL version 3.04.2.

Exemple

Pour Linux, macOS ou Unix :

aws rds modify-global-cluster \
          --global-cluster-identifier global_cluster_identifier \
          --engine aurora-mysql \
          --engine-version 8.0.mysql_aurora.3.04.2 \
          --allow-major-version-upgrade

Pour Windows :

aws rds modify-global-cluster ^
          --global-cluster-identifier global_cluster_identifier ^
          --engine aurora-mysql ^
          --engine-version 8.0.mysql_aurora.3.04.2 ^
          --allow-major-version-upgrade

Mises à niveau sur place pour les clusters de bases de données ayant des réplicas en lecture entre régions

Vous pouvez mettre à niveau un cluster de bases de données Aurora ayant un réplica en lecture entre régions à l’aide de la procédure de mise à niveau sur place, mais certains éléments doivent être pris en considération :

  • Vous devez d’abord mettre à niveau le cluster de bases de données du réplica en lecture. Si vous essayez d’abord de mettre à niveau le cluster principal, vous recevez un message d’erreur similaire au message suivant :

    Impossible de mettre à niveau le cluster de bases de données test-xr-primary-cluster, car le réplica entre régions d’Aurora associé, test-xr-replica-cluster, n’a pas encore reçu les correctifs requis. Mettez à niveau le réplica entre régions d’Aurora et réessayez.

    Cela signifie que le cluster de bases de données principal ne peut pas avoir une version de moteur de base de données supérieure à celle du cluster de réplication.

  • Avant de mettre à niveau le cluster de bases de données principal, arrêtez la charge de travail d’écriture et désactivez toute nouvelle demande de connexion à l’instance de base de données d’enregistreur du cluster principal.

  • Lorsque vous mettez à niveau le cluster principal, choisissez un groupe de paramètres de cluster de bases de données personnalisé dont le paramètre binlog_format est défini sur une valeur qui prend en charge la réplication des journaux binaires, comme MIXED.

    Pour plus d’informations sur l’utilisation de la journalisation binaire Aurora, consultez Réplication entre Aurora et MySQL ou entre Aurora et un autre cluster de bases de données Aurora (réplication de journaux binaires). Pour plus d’informations sur la modification des paramètres de configuration de Aurora MySQL, consultez Paramètres de configuration d’Aurora MySQL et Groupes de paramètres pour Amazon Aurora.

  • N’attendez pas trop longtemps pour mettre à niveau le cluster de bases de données principal après avoir mis à niveau le cluster du réplica. Nous vous recommandons de ne pas attendre au-delà de la fenêtre de maintenance suivante.

  • Après avoir mis à niveau le cluster de bases de données principal, redémarrez son instance de base de données d’enregistreur. Le groupe de paramètres de cluster de bases de données personnalisé qui active la réplication des journaux binaires ne prend effet qu’une fois que l’instance de base de données d’enregistreur est redémarrée.

  • Ne relancez pas la charge de travail d’écriture et n’activez pas les connexions à l’instance de base de données d’enregistreur tant que vous n’avez pas confirmé que la réplication entre régions a redémarré et que le délai de réplication de la Région AWS secondaire est de 0.