Mettre à niveau la version majeure de la base de données sur place

Cette page décrit comment mettre à niveau la version majeure de la base de données en mettant à niveau votre instance Cloud SQL plutôt qu'en migrant les données.

Introduction

Les fournisseurs de logiciels de base de données publient régulièrement de nouvelles versions majeures contenant de nouvelles fonctionnalités, des améliorations de performances et des améliorations de sécurité. Cloud SQL intègre de nouvelles versions après leur publication. Une fois que Cloud SQL est compatible avec une nouvelle version majeure, vous pouvez mettre à jour vos instances pour maintenir votre base de données à jour.

Vous pouvez mettre à niveau la version de base de données d'une instance sur place ou en migrant les données. Les mises à niveau sur place constituent un moyen plus simple de mettre à niveau la version majeure de votre instance. Vous n'avez pas besoin de migrer les données ni de modifier les chaînes de connexion de l'application. Avec les mises à niveau sur place, vous pouvez conserver le nom, l'adresse IP et d'autres paramètres de votre instance actuelle après la mise à niveau. Les mises à niveau sur place ne nécessitent pas de déplacer de fichiers de données et peuvent être effectuées plus rapidement. Dans certains cas, le temps d'arrêt est plus court que celui qu'implique la migration de vos données.

Planifier une mise à niveau de version majeure

1. Vérifiez que vous disposez du rôle requis pour effectuer une mise à niveau de version majeure : Propriétaire Cloud SQL ou Administrateur Cloud SQL.

2. Choisissez une version majeure cible.

   gcloud

   Pour en savoir plus sur l'installation et le démarrage avec la gcloud CLI, consultez la page Installer la gcloud CLI. Pour en savoir plus sur le démarrage de Cloud Shell, consultez la page Utiliser Cloud Shell.

   Pour vérifier les versions de bases de données que vous pouvez cibler pour une mise à niveau sur place sur votre instance, procédez comme suit :

   1. Exécutez la commande suivante :

   gcloud sql instances describe INSTANCE_NAME
      

   Remplacez INSTANCE_NAME par le nom de l'instance.

   2. Dans le résultat de la commande, localisez la section intitulée upgradableDatabaseVersions.
   3. Chaque sous-section renvoie une version de base de données disponible pour la mise à niveau. Dans chaque sous-section, examinez les champs suivants.
   • majorVersion : version majeure que vous pouvez cibler pour la mise à niveau sur place.
   • name : chaîne de version de base de données qui inclut la version majeure. Pour Cloud SQL pour MySQL, ce champ inclut également la version mineure de la base de données.
   • displayName : nom à afficher pour la version de base de données.

   REST v1

   Pour vérifier les versions de bases de données cibles disponibles pour la mise à niveau sur place d'une version majeure, utilisez la méthode instances.get de l'API Cloud SQL Admin.

   Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :

   • INSTANCE_NAME : nom de l'instance.

   Méthode HTTP et URL :

   GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME

   Pour envoyer votre requête, développez l'une des options suivantes :

   curl (Linux, macOS ou Cloud Shell)

   Exécutez la commande suivante :

   curl -X GET \
        -H "Authorization: Bearer $(gcloud auth print-access-token)" \
        "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME"

   PowerShell (Windows)

   Exécutez la commande suivante :

   $cred = gcloud auth print-access-token
   $headers = @{ "Authorization" = "Bearer $cred" }
   
   Invoke-WebRequest `
       -Method GET `
       -Headers $headers `
       -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME" | Select-Object -Expand Content

   Vous devriez recevoir une réponse JSON de ce type :

   
   upgradableDatabaseVersions:
   
   {
     major_version: "MYSQL_8_0"
     name: "MYSQL_8_0_36"
     display_name: "MySQL 8.0.36"
   }
   
   

   REST v1beta4

   Pour vérifier les versions de bases de données cibles disponibles pour la mise à niveau sur place de la version majeure d'une instance, utilisez la méthode instances.get de l'API Cloud SQL Admin.

   Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :

   • INSTANCE_NAME : nom de l'instance.

   Méthode HTTP et URL :

   GET https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME

   Pour envoyer votre requête, développez l'une des options suivantes :

   curl (Linux, macOS ou Cloud Shell)

   Exécutez la commande suivante :

   curl -X GET \
        -H "Authorization: Bearer $(gcloud auth print-access-token)" \
        "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME"

   PowerShell (Windows)

   Exécutez la commande suivante :

   $cred = gcloud auth print-access-token
   $headers = @{ "Authorization" = "Bearer $cred" }
   
   Invoke-WebRequest `
       -Method GET `
       -Headers $headers `
       -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME" | Select-Object -Expand Content

   Vous devriez recevoir une réponse JSON de ce type :

   
   upgradableDatabaseVersions:
   
   {
     major_version: "MYSQL_8_0"
     name: "MYSQL_8_0_36"
     display_name: "MySQL 8.0.36"
   }
   
   

   Pour obtenir la liste complète des versions de bases de données compatibles avec Cloud SQL, consultez Versions de bases de données et règles de version.

3. Examinez les fonctionnalités proposées dans chaque version majeure de la base de données et corrigez les incompatibilités.

   • MySQL 9.7
   • MySQL 8.4
   • MySQL 8.0
   • MySQL 5.7

   Les nouvelles versions majeures présentent des modifications incompatibles qui peuvent vous obliger à modifier le code de l'application, le schéma ou les paramètres de la base de données. Avant de pouvoir mettre à niveau votre instance de base de données, consultez les notes de version de votre version majeure cible afin de déterminer les incompatibilités que vous devez corriger.

   Après la mise à niveau vers une version ultérieure, la valeur par défaut de certaines variables système peut changer. Par exemple, la valeur par défaut de character_set_server dans MySQL 5.6 et MySQL 5.7 est utf8. Lorsque vous passez à MySQL 8.0, la valeur par défaut de character_set_server devient utf8mb4. Pour revenir à utf8, vous devez rétablir manuellement l'ancienne valeur de l'indicateur de base de données. Consultez la page Configurer des options de base de données pour en savoir plus. La plupart des modifications de valeur par défaut sont effectuées par la communauté MySQL (pour en savoir plus, consultez la page Mettre à niveau les valeurs par défaut du serveur).

4. Effectuez la vérification préalable des mises à niveau.

5. Tester la mise à niveau avec une simulation

   Effectuez une simulation du processus de mise à niveau de bout en bout dans un environnement de test avant de mettre à jour la base de données de production. Vous pouvez cloner votre instance pour créer une copie identique des données sur lesquelles tester le processus de mise à niveau.

   En plus de vérifier que la mise à niveau a abouti, exécutez des tests pour vous assurer que l'application se comporte comme prévu sur la base de données mise à niveau.

6. Choisissez une heure de mise à niveau.

   La mise à niveau rend l'instance indisponible pendant un certain temps. Prévoyez la mise à niveau pendant une période où l'activité de la base de données est faible.

Préparer une mise à niveau de version majeure

Avant d'effectuer une mise à niveau, procédez comme suit :

1. Si vous effectuez une mise à niveau de MySQL 8.0 vers MySQL 8.4, tous les nouveaux utilisateurs que vous créez après la mise à niveau utilisent le plug-in d'authentification caching_sha2_password au lieu du plug-in mysql_native_password obsolète. Vous pouvez également mettre à jour les comptes utilisateur existants pour utiliser le plug-in d'authentification caching_sha2_password. Pour modifier vos comptes utilisateur de base de données existants afin qu'ils utilisent le plug-in d'authentification caching_sha2_password, utilisez la commande suivante :

   ALTER USER 'username'@'%'
   IDENTIFIED WITH caching_sha2_password BY 'user_password';
        

   Remplacez username et user_password par les valeurs du compte utilisateur de base de données d'authentification intégrée que vous mettez à jour.

2. Vérifiez l'espace disque et le type de machine de l'instance.

   Les mises à niveau de versions majeures nécessitent davantage d'espace disque et de mémoire pour stocker les tables mises à niveau et le nouveau dictionnaire de données. Un espace disque insuffisant entraîne l'échec de la mise à niveau et le rollback vers la version d'origine. Cloud SQL vous recommande de disposer d'une mémoire minimale de 100 Ko pour chaque table.

Configuration requise pour utiliser MySQL 8.4 ou version ultérieure avec le proxy d'authentification Cloud SQL

Lorsque vous utilisez MySQL 8.4 ou une version ultérieure avec le proxy d'authentification Cloud SQL, vous devez configurer la configuration de la base de données de votre application avec le paramètre de configuration MySQL allowPublicKeyRetrieval=true. Vous devez mettre à niveau vos applications clientes avec cette configuration avant de mettre à niveau la version de la base de données.

Par exemple, si vous utilisez le client mysql, utilisez l'option --get-server-public-key :

mysql -u username -p --get-server-public-key

Si vous utilisez le langage de programmation Java, utilisez ce qui suit :

config.setJdbcUrl("jdbc:mysql://" + dbHost + ":" + dbPort + "/" + dbName);
config.addDataSourceProperty("allowPublicKeyRetrieval", "true");

Évaluer l'état de préparation de votre instance pour la mise à niveau

Cloud SQL vous permet d'effectuer une vérification préalable sur votre instance avant de mettre à niveau une version majeure. Cette vérification préalable est une opération de longue durée (LRO) qui vérifie si votre instance est prête pour une mise à niveau. Il permet de détecter les problèmes potentiels tels que les incompatibilités, les problèmes de configuration ou les problèmes de données avant l'opération de mise à niveau.

Cloud SQL peut exécuter le processus de pré-vérification en parallèle de votre charge de travail. Exécuter la vérification préliminaire avant d'effectuer une mise à niveau de version majeure peut vous aider à éviter un échec de la mise à niveau.

Lorsque vous exécutez la vérification préalable, l'un des événements suivants se produit :

• Aucun problème détecté : la vérification préalable s'est terminée correctement et aucun problème n'a été détecté.
• Problèmes détectés : la vérification préalable s'est terminée, mais elle a détecté des erreurs qui bloqueront votre mise à niveau. Les problèmes doivent être résolus avant la mise à niveau.
• Avertissements détectés : la vérification préalable s'est terminée correctement et a détecté des avertissements. Examinez les avertissements. Nous vous recommandons de résoudre les problèmes avant de procéder à la mise à niveau.

En fonction des résultats de la vérification préalable, vous pouvez procéder à la mise à niveau ou résoudre les problèmes identifiés avant de procéder à la mise à niveau.

Limites

Lorsque vous utilisez la vérification préalable de la mise à niveau de la version majeure, tenez compte des limites suivantes :

• L'état de l'instance doit être défini sur RUNNING.

• L'instance ne doit pas avoir d'opérations bloquantes en attente. Si une opération de blocage est en attente, la vérification préalable génère une erreur avec le message suivant :

  Operation failed because another operation was already in progress. Try
  your request after the current operation is complete.
  

• La vérification préalable doit se connecter à toutes les bases de données de l'instance. Si une base de données est inaccessible, verrouillée ou ne répond pas, la vérification préalable peut échouer ou afficher des erreurs. Nous vous recommandons d'exécuter la vérification préalable lorsque la charge de la base de données est faible.

• La vérification préalable vérifie la compatibilité de la mise à niveau entre des versions majeures consécutives de Cloud SQL pour MySQL. Par exemple, vous pouvez exécuter une vérification préalable pour la mise à niveau entre MySQL 5.7 et MySQL 8.0, la mise à niveau entre MySQL 8.0 et MySQL 8.4, puis la mise à niveau entre MySQL 8.4 et MySQL 9.7.

  La vérification préalable ne permet pas de vérifier la mise à niveau d'une version mineure au sein de la même version majeure. Par exemple, vous ne pouvez pas effectuer de vérification préalable pour une mise à niveau de MySQL 8.0.31 vers la version 8.0.45.

• La pré-vérification est limitée à trois heures. Si l'opération de pré-vérification dépasse la limite de trois heures, le processus expire et est automatiquement annulé.

• Il est possible que l'utilitaire de vérification des mises à niveau du shell MySQL ne détecte pas toutes les incompatibilités lors du processus de vérification préalable. Il est toujours possible que la mise à niveau échoue. Il est également possible que certains avertissements non traités bloquent une mise à niveau vers une version majeure.

Avant de commencer

• Assurez-vous que l'API Cloud SQL Admin est activée pour votre instance.
• Vérifiez que vous disposez de l'autorisation IAM cloudsql.instances.preCheckMajorVersionUpgrade.

Effectuer la vérification préalable

Pour effectuer la vérification préalable de la mise à niveau de version majeure, procédez comme suit :

Examiner les résultats de la vérification préalable

Une fois la vérification préalable terminée, votre instance est prête pour la mise à niveau ou présente des problèmes qui requièrent votre attention.

Prêt pour la mise à niveau

Si la vérification préalable se termine correctement et que le tableau preCheckResponse est vide, cela signifie qu'aucun problème ni avertissement n'a été détecté. Votre instance est prête pour la mise à niveau de la version majeure. Pour continuer, consultez Effectuer la mise à niveau de la version majeure.

Pas prêt pour la mise à niveau

Si la vérification préalable s'est exécutée correctement et que le tableau preCheckResponse contient des problèmes, votre instance n'est pas prête pour la mise à niveau et nécessite une attention particulière. Les problèmes identifiés peuvent ou non bloquer la mise à niveau. Ces problèmes sont signalés dans le preCheckResponse avec les types de messages suivants :

Chaque type de problème inclut un champ message et un champ actions_required. Examinez chaque problème pour comprendre son type et comment le résoudre. Pour en savoir plus sur les problèmes courants et leurs solutions, consultez Erreurs courantes de pré-vérification de la mise à niveau de version majeure.

Une fois les problèmes résolus, réexécutez la vérification préalable pour confirmer que votre instance est prête pour la mise à niveau. Ensuite, procédez à la mise à niveau de votre instance une fois la vérification préalable terminée.

Annuler une vérification préalable à la mise à niveau de version majeure

Vous pouvez annuler une opération de vérification préalable de mise à niveau de version majeure pour Cloud SQL pour MySQL.

Avant de commencer

Pour annuler la vérification préalable de la mise à niveau de la version majeure, vous avez besoin de l'ID de l'opération de vérification préalable. Vous devez spécifier cet ID dans la commande gcloud ou de l'API REST afin que Cloud SQL sache quelle opération annuler.

L'ID d'opération est renvoyé dans le champ name de la réponse.

Vous pouvez également trouver l'ID d'opération en effectuant un appel operations.list sur l'instance Cloud SQL.

Annuler

Vous pouvez utiliser les commandes gcloud ou l'API REST pour annuler une opération de pré-vérification.

Vérifier l'état annulé

Vous pouvez utiliser les commandes gcloud ou l'API REST pour vérifier l'état d'une opération de pré-vérification annulée.

Résoudre les problèmes d'annulation

Effectuer la mise à niveau de la version majeure

Vous pouvez mettre à niveau la version majeure d'une seule instance Cloud SQL, ou mettre à niveau la version majeure d'une instance principale et inclure toutes ses instances répliquées dans la mise à niveau, y compris les instances répliquées en cascade et les instances répliquées interrégionales.

Mettre à niveau la version majeure d'une seule instance

Lorsque vous lancez une opération de mise à niveau pour une seule instance, Cloud SQL effectue les opérations suivantes :

1. Vérifie la configuration de votre instance pour s'assurer qu'elle est compatible avec une mise à niveau.
2. Une fois que Cloud SQL a vérifié la configuration, il rend l'instance indisponible.
3. Effectue une sauvegarde avant la mise à niveau.
4. Effectue la mise à niveau sur l'instance.
5. Rend votre instance disponible.
6. Effectue une sauvegarde post-mise à niveau.

resource "google_sql_database_instance" "default" {
  name             = "mysql-instance"
  region           = "us-central1"
  database_version = "MYSQL_8_0"
  settings {
    tier = "db-n1-standard-2"
  }
}

Lorsque vous placez une demande de mise à niveau sur place, Cloud SQL commence par effectuer une vérification de la mise à niveau. Si Cloud SQL détermine que votre instance n'est pas prête pour une mise à niveau, votre requête de mise à niveau échoue avec un message suggérant comment résoudre le problème. Consultez également la section Résoudre les problèmes liés à la mise à niveau d'une version majeure.

Inclure les instances dupliquées dans la mise à niveau de version majeure

Si votre instance principale comporte des instances répliquées, vous pouvez toutes les inclure dans la mise à niveau. Cloud SQL peut mettre à niveau toutes les instances répliquées de l'instance principale, y compris les instances répliquées interrégionales et les instances répliquées en cascade.

Lorsque vous incluez des instances répliquées dans une mise à niveau de version majeure, Cloud SQL effectue les opérations suivantes :

1. Vérifie la configuration de votre instance principale et de vos instances répliquées pour s'assurer qu'elles sont compatibles avec une mise à niveau.
2. Rend votre instance principale indisponible.
3. Effectue une sauvegarde de l'instance principale avant la mise à niveau.
4. Arrête la réplication pour toutes les instances dupliquées.
5. Effectue la mise à niveau sur l'instance principale.
6. Si la mise à niveau de l'instance principale réussit, l'instance principale redevient disponible et redémarre la réplication.
7. Cloud SQL effectue une sauvegarde de l'instance principale après la mise à niveau.
8. Cloud SQL procède à la mise à niveau de toutes les instances répliquées.

Même si la mise à niveau de la version majeure d'une instance répliquée échoue, l'instance principale reste disponible.

Pour inclure des instances dupliquées dans une mise à niveau de version majeure, vous ne pouvez pas utiliser la consoleCloud de Confiance ou Terraform. Vous ne pouvez utiliser que la gcloud CLI ou l'API Cloud SQL Admin.

Sauvegardes automatiques des mises à niveau

Lorsque vous effectuez une mise à niveau de version majeure, Cloud SQL effectue automatiquement deux sauvegardes à la demande, appelées sauvegardes de mise à niveau :

• La première sauvegarde de mise à niveau est la sauvegarde préalable à la mise à niveau, qui est effectuée immédiatement avant le début de la mise à niveau. Vous pouvez utiliser cette sauvegarde pour restaurer l'état de votre instance de base de données dans la version précédente.
• La deuxième sauvegarde de mise à niveau est la sauvegarde post-mise à niveau, qui est effectuée immédiatement après l'autorisation des nouvelles écritures sur l'instance de base de données mise à niveau.

Lorsque vous affichez la liste de vos sauvegardes, les sauvegardes de mise à niveau sont répertoriées avec le type On-demand. Les sauvegardes de mise à niveau sont libellées afin de pouvoir les identifier rapidement. Par exemple, si vous effectuez une mise à niveau de MySQL 5.7 vers MySQL 8.0, votre sauvegarde préalable est libellée Pre-upgrade backup, MYSQL_5_7 to MYSQL_8_0. et votre sauvegarde post-mise à niveau est libellée Post-upgrade backup, MYSQL_8_0 from MYSQL_5_7.. Si vous effectuez une mise à niveau de MySQL 8.0 vers MySQL 8.4, votre sauvegarde préalable est libellée Pre-upgrade backup, MYSQL_8_0 to MYSQL_8_4. et votre sauvegarde post-mise à niveau est libellée Post-upgrade backup, MYSQL_8_4 from MYSQL_8_0.. Si vous effectuez une mise à niveau de MySQL 8.4 vers MySQL 9.7, votre sauvegarde préalable est libellée Pre-upgrade backup, MYSQL_8_4 to MYSQL_9_7. et votre sauvegarde post-mise à niveau est libellée Post-upgrade backup, MYSQL_9_7 from MYSQL_8_4..

Comme pour les autres sauvegardes à la demande, les sauvegardes de mise à niveau sont conservées jusqu'à ce que vous les supprimiez ou que vous supprimiez l'instance. Si la récupération PITR est activée, vous ne pouvez pas supprimer vos sauvegardes de mise à niveau tant qu'elles sont dans votre période de conservation. Si vous devez supprimer vos sauvegardes de mise à niveau, vous devez désactiver la récupération PITR ou attendre que vos sauvegardes de mise à niveau ne se trouvent plus dans votre durée de conservation.

Terminer la mise à niveau de la version majeure

1. Effectuez des tests de validation.

   Exécutez des tests pour vérifier que votre système mis à niveau fonctionne comme prévu.

2. Facultatif : Mettez à jour les droits d'utilisateur.

   MySQL 8.0 apporte de nouvelles modifications aux systèmes de sécurité et de gestion des comptes. Pour plus d'informations, consultez la section Nouveautés de MySQL 8.0.

   Cloud SQL pour MySQL a adopté ces modifications et amélioré les droits utilisateur associés au rôle cloudsqlsuperuser. Les utilisateurs créés dans la version MySQL 5.7 de l'instance peuvent ne pas disposer des mêmes droits que ceux créés directement dans MySQL 8.0. Par exemple, les utilisateurs qui passent de MySQL 5.7 à MySQL 8.0 ne disposent pas du droit CONNECTION_ADMIN. Par conséquent, ils ne peuvent pas exécuter la commande KILL sur les sessions d'autres utilisateurs. Pour savoir comment mettre à jour les droits des utilisateurs, consultez la procédure décrite dans cette section.

   Si vous passez de MySQL 8.0 à MySQL 8.4, des modifications supplémentaires sont apportées aux droits utilisateur, y compris l'ajout de droits introduits dans MySQL 8.4 et la suppression de droits qui existaient dans MySQL 8.0. Pour en savoir plus, consultez Droits d'utilisateur MySQL 8.4 (cloudsqlsuperuser).

   Vous pouvez mettre à jour les droits des utilisateurs dans MySQL 8.0, MySQL 8.4 ou MySQL 9.7 en procédant comme suit :

   1. Créez un utilisateur doté du rôle cloudsqlsuperuser par défaut.

   2. Utilisez cet utilisateur pour vous connecter à l'instance afin de pouvoir mettre à jour les droits des autres utilisateurs.

      Par exemple, pour vérifier les droits dont disposent les utilisateurs, exécutez la commande suivante :

      SHOW GRANTS for 'admin'@'%',

      Pour accorder des droits à un utilisateur, par exemple le droit d'utiliser la commande KILL pour mettre fin aux connexions, exécutez la commande suivante :

      GRANT CONNECTION_ADMIN ON *.* to 'admin'@'%';

      Pour appliquer le rôle cloudsqlsuperuser à l'utilisateur admin'@'%, exécutez la commande suivante :

      GRANT 'cloudsqlsuperuser' to 'admin'@'%';

3. Facultatif : Créez une sauvegarde.

   Bien que Cloud SQL crée automatiquement une sauvegarde après la mise à niveau de votre instance principale, Cloud SQL vous recommande de créer une sauvegarde vous-même afin de pouvoir récupérer votre base de données si nécessaire.

4. Facultatif : Si vous avez effectué la mise à niveau vers Cloud SQL pour MySQL 8.4 ou MySQL 9.7, mettez également à jour tous vos connecteurs, clients et interfaces système MySQL vers MySQL 8.4 ou MySQL 9.7.

Résoudre un problème de mise à niveau de version majeure

Cloud SQL renvoie un message d'erreur si vous tentez d'effectuer une commande de mise à niveau non valide, par exemple si votre instance contient des indicateurs de base de données non valides pour la nouvelle version.

Si votre requête de mise à niveau échoue, vérifiez sa syntaxe. Si la structure de la requête est valide, tentez de considérer les suggestions suivantes.

Afficher les journaux d'erreurs

Si un problème survient lors d'une requête de mise à niveau valide, Cloud SQL publie les journaux d'erreurs dans projects/PROJECT_ID/logs/cloudsql.googleapis.com%2Fmysql.err. Chaque entrée de journal contient un libellé avec l'identifiant d'instance pour vous aider à identifier l'instance avec l'erreur de mise à niveau. Recherchez ces erreurs de mise à niveau et corrigez-les.

Pour afficher les journaux d'erreurs, utilisez la console Cloud de Confiance by S3NS :

1. Dans la console Cloud de Confiance , accédez à la page Instances Cloud SQL.

   Accéder à la page Instances Cloud SQL

2. Pour ouvrir la page Présentation d'une instance, cliquez sur son nom.

3. Dans le volet Opérations et journaux de la page Présentation de l'instance, cliquez sur le lien Afficher les journaux d'erreurs MySQL.

   La page Explorateur de journaux s'affiche.

4. Affichez les journaux comme suit :

   • Pour regrouper tous les journaux d'erreurs d'un projet, sélectionnez le nom du journal dans le filtre de journal Nom du journal.

   Pour en savoir plus sur les filtres de requête, consultez la page Requêtes avancées.

   • Pour filtrer les journaux d'erreurs de mise à niveau pour une seule instance, saisissez la requête suivante dans la zone Rechercher dans tous les champs, après avoir remplacé DATABASE_ID

   par l'ID du projet suivi du nom de l'instance au format suivant : project_id:instance_name.

   resource.type="cloudsql_database"
   resource.labels.database_id="DATABASE_ID"
   logName : "projects/PROJECT_ID/logs/cloudsql.googleapis.com%2Fmysql.err"

   Par exemple, pour filtrer les journaux d'erreurs de mise à niveau selon une instance nommée shopping-db qui s'exécute dans le projet buylots, utilisez le filtre de requête suivant :

    resource.type="cloudsql_database"
    resource.labels.database_id="buylots:shopping-db"
    logName : "projects/buylots/logs/cloudsql.googleapis.com%2Fmysql.err"

   Vous pouvez examiner tous les journaux signalés au cours d'une période donnée ou les filtrer par niveau de gravité. Une option courante de dépannage peut consister à sélectionner les filtres suivants :

   • Urgence
   • Alerte
   • Critique
   • Erreur

   Vous pouvez rencontrer des problèmes connus lors de la vérification préalable et de la mise à niveau de MySQL 5.7 vers MySQL 8.0. Pour obtenir de l'aide sur la résolution de ces problèmes, consultez Résoudre les problèmes de mise à niveau sur place de la version majeure vers MySQL 8.0.

Opération MVU en cours d'exécution depuis longtemps

Deux tâches sous-jacentes sont associées à une mise à niveau de version majeure :

• Opération de pré-vérification : renvoie une erreur de délai d'expiration si elle n'est pas terminée dans un délai de trois heures.
• Opération de mise à niveau : renvoie une erreur de délai d'expiration si elle n'est pas terminée dans un délai de six heures.

Si l'instance effectue une opération MAJOR_VERSION_UPGRADE en cours pendant une durée plus longue que prévu, examinez les journaux d'erreurs MySQL. Cela peut être dû à des problèmes courants tels que :

• Un grand nombre de tables, de vues ou d'index
• Ressources insuffisantes (processeur ou mémoire, par exemple)
• Transactions majeures bloquant l'arrêt des bases de données pour que le processus de mise à niveau commence. Vous pouvez utiliser la console Cloud de Confiance pour vérifier les processus en cours.

Erreurs courantes de vérification préalable à la mise à niveau de version majeure

Voici les problèmes les plus courants lors des mises à niveau de MySQL 5.7 vers MySQL 8.0 :

• Ajout de nouveaux mots clés réservés, tels que RANKS, GROUPS et FUNCTION, dans les procédures stockées, les déclencheurs et d'autres objets de base de données. Pour en savoir plus, consultez la section Mots clés et mots réservés.
• Caractères UTF non valides dans les définitions de table.
• Transitions XA non validées devant être validées (à l'aide de l'instruction XA COMMIT) ou faire l'objet d'un rollback (à l'aide de l'instruction XA ROLLBACK).
• Contrainte de clé étrangère dans les noms de plus de 64 caractères.
• Type de données spatiales dans un index de colonnes mixte. Pour en savoir plus, consultez Type de données spatiales.

Pour obtenir de l'aide sur la résolution des erreurs et des problèmes connus lors de la vérification préalable de MySQL 5.7 vers MySQL 8.0, consultez Résoudre les problèmes de mise à niveau sur place de la version majeure vers MySQL 8.0. Pour en savoir plus sur les problèmes courants liés à MySQL, consultez les pages Préparer l'installation pour la mise à niveau et Effectuer une mise à niveau vers MySQL 8.0 ?.

Voici les problèmes les plus courants lors des mises à niveau de MySQL 8.0 vers MySQL 8.4 :

• Terminologie de réplication obsolète. Les termes MASTER et SLAVE sont complètement supprimés de MySQL 8.4.

  Si vous utilisez toujours des commandes ou des configurations avec ces termes, vous devez les remplacer ou les supprimer. Pour en savoir plus sur la suppression et le remplacement de ces termes, consultez Nouveautés de MySQL 8.4 par rapport à MySQL 8.0.

Voici les problèmes les plus courants lors des mises à niveau de MySQL 8.4 vers MySQL 9.7 :

• Si vous avez activé cloudsql_vector pour votre instance, vous ne pouvez pas avoir d'index secondaire non vectoriel sur une colonne contenant des embeddings vectoriels Cloud SQL avant la mise à niveau. Le message d'erreur suivant peut s'afficher :

  Non-vector secondary indexes are disallowed on vector columns when cloudsql_vector is enabled.

  Pour résoudre ce problème, supprimez l'index secondaire avant de passer à MySQL 9.7.

• Vous disposez d'embeddings vectoriels dans votre base de données Cloud SQL 8.4, mais vous avez défini cloudsql_vector sur off. Lors de la mise à niveau vers MySQL 9.7, toutes les données vectorielles sont migrées vers le format MySQL de la communauté au lieu du format VARBINARY utilisé par Cloud SQL pour MySQL 8.4 et les bases de données antérieures. Pour vous assurer que les données vectorielles sont migrées correctement, vous pouvez définir l'option cloudsql_vector sur on et procéder à la mise à niveau vers MySQL 9.7. Le processus de mise à niveau migre vos données vectorielles vers le format communautaire. Vous pouvez également conserver l'option cloudsql_vector définie sur off et supprimer manuellement les données vectorielles de votre base de données MySQL 8.4 avant de procéder à la mise à niveau.
• Il vous reste des comptes utilisateur de base de données intégrés qui utilisent le plug-in mysql_native_password. Le plug-in est complètement supprimé de Cloud SQL pour MySQL 9.7. Si des comptes utilisateur utilisent le plug-in mysql_native_password, ils ne peuvent pas se connecter à votre base de données. Vous devez modifier tous les comptes restants pour utiliser le plug-in caching_sha2_password avant de passer à Cloud SQL pour MySQL 9.7.

Restaurer l'instance principale vers la version majeure précédente

Si votre système de base de données mis à niveau ne fonctionne pas comme prévu, vous devrez peut-être restaurer la version précédente de l'instance principale. Pour ce faire, vous devez restaurer votre sauvegarde préalable à la mise à niveau sur une instance de récupération Cloud SQL, qui est une nouvelle instance exécutant la version préliminaire.

Pour restaurer une instance principale à la version précédente, procédez comme suit :

1. Identifiez votre sauvegarde préalable à la mise à niveau.

   Consultez la section Sauvegardes automatiques.

2. Créez une instance de récupération.

   Créez une instance Cloud SQL à l'aide de la version majeure en cours d'exécution par Cloud SQL lors de la sauvegarde préalable. Définissez les options et les paramètres d'instance utilisés par l'instance d'origine.

3. Restaurez votre sauvegarde préalable à la mise à niveau.

   Restaurez votre sauvegarde préalable à la mise à niveau sur l'instance de récupération. Cette opération peut prendre plusieurs minutes.

4. Ajoutez vos instances dupliquées avec accès en lecture.

   Si vous utilisez des instances répliquées avec accès en lecture, ajoutez-les individuellement.

5. Connectez votre application.

   Après avoir récupéré votre système de base de données, mettez à jour votre application avec les détails de l'instance de récupération et de ses instances dupliquées avec accès en lecture. Vous pouvez reprendre la diffusion du trafic sur la version antérieure à la mise à niveau de votre base de données.

Limites

Cette section répertorie les limites de la mise à niveau de version majeure sur place.

• Vous ne pouvez pas effectuer de mise à niveau de version majeure sur place sur une instance répliquée externe.
• La mise à niveau des instances de MySQL 5.7 vers MySQL 8.0 comportant plus de 512 000 tables peut prendre beaucoup de temps et arriver à expiration.
• La mise à niveau des instances de MySQL 8.0 vers MySQL 8.4 comportant plus de 512 000 tables peut prendre beaucoup de temps et arriver à expiration.

• Lors de la mise à niveau de MySQL 8.0 vers MySQL 8.4, si vous avez mis à niveau une instance répliquée vers MySQL 8.4, mais pas l'instance principale, vous pouvez créer un compte utilisateur sur une instance principale non mise à niveau avec le plug-in d'authentification mysql_native_password obsolète. Pour éviter ce problème, veillez à mettre à niveau l'instance principale immédiatement après la mise à niveau des instances répliquées, ou à créer uniquement des comptes utilisateur sur l'instance principale à l'aide de la commande suivante.

  CREATE USER 'USERNAME'@'%' IDENTIFIED WITH caching_sha2_password BY 'PASSWORD';

  Remplacez USERNAME et PASSWORD par les valeurs appropriées.

Questions fréquentes

Les questions suivantes peuvent vous être posées lors de la mise à niveau de la version majeure de la base de données.

Mon instance est-elle indisponible lors d'une mise à niveau ?

Oui. Votre instance reste indisponible pendant un certain temps pendant que Cloud SQL effectue la mise à niveau.

Combien de temps dure une mise à niveau ?

La mise à niveau d'une seule instance prend généralement moins de 10 minutes. Si la configuration de votre instance utilise un petit nombre de processeurs virtuels ou peu de mémoire, votre mise à niveau peut prendre plus de temps.

Si votre instance héberge trop de bases de données ou de tables, ou si vos bases de données sont très volumineuses, la mise à niveau peut prendre des heures, voire expirer, car la durée totale de mise à niveau correspond au nombre d'objets dans vos bases de données. Si vous devez mettre à niveau plusieurs instances, le temps de mise à niveau augmente proportionnellement. Si vous incluez des instances répliquées dans votre mise à niveau, l'opération peut prendre jusqu'à une heure, selon le nombre d'instances répliquées de votre instance principale.

Puis-je surveiller chaque étape de mon processus de mise à niveau ?

Bien que Cloud SQL vous permette de vérifier si une opération de mise à niveau est toujours en cours, vous ne pouvez pas suivre les étapes de chaque mise à niveau.

Puis-je annuler ma mise à niveau après son lancement ?

Non, vous ne pouvez pas annuler une mise à niveau une fois celle-ci démarrée. En cas d'échec de la mise à niveau, Cloud SQL récupère automatiquement votre instance sur la version précédente.

Qu'advient-il de mes paramètres lors d'une mise à niveau ?

Lorsque vous effectuez une mise à niveau de version majeure sur place, Cloud SQL conserve vos paramètres de base de données, y compris le nom de l'instance, l'adresse IP, les valeurs des options configurées explicitement et les données utilisateur. Toutefois, la valeur par défaut des variables système peut changer. Par exemple, la valeur par défaut de l'option character_set_server dans MySQL 5.7 est utf8. Lorsque vous passez à MySQL 8.0, la valeur par défaut de l'option devient utf8mb4. Pour revenir à utf8, rétablissez la valeur précédente de l'option.

Pour en savoir plus, consultez Configurer des indicateurs de base de données. Si une option ou une valeur spécifique n'est plus acceptée dans votre version cible, Cloud SQL le supprime automatiquement lors de la mise à niveau.

Que puis-je faire si la réplication s'interrompt après la mise à niveau d'une instance répliquée ?

Si la réplication s'interrompt après la mise à niveau d'une instance répliquée, Cloud SQL effectue un rollback de l'instance répliquée vers la version majeure de MySQL de l'instance principale. Vous pouvez à nouveau mettre à jour l'instance répliquée, mais si le problème persiste, la réplication peut s'interrompre à nouveau. C'est pourquoi nous vous recommandons d'inclure vos instances répliquées lorsque vous effectuez une mise à niveau de version majeure, au lieu de mettre à niveau chaque instance répliquée séparément.

Si l'instance répliquée n'est pas restaurée vers la même version majeure que votre instance principale, deux options s'offrent à vous :

1. Supprimez l'instance répliquée interrompue, créez-en une nouvelle et mettez-la à niveau.

   Si la mise à niveau échoue à nouveau, cela est probablement dû à des modifications incompatibles ajoutées à l'instance principale lors de sa mise à niveau. Dépannez la mise à niveau pour localiser le problème, corrigez l'instance principale et essayez de mettre à niveau l'instance répliquée. Pour en savoir plus, consultez Dépannage.

2. Mettez à niveau l'instance principale.

   Si le thread de l'instance répliquée ne fonctionne pas, l'opération de mise à niveau sur l'instance principale recrée les instances répliquées.

Pourquoi mon instance répliquée mise à niveau est-elle revenue à la version majeure précédente ?

Si une mise à niveau échoue, l'instance répliquée fait l'objet d'un rollback vers la version de l'instance principale. Vous pouvez de nouveau mettre à niveau l'instance répliquée, mais si le problème persiste, vous pouvez consulter le journal mysql.err de l'instance répliquée pour trouver la source. Recherchez des mots clés tels que [REPL]... failed executing transaction.... end_log_pos...; Failure Reason.

Si le message d'erreur contient Access denied for AuthId.... avec des modifications apportées aux droits d'utilisateur, il est probable qu'une requête exécutée à l'aide des droits d'utilisateur MySQL 5.7 sur les schémas mysql et sys puisse échouer en raison des modifications apportées aux systèmes de sécurité et de gestion des comptes dans MySQL 8.0. Pour résoudre ce problème, vous devez arrêter les requêtes sur l'instance principale avant de la mettre à niveau vers la nouvelle version, puis relancer la mise à niveau de l'instance répliquée. Cloud SQL vous recommande d'arrêter temporairement toutes ces requêtes dans l'instance principale avant de passer à la nouvelle version, car cela peut entraîner un problème similaire.

Si vous ne voyez pas le motif de l'échec, tel que Access denied for AuthID.... dans les journaux MySQL, votre problème est probablement dû à de nouvelles données incompatibles qui ont pu être ajoutées à l'instance principale après la mise à niveau de l'instance répliquée. Consultez la section Préparer une mise à niveau de version majeure pour savoir comment résoudre les problèmes d'incompatibilité avant de procéder à une nouvelle mise à niveau.

Étapes suivantes

• Découvrez les options de connexion à une instance.
• Apprenez-en plus sur l'importation et l'exportation de données.
• Apprenez à définir des indicateurs de base de données.