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 des répliques de lecture interrégionales

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 toute planification et tous les tests préalables à la mise à niveau, comme décrit dansPlanification d'une mise à niveau de version majeure d'un cluster Aurora MySQL.

L'exemple suivant met à niveau le mydbcluster-cluster cluster de base de données 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 console Amazon RDS AWS Management Console et ouvrez-la à https://console.aws.amazon.com/rds/l'adresse.

  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 Résolution des problèmes liés à la mise à niveau SQL sur place d'Aurora My 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 de plus amples informations, veuillez consulter 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 base de données Aurora MySQL, utilisez la AWS CLI modify-db-clustercommande 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 sample-cluster cluster de base de données 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

Dans 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

Dans 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 CLI modify-db-cluster pour créer un end-to-end processus automatisé d'exécution et de vérification des mises à niveau. Pour plus d'informations et d'exemples, consultez Tutoriel de mise à niveau SQL sur place d'Aurora My.

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 modify-global-clusterde commande au lieu demodify-db-cluster. Pour de plus amples informations, veuillez consulter Mises à niveau majeures sur place des bases de données globales.

Pour mettre à niveau la version majeure d'un cluster de base de données Aurora MySQL, utilisez l'opération Modify de l'API RDS DBCluster 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. Vous appelez l'ModifyGlobalClusteropération au lieu deModifyDBCluster. Pour de plus amples informations, veuillez consulter 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 pouvez effectuer une mise à niveau sur place de la version 2 vers la version 3 d'Aurora MySQL uniquement si vous définissez le lower_case_table_names paramètre par défaut et redémarrez votre base de données globale. Pour plus d'informations sur les méthodes que vous pouvez utiliser, consultez Mises à niveau de version majeure..

Important

Si vous spécifiez un groupe de paramètres personnalisé pendant le processus de mise à niveau, assurez-vous de redémarrer manuellement le cluster une fois la mise à niveau terminée. Ainsi, le cluster commencera à utiliser vos paramètres personnalisés.

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 base 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 base de données global plutôt que l'un des clusters qu'il contient.

Si vous utilisez le AWS Management Console, choisissez l'élément avec le rôle Base de données globale.

Mise à niveau du cluster de base de données

Si vous utilisez l'API AWS CLI ou l'API RDS, lancez le processus de mise à niveau en appelant la modify-global-clustercommande ou l'ModifyGlobalClusteropération. 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 base 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 global Aurora MySQL à l'aide de AWS CLI, utilisez la modify-global-clustercommande avec les paramètres obligatoires suivants :

  • --global-cluster-identifier

  • --engine aurora-mysql

  • --engine-version

  • --allow-major-version-upgrade

L'exemple suivant met à niveau le cluster de base de données global vers la version 3.04.2 d'Aurora MySQL.

Exemple

Dans 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

Dans 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 avec des répliques de lecture entre régions

Vous pouvez mettre à niveau un cluster de base de données Aurora doté d'une réplique en lecture entre régions à l'aide de la procédure de mise à niveau sur place, mais certaines considérations doivent être prises en compte :

  • Vous devez d'abord mettre à niveau le cluster de base de données Read Replica. Si vous essayez d'abord de mettre à niveau le cluster principal, vous recevrez un message d'erreur tel que le suivant :

    Impossible de mettre à niveau le cluster de base de données test-xr-primary-cluster car la réplique interrégionale Aurora associée test-xr-replica-cluster n'est pas encore corrigée. Mettez à niveau la réplique interrégionale d'Aurora et réessayez.

    Cela signifie que le cluster de base 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 base 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'écriture du cluster principal.

  • Lorsque vous mettez à niveau le cluster principal, choisissez un groupe de paramètres de cluster de base de données personnalisé dont le binlog_format paramètre est défini sur une valeur qui prend en charge la réplication de journalisation binaire, telle queMIXED.

    Pour plus d'informations sur l'utilisation de la journalisation binaire Aurora, consultez Réplication entre Aurora et My SQL ou entre Aurora et un autre cluster de base 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 SQL configuration d'Aurora My et Groupes de paramètres pour Amazon Aurora ().

  • N'attendez pas trop longtemps pour mettre à niveau le cluster de base de données principal après avoir mis à niveau le cluster de répliques. Nous vous recommandons de ne pas attendre plus longtemps que la fenêtre de maintenance suivante.

  • Après avoir mis à niveau le cluster de base de données principal, redémarrez son instance de base de données d'écriture. Le groupe de paramètres de cluster de base de données personnalisé qui active la réplication du journal binaire ne prend effet qu'une fois que l'instance de base de données du rédacteur est redémarrée.

  • Ne reprenez pas la charge de travail d'écriture et n'activez pas les connexions à l'instance de base de données du rédacteur 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 dans l'instance secondaire Région AWS est de 0.