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.

L'utilitaire mysql_upgrade est utilisé par Cloud SQL pour l'opération de mise à niveau sur place MySQL.

Planifier une mise à niveau de version majeure

  1. 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 :
      2. 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 :

    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 :

    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.

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

    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 à la valeur utf8, vous devez rétablir manuellement l'ancienne valeur de l'option 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).

  3. Effectuez une vérification préalable des mises à niveau de MySQL 5.7 vers la version 8.0.

    Effectuez une vérification préalable avant d'exécuter les mises à niveau de MySQL 5.7 vers la version 8.0. Vous pouvez vous servir de l'utilitaire de vérification des mises à niveau dans le shell MySQL. Si des problèmes sont détectés lors de la vérification préalable, corrigez-les avant de procéder à la mise à niveau. Cloud SQL ne permet pas de réaliser une vérification préalable lors de la mise à niveau d'une version majeure. Toute tentative de mise à niveau d'une instance ayant échoué à la vérification préalable peut également échouer.

  4. Vérifiez l'espace disque et les types de machines de l'instance.

    Une mise à niveau de version majeure nécessite des ressources supplémentaires, telles que de l'espace disque, pour stocker les tables mises à niveau. Si l'espace disque est insuffisant, la mise à niveau échoue et effectue un rollback. Pour une mise à niveau de MySQL 5.7 vers la version 8.0, de la mémoire supplémentaire est nécessaire pour convertir les anciennes métadonnées vers le nouveau dictionnaire de données. Avant d'exécuter une mise à niveau de version majeure, assurez-vous de disposer de plus de 100 Ko de mémoire pour chaque table. Vous pouvez augmenter temporairement la mémoire en modifiant le type de machine.

  5. Vérifier les modifications des autorisations utilisateur dans MySQL 8.0

    Cloud SQL pour MySQL version 8.0 utilise un indicateur appelé partial_revokes, qui est défini sur ON par défaut. Contrairement à MySQL 5.7, cet indicateur empêche l'utilisation de caractères génériques dans les commandes GRANT de base de données. Pour vous assurer que les utilisateurs de la base de données ont accès aux schémas de base de données appropriés, modifiez les droits des utilisateurs de la base de données avant de passer à MySQL 8.0. Mettez à jour les droits de l'utilisateur pour utiliser le nom complet des schémas de base de données requis au lieu d'utiliser des caractères génériques.

    Pour en savoir plus sur le fonctionnement de cet indicateur dans MySQL 8.0, consultez la section partial_revokes dans MySQL 8.0.

  6. Tester la mise à niveau avec une simulation

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

  7. 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. Pour les mises à niveau de MySQL 5.7 vers la version 8.0 UNIQUEMENT : examinez et corrigez les problèmes incompatibles détectés lors du processus de vérification préalable. Voici les problèmes les plus courants :

    1. Ajout de nouveaux mots clés réservés, tels que RANKS, GROUPS, FUNCTION, dans les procédures stockées, les déclencheurs, etc. Pour en savoir plus, consultez la section Mots clés et mots réservés.
    2. Caractères UTF non valides dans les définitions de table.
    3. 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).
    4. Contrainte de clé étrangère dans les noms de plus de 64 caractères.
    5. Type de données spatiales dans l'index de colonnes mixte. Pour en savoir plus, consultez la section Type de données spatiales.

    Pour en savoir plus, consultez les pages Préparer l'installation pour la mise à niveau et Effectuer une mise à niveau vers MySQL 8.0 ?.

  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. Le manque d'espace disque requis 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 000 pour chaque table.

    Remarque : Vous pouvez augmenter temporairement la mémoire en modifiant le type de machine avant d'exécuter la mise à niveau de la version majeure. Pour en savoir plus, consultez la section Modifier le type de machine.

  3. Mettez à niveau vos instances répliquées avec accès en lecture.

    Si vous utilisez des instances répliquées avec accès en lecture, vous devez d'abord les mettre à niveau avant de mettre à niveau l'instance principale. Si l'instance répliquée est mise à niveau, mais que l'instance principale ne l'est pas, la réplication peut s'interrompre si l'instance principale utilise des instructions ou des fonctions qui ne sont plus compatibles avec une version ultérieure de MySQL utilisée par l'instance répliquée. Pour éviter ce type de problème, Cloud SQL vous recommande d'effectuer les opérations suivantes :

    1. Mettez à niveau l'instance principale immédiatement après la mise à niveau des instances répliquées.
    2. Évitez d'exécuter des requêtes incompatibles avec la nouvelle version sur l'instance principale tant que la mise à niveau n'est pas terminée.
    3. (Facultatif) Suspendez toutes les instructions WRITE sur l'instance principale jusqu'à la fin de la mise à niveau.
    4. (Facultatif) Supprimez toutes les instances répliquées avant de mettre à niveau l'instance principale et recréez les instances répliquées une fois la mise à niveau terminée.

    Si la réplication s'interrompt, l'instance répliquée fait l'objet d'un rollback vers la version de l'instance principale. Vous pouvez à nouveau mettre à jour l'instance répliquée, mais si le problème persiste, consultez les questions fréquentes.

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

Lorsque vous lancez une opération de mise à niveau, Cloud SQL vérifie d'abord la configuration de votre instance pour s'assurer qu'elle est compatible avec une mise à niveau. Après avoir vérifié votre configuration, Cloud SQL rend votre instance indisponible, effectue une sauvegarde préalable à la mise à niveau, effectue la mise à niveau, relance votre instance, puis effectue une sauvegarde post-mise à niveau.

Lorsque vous effectuez une mise à niveau vers MySQL 8.0, Cloud SQL provisionne automatiquement votre instance sur la version mineure par défaut.

Console

  1. Dans Google Cloud Console, 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. Cliquez sur Modifier.
  4. Dans la section Informations sur l'instance, cliquez sur le bouton Mettre à niveau, puis confirmez que vous souhaitez accéder à la page de mise à niveau.
  5. Sur la page Choisir une version de base de données, cliquez sur le champ Version de la base de données pour la mise à niveau, puis sélectionnez l'une des versions majeures disponibles.
  6. Cliquez sur Continuer.
  7. Dans la zone ID d'instance, saisissez le nom de l'instance, puis cliquez sur le bouton Démarrer la mise à niveau.
L'exécution de la requête prend plusieurs minutes.

Vérifiez que la version majeure de la base de données mise à niveau apparaît sous le nom de l'instance sur la page Présentation de l'instance.

gcloud

  1. Lancez la mise à niveau.

    Exécutez la commande gcloud sql instances patch avec l'option --database-version.

    Avant d'exécuter la commande, remplacez les éléments suivants :

    • INSTANCE_NAME : nom de l'instance
    • DATABASE_VERSION : énumération de la version majeure de la base de données, qui doit être postérieure à la version actuelle. Spécifiez une version de base de données pour une version majeure disponible en tant que cible de mise à niveau pour l'instance. Vous pouvez obtenir cette énumération comme première étape de la planification de la mise à niveau. Si vous avez besoin de la liste complète des énumérations de versions de bases de données, consultez SqlDatabaseEnums.
    gcloud sql instances patch INSTANCE_NAME \
--database-version=DATABASE_VERSION

    Les mises à niveau de versions majeures prennent plusieurs minutes. Il est possible qu'un message indique que l'opération prend plus de temps que prévu. Vous pouvez ignorer ce message ou exécuter la commande gcloud sql operations wait pour l'ignorer.

  2. Obtenez le nom de l'opération de mise à niveau.

    Exécutez la commande gcloud sql operations list avec l'option --instance.

    Avant d'exécuter la commande, remplacez la variable INSTANCE_NAME par le nom de l'instance. 

    gcloud sql operations list --instance=INSTANCE_NAME

  3. Surveillez l'état de la mise à niveau.

    Exécutez la commande gcloud sql operations describe.

    Avant d'exécuter la commande, remplacez la variable OPERATION par le nom de l'opération de mise à niveau récupérée à l'étape précédente. 

    gcloud sql operations describe OPERATION

REST v1

  1. Démarrez la mise à niveau sur place.

    Exécutez une requête PATCH avec la méthode instances:patch.

    Avant d'utiliser les données de requête ci-dessous, remplacez les variables suivantes :

    • PROJECT_ID : ID du projet
    • INSTANCE_NAME : nom de l'instance

    Méthode HTTP et URL :

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

    Corps JSON de la requête : 

    {
  "databaseVersion": DATABASE_VERSION
}

    Remplacez DATABASE_VERSION par l'énumération de la version majeure de la base de données, qui doit être postérieure à la version actuelle. Spécifiez une version de base de données pour une version majeure disponible en tant que cible de mise à niveau pour l'instance. Vous pouvez obtenir cette énumération comme première étape de la planification de la mise à niveau. Si vous avez besoin de la liste complète des énumérations de versions de bases de données, consultez SqlDatabaseVersion.

  2. Obtenez le nom de l'opération de mise à niveau.

    Exécutez une requête GET avec la méthode operations.list après avoir remplacé PROJECT_ID par l'ID du projet.

    Méthode HTTP et URL :

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations

  3. Surveillez l'état de la mise à niveau.

    Exécutez une requête GET avec la méthode operations.get après avoir remplacé les variables suivantes :

    • PROJECT_ID : ID du projet
    • OPERATION_NAME : nom de l'opération de mise à niveau récupérée à l'étape précédente.

    Méthode HTTP et URL : 

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operation/OPERATION_NAME

Terraform

Pour mettre à jour la version de la base de données, utilisez une ressource Terraform et le fournisseur Terraform pour Google Cloud, version 4.34.0 ou ultérieure.

resource "google_sql_database_instance" "instance" {
  name             = "mysql-instance"
  region           = "us-central1"
  database_version = "MYSQL_8_0"
  settings {
    tier = "db-n1-standard-2"
  }
  # set `deletion_protection` to true, will ensure that one cannot accidentally delete this instance by
  # use of Terraform whereas `deletion_protection_enabled` flag protects this instance at the GCP level.
  deletion_protection = false
}

Appliquer les modifications

Pour appliquer votre configuration Terraform dans un projet Google Cloud, suivez les procédures des sections suivantes.

Préparer Cloud Shell

  1. Lancez Cloud Shell.

  2. Définissez le projet Google Cloud par défaut dans lequel vous souhaitez appliquer vos configurations Terraform.

    Vous n'avez besoin d'exécuter cette commande qu'une seule fois par projet et vous pouvez l'exécuter dans n'importe quel répertoire.

    export GOOGLE_CLOUD_PROJECT=PROJECT_ID

    Les variables d'environnement sont remplacées si vous définissez des valeurs explicites dans le fichier de configuration Terraform.

Préparer le répertoire

Chaque fichier de configuration Terraform doit avoir son propre répertoire (également appelé module racine).

  1. Dans Cloud Shell, créez un répertoire et un nouveau fichier dans ce répertoire. Le nom du fichier doit comporter l'extension .tf, par exemple main.tf. Dans ce tutoriel, le fichier est appelé main.tf. 
    mkdir DIRECTORY && cd DIRECTORY && touch main.tf

  2. Si vous suivez un tutoriel, vous pouvez copier l'exemple de code dans chaque section ou étape.

    Copiez l'exemple de code dans le fichier main.tf que vous venez de créer.

    Vous pouvez également copier le code depuis GitHub. Cela est recommandé lorsque l'extrait Terraform fait partie d'une solution de bout en bout.

  3. Examinez et modifiez les exemples de paramètres à appliquer à votre environnement.
  4. Enregistrez les modifications.
  5. Initialisez Terraform. Cette opération n'est à effectuer qu'une seule fois par répertoire. 
    terraform init

    Vous pouvez également utiliser la dernière version du fournisseur Google en incluant l'option -upgrade : 

    terraform init -upgrade

Appliquer les modifications

  1. Examinez la configuration et vérifiez que les ressources que Terraform va créer ou mettre à jour correspondent à vos attentes : 
    terraform plan

    Corrigez les modifications de la configuration si nécessaire.

  2. Appliquez la configuration Terraform en exécutant la commande suivante et en saisissant yes lorsque vous y êtes invité : 
    terraform apply

    Attendez que Terraform affiche le message "Apply completed!" (Application terminée).

  3. Ouvrez votre projet Google Cloud pour afficher les résultats. Dans la console Google Cloud, accédez à vos ressources dans l'interface utilisateur pour vous assurer que Terraform les a créées ou mises à jour.

Supprimer les modifications

Pour supprimer vos modifications, procédez comme suit :

  1. Pour désactiver la protection contre la suppression, définissez l'argument deletion_protection sur false dans le fichier de configuration Terraform. 
    deletion_protection =  "false"
  2. Appliquez la configuration Terraform mise à jour en exécutant la commande suivante et en saisissant yes lorsque vous y êtes invité : 
    terraform apply

  1. Supprimez les ressources précédemment appliquées à votre configuration Terraform en exécutant la commande suivante et en saisissant yes à la requête :

    terraform destroy

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.

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

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

Une fois la mise à niveau de l'instance principale terminée, procédez comme suit :

  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.

    Si vous êtes passé à MySQL 8.0, notez que MySQL a modifié les systèmes de sécurité et de gestion des comptes. Pour plus d'informations, consultez la section Nouveautés de MySQL 8.0.

    Il est possible que les utilisateurs créés dans la version MySQL 5.7 de l'instance ne disposent pas des mêmes droits que ceux créés directement dans MySQL 8.0. Par exemple, un utilisateur ayant effectué une mise à niveau à partir de MySQL 5.7 peut ne pas disposer des droits CREATE ROLE et DROP ROLE, car ces droits n'existaient pas dans MySQL 5.7. Cloud SQL vous recommande de réinitialiser les droits d'utilisateur après la mise à niveau des versions afin de résoudre tout problème lié aux droits d'utilisateur.

    Pour réinitialiser les droits d'utilisateur, procédez comme suit :

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

    2. Utilisez l'utilisateur créé pour révoquer tous les droits précédents d'un utilisateur mis à niveau avec la commande suivante :

      REVOKE ALL PRIVILEGES ON *.* FROM user@host

    3. Accordez les droits attendus à l'utilisateur mis à niveau.

  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.

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 options 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 de mise à niveau

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, procédez comme suit :

  1. Dans Google Cloud Console, 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"

Restaurer 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. 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 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 utilisiez des instances dupliqué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 la version 8.0 comportant plus de 512 000 tables peut prendre beaucoup de temps et arriver à expiration.

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 de mise à niveau correspond au nombre d'objets dans vos bases de données. Si vous devez mettre à niveau plusieurs instances, le temps total de mise à niveau augmente proportionnellement.

Puis-je surveiller chaque étape de mon processus de mise à niveau ?
Bien que Cloud SQL vous permet 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.

Pour en savoir plus, consultez la section Configurer des options 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 de l'instance répliquée ?
Si la réplication s'interrompt après la mise à niveau de l'instance répliquée, celle-ci fait l'objet d'un rollback vers la version MySQL de l'instance principale. Vous pouvez de nouveau mettre à niveau l'instance répliquée, mais si le problème persiste, la réplication peut s'interrompre à nouveau.

Si l'instance répliquée ne fait pas l'objet d'un rollback, 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 la section Dépannage.

  2. Mettez à niveau l'instance principale.

    La mise à niveau sur l'instance principale recrée les instances répliquées si le thread de l'instance répliquée ne fonctionne pas.

Pourquoi mon instance répliquée mise à niveau est-elle revenue à l'ancienne version ?

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