Dépannage

Exécutez la commande gcloud sql operations list pour répertorier toutes les opérations pour l'instance Cloud SQL donnée.

Recherchez les utilisateurs dans les journaux et filtrez-les par texte. Vous devrez peut-être consulter les journaux d'audit pour obtenir des informations personnelles. Les fichiers journaux pertinents incluent :

• cloudsql.googlapis.com/mysql-general.log
• cloudsql.googleapis.com/mysql.err
• Si Cloud Audit Logs est activé et que vous disposez des autorisations nécessaires pour les afficher, il est possible que cloudaudit.googleapis.com/activity soit également disponible.

Une fois qu'une instance est définitivement supprimée, la récupération de données est impossible. Toutefois, si l'instance est restaurée, ses sauvegardes sont également restaurées. Pour en savoir plus sur la récupération d'une instance supprimée, consultez la section Sauvegardes de récupération.

Si vous avez exporté les données, créez une instance puis importez les données pour recréer la base de données. Les données exportées sont écrites dans Cloud Storage, d'où sont lues les données importées.

Si vous devez vraiment annuler l'opération, vous pouvez demander au service client d'effectuer une opération force restart sur l'instance.

Créez les utilisateurs de la base de données avant d'effectuer une restauration à partir du fichier de vidage SQL.

Pour conserver les sauvegardes indéfiniment, vous pouvez créer des sauvegardes à la demande, car elles ne sont pas supprimées de la même manière que les sauvegardes automatiques. Les sauvegardes à la demande sont conservées indéfiniment, c'est-à-dire jusqu'à leur suppression ou la suppression de l'instance à laquelle elles appartiennent. En revanche, comme les sauvegardes de ce type ne sont pas automatiquement supprimées, elles peuvent affecter la facturation.

Vous essayez d'annuler une opération d'importation ou d'exportation terminée, échouée ou annulée. Si l'opération est en cours d'exécution, vous pouvez l'annuler.

Cloud SQL n'est pas compatible avec l'annulation de l'opération, car son type d'opération est différent de IMPORT ou EXPORT.

Cloud SQL ne peut pas annuler l'opération d'importation ou d'exportation pour le moment. Réessayez dans quelques secondes. Si le problème persiste, contactez l'assistance Google Cloud.

Si possible, supprimez toutes les entrées Authorized Networks de l'instance Cloud SQL. Sinon, créez une instance dupliquée sans aucune entrée Authorized Networks.

Vous essayez d'utiliser la console Google Cloud pour cloner une instance avec une adresse IP privée, mais vous n'avez pas spécifié la plage d'adresses IP allouée que vous souhaitez utiliser et l'instance source n'est pas créée avec la plage spécifiée. Par conséquent, l'instance clonée est créée dans une plage aléatoire.

Utilisez gcloud pour cloner l'instance et indiquez une valeur pour le paramètre
--allocated-ip-range-name. Pour en savoir plus, consultez la section Cloner une instance avec une adresse IP privée.

• Instabilité du réseau.
• Absence de réponse aux commandes keep-alive TCP (le client ou le serveur ne répond pas ou est peut-être surchargé)
• La durée de vie de la connexion au moteur de base de données a été dépassée et le serveur met fin à la connexion.

Les applications doivent tolérer les défaillances du réseau et se baser sur les bonnes pratiques telles que le regroupement des connexions et les nouvelles tentatives. La plupart des regroupements de connexions interceptent ces erreurs lorsque cela est possible. Sinon, l'application doit réessayer ou échouer sans occasionner de blocage.

Pour effectuer de nouvelles tentatives de connexion, nous vous recommandons les techniques suivantes :

1. Intervalle exponentiel entre les tentatives Augmentez l'intervalle de temps entre chaque nouvelle tentative, de manière exponentielle.
2. Ajoutez également un intervalle aléatoire.

La combinaison de ces techniques permet de réduire les limitations.

Les certificats client ont expiré ou le chemin d'accès aux certificats est incorrect.

Générez à nouveau les certificats en les recréant.

• La taille de la plage d'adresses IP allouée à la connexion de service privé est inférieure à /24.
• La taille de la plage d'adresses IP allouée pour la connexion de service privé est trop petite pour le nombre d'instances Cloud SQL.
• La taille requise pour la plage d'adresses IP allouée sera plus importante si les instances sont créées dans plusieurs régions. Voir Taille de la plage allouée

Pour résoudre ce problème, vous pouvez étendre la plage d'adresses IP allouée existante ou allouer une plage d'adresses IP supplémentaire à la connexion de service privée. Pour plus d'informations, consultez la section Allouer une plage d'adresses IP.

Si vous avez utilisé l'option --allocated-ip-range-name lors de la création de l'instance Cloud SQL, vous ne pouvez étendre que la plage d'adresses IP spécifiée.

Si vous allouez une nouvelle plage, assurez-vous que l'allocation ne chevauche aucune allocation existante.

Après avoir créé une nouvelle plage d'adresses IP, mettez à jour l'appairage de VPC à l'aide de la commande suivante :

gcloud services vpc-peerings update \
--service=servicenetworking.googleapis.com \
--ranges=OLD_RESERVED_RANGE_NAME,NEW_RESERVED_RANGE_NAME \
--network=VPC_NETWORK \
--project=PROJECT_ID \
--force
    

Si vous développez une allocation existante, veillez à effectuer uniquement une opération d'augmentation de la plage d'allocation et non à la réduire. Par exemple, si l'allocation d'origine était 10.0.10.0/24, la nouvelle allocation doit être définie au mininmum sur 10.0.10.0/23.

En règle générale, si vous commencez par utiliser une allocation /24, il est conseillé de réduire le /masque d'une unité pour chaque condition (groupe de type d'instances supplémentaire, région supplémentaire). Par exemple, si vous essayez de créer les deux groupes de types d'instances sur la même allocation, passer de /24 à /23 est suffisant.

Après avoir étendu une plage d'adresses IP existante, mettez à jour l'appairage de VPC à l'aide de la commande suivante :

gcloud services vpc-peerings update \
--service=servicenetworking.googleapis.com \
--ranges=RESERVED_RANGE_NAME \
--network=VPC_NETWORK \
--project=PROJECT_ID
    

Exportez uniquement les données dont vous avez besoin à l'aide du format CSV.

Utilisez le déchargement des exportations. En règle générale, lors du déchargement des exportations, au lieu d'exécuter une exportation sur l'instance source, Cloud SQL lance une instance de déchargement pour effectuer l'exportation. Le déchargement des exportations présente plusieurs avantages, y compris une amélioration des performances sur l'instance source et le déblocage des opérations d'administration pendant l'exportation. Avec le déchargement des exportations, la latence totale peut augmenter en fonction du temps nécessaire à l'affichage de l'instance de déchargement. En règle générale, la latence n'est pas significative pour les exportations de taille raisonnable. Toutefois, si votre exportation est suffisamment petite, vous pouvez constater une augmentation de la latence.

Vous pouvez créer votre propre système d'exportation automatisé à l'aide de produits Google Cloud tels que Cloud Scheduler, Pub/Sub et les fonctions Cloud Run, de manière semblable à cet article sur l'automatisation des sauvegardes.

Assurez-vous que l'instance principale externe est disponible. Vous pouvez également modifier les valeurs des options net_read_timeout et net_write_timeout sur l'instance source afin d'arrêter l'erreur. Pour en savoir plus sur les valeurs autorisées pour ces options, consultez la page Configurer des options de base de données.

Pour en savoir plus sur l'utilisation des options de mysqldump pour la migration des importations gérées, consultez la section Options de synchronisation initiales autorisées et par défaut.

Assurez-vous que les options de réplication telles que binlog-do-db, binlog-ignore-db, replicate-do-db ou replicate-ignore-db ne sont pas définies de manière conflictuelle.

Exécutez la commande show master status sur l'instance principale pour afficher les paramètres actuels.

• Vérifiez les métriques de réplication de votre instance répliquée dans la section "Cloud Monitoring" de la console Google Cloud.
• Les erreurs du thread d'E/S MySQL ou du thread SQL sont disponibles dans Cloud Logging dans les fichiers mysql.err log.
• Cette erreur peut également se produire lors de la connexion à l'instance dupliquée. Exécutez la commande SHOW SLAVE STATUS et vérifiez les champs suivants dans le résultat :
  • Slave_IO_Running
  • Slave_SQL_Running
  • Last_IO_Error
  • Last_SQL_Error

Augmentez la taille du disque de l'instance dupliquée. Vous pouvez augmenter manuellement la taille du disque ou activer l'augmentation automatique de l'espace de stockage.

Créez un fichier de dump avec les options appropriées, puis configurez l'instance répliquée externe en utilisant ce fichier.

1. Connectez-vous à votre client mysql via une instance Compute Engine.
2. Exécutez mysqldump et utilisez les options --master-data=1 et --flush-privileges.

   Important : n'incluez pas l'option --set-gtid-purged=OFF.

   En savoir plus.

3. Assurez-vous que le fichier de dump que vous venez de créer contient la ligne SET @@GLOBAL.GTID_PURGED='...'.
4. Importez le fichier de dump dans un bucket Cloud Storage, puis configurez l'instance répliquée en utilisant ce fichier.

Modifiez l'instance en augmentant la taille de la machine afin d'obtenir plus de processeurs et de mémoire.

Fermez les opérations inutilisées. Vérifiez l'utilisation du processeur et de la mémoire de votre instance Cloud SQL pour vous assurer que de nombreuses ressources sont disponibles. Le meilleur moyen de s'assurer de la présence d'un nombre maximal de ressources pour l'opération d'importation consiste à redémarrer l'instance avant de lancer l'importation.

Un redémarrage :

• ferme toutes les connexions ;
• met fin à toutes les tâches susceptibles de consommer des ressources.

Créez les utilisateurs de la base de données avant de l'importer.

Solutions possibles

Ajoutez la ligne suivante au début du fichier de dump :

SET FOREIGN_KEY_CHECKS=0;
  

Ajoutez également cette ligne à la fin du fichier de dump :

SET FOREIGN_KEY_CHECKS=1;
  

Ces paramètres désactivent les vérifications de l'intégrité des données pendant que l'opération d'importation est en cours, et les réactivent une fois les données chargées. Cela n'affecte pas l'intégrité des données de la base de données, car elles ont déjà été validées lors de la création du fichier de vidage.

Par exemple, un utilisateur a été supprimé, mais vous ne pouvez pas savoir qui est à l'origine de cette opération. Les journaux indiquent que l'opération a commencé, mais ne fournissent pas plus d'informations. Pour obtenir des informations détaillées et des informations permettant d'identifier personnellement l'utilisateur telles que celles-ci, vous devez activer la journalisation d'audit.

Connectez-vous à la base de données et exécutez les commandes suivantes pour en savoir plus sur chaque type :

SHOW VARIABLES LIKE 'innodb_log_file%';

SELECT ROUND(SUM(LENGTH(argument)/POW(1024,2),2)
AS GB from mysql.general_log;

SHOW BINARY LOGS;
    

Pour télécharger les journaux au format JSON, procédez comme suit :

gcloud logging read \
"resource.type=cloudsql_database \
AND logName=projects/PROJECT_ID \
/logs/cloudsql.googleapis.com%2FLOG_NAME" \
--format json \
--project=PROJECT_ID \
--freshness="1d" \
> downloaded-log.json
    

Pour télécharger les journaux au format TEXT, procédez comme suit :

gcloud logging read \
"resource.type=cloudsql_database \
AND logName=projects/PROJECT_ID \
/logs/cloudsql.googleapis.com%2FLOG_NAME" \
--format json \
--project=PROJECT_ID \
--freshness="1d"| jq -rnc --stream 'fromstream(1|truncate_stream(inputs)) \
| .textPayload' \
--order=asc
> downloaded-log.txt
   

Pour connaître la taille des journaux généraux, connectez-vous à la base de données et exécutez la requête suivante :

Solutions possibles

• Vous pouvez vérifier l'espace de stockage occupé par les journaux binaires à l'aide de la commande suivante dans l'interface de ligne de commande MySQL : SHOW BINARY LOGS;
• Les tables temporaires peuvent également occuper une quantité importante d'espace de stockage. Pour vérifier l'utilisation de l'espace temporaire, utilisez la commande suivante : SELECT * FROM INFORMATION_SCHEMA.FILES WHERE TABLESPACE_NAME='innodb_temporary'\G.
• La commande suivante vous permet de vérifier la taille du journal de rétablissement : SHOW VARIABLES LIKE 'innodb_log_file%';
• Vous pouvez vérifier la taille de general_log, s'il est activé, à l'aide de la commande suivante : SELECT ROUND(SUM(LENGTH(argument)/POW(1024,2)),2) AS GB from mysql.general_log;
• Si nécessaire, vous pouvez tronquer vos tables de journal à l'aide de l'API. Pour plus d'informations, consultez la page de la documentation de référence sur la méthode instances.truncateLog.
• Apprenez-en plus sur les paramètres et la configuration des journaux de requête lente.

Connectez-vous à la base de données et exécutez cette requête :

SHOW PROCESSLIST.

Le premier élément de la liste peut être celui conservant le verrouillage, que les éléments suivants attendent.

La requête SHOW INNODB STATUS peut également être utile.

SELECT * FROM INFORMATION_SCHEMA.FILES WHERE TABLESPACE_NAME='innodb_temporary'\G

Connectez-vous à la base de données et exécutez la requête suivante :

SELECT TABLE_SCHEMA, TABLE_NAME, sum(DATA_LENGTH+INDEX_LENGTH)/pow(1024,2) FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA NOT IN ('PERFORMANCE_SCHEMA','INFORMATION_SCHEMA','SYS','MYSQL') GROUP BY TABLE_SCHEMA, TABLE_NAME;

Si possible, segmentez l'instance. L'utilisation de nombreuses instances Cloud SQL plus petites est préférable à une instance de grande taille.

Le redémarrage supprime les fichiers temporaires sans réduire l'espace de stockage. Seul le service client est en mesure de réinitialiser la taille de l'instance.

Examinez les journaux au moment de la suppression et vérifiez si un script malveillant est en cours d'exécution à partir d'un tableau de bord ou d'un autre processus automatisé.

Voici quelques explications possibles :

• Une autre opération est en cours. Les opérations Cloud SQL ne s'exécutent pas simultanément. Attendez que l'autre opération se termine.
• L'avertissement INSTANCE_RISKY_FLAG_CONFIG est déclenché chaque fois qu'au moins une option beta est utilisée. Supprimez les paramètres risqués de l'option et redémarrez l'instance.

Malheureusement, vous ne pouvez réduire le fichier ibtmp1 qu'en redémarrant le service.

L'une des mesures d'atténuation consiste à créer la table temporaire avec ROW_FORMAT=COMPRESSED, afin de stocker ce fichier dans des espaces de tables de type "un fichier par table" dans le répertoire de fichiers temporaires. Toutefois, cette méthode génère des coûts de performances liés à la création et à la suppression d'un espace de table de type "un fichier par table" pour chaque table temporaire.

Si l'espace de stockage de votre instance est insuffisant et que la fonctionnalité d'augmentation automatique de l'espace de stockage n'est pas activée, l'instance se déconnecte. Pour éviter ce problème, vous pouvez modifier l'instance afin d'activer l'augmentation automatique de l'espace de stockage.

En limitant les connexions à moins de 60 secondes, y compris les connexions à partir de l'invite de commande de base de données, vous pouvez éviter la plupart des arrêts non propres. Si vous laissez ces connexions ouvertes pendant des heures ou plusieurs jours, cela peut entraîner des arrêts incorrects.

Identifiez les objets qui dépendent de l'utilisateur, puis supprimez-les ou réattribuez-les à un autre utilisateur.

Reportez-vous aux conseils généraux sur les performances, en particulier.

Pour les insertions, mises à jour ou suppressions lentes de bases de données, envisagez les actions suivantes :

• Si vous activez l'option long_query_time, vous pouvez rechercher les requêtes lentes dans les journaux. Accédez à la page Explorateur de journaux de votre projet, puis exécutez une requête semblable à la suivante :

  resource.type="cloudsql_database"
  resource.labels.database_id="INSTANCE-ID"
  log_name="projects/PROJECT-ID/logs/cloudsql.googleapis.com%2Fmysql-slow.log"
        

  Vous pouvez télécharger les journaux au format JSON ou TEXT pour les traiter en local.

• Vérifiez l'emplacement du rédacteur et de la base de données. L'envoi de données sur une longue distance entraîne une latence.
• Vérifiez l'emplacement du lecteur et de la base de données. La latence affecte davantage les performances de lecture que les performances d'écriture.

Pour réduire la latence, nous vous recommandons de placer les ressources sources et de destination dans la même région.

En dehors de votre charge de travail, d'autres facteurs peuvent avoir une incidence sur l'utilisation de la mémoire, tels que le nombre de connexions actives et les processus internes. Ils ne sont pas toujours reflétés dans les graphiques de surveillance.

Assurez-vous que l'instance dispose d'une marge suffisante pour prendre en compte votre charge de travail et une utilisation supplémentaire de la mémoire.

Pour conserver vos données, exportez-les vers Cloud Storage avant de supprimer l'instance.

Le rôle d'administrateur Cloud SQL inclut l'autorisation de supprimer l'instance. Pour éviter toute suppression accidentelle, accordez ce rôle uniquement si nécessaire.

Il existe d'autres façons d'atteindre cet objectif en créant une instance.

• Vous pouvez cloner l'instance que vous souhaitez renommer et définir un nouveau nom pour l'instance clonée. Cela vous permet de créer une instance sans avoir à importer des données manuellement. Tout comme lors de la création d'une instance, l'instance clonée possède une nouvelle adresse IP.
• Vous pouvez exporter les données de votre instance vers un bucket Cloud Storage, créer une instance avec le nouveau nom souhaité, puis importer. les données dans la nouvelle instance.

Dans les deux cas, vous pouvez supprimer votre ancienne instance une fois l'opération terminée. Nous vous recommandons d'opter pour le clonage, car il n'a aucune incidence sur les performances et ne nécessite aucune répétition des paramètres de configuration de l'instance (tels que les options, le type de machine, la taille de stockage et la mémoire).

1. Vérifiez l'état du point de terminaison.

   gcloud

   Pour vérifier l'état, utilisez la commande
   gcloud compute forwarding-rules describe.

   gcloud compute forwarding-rules describe ENDPOINT_NAME \
   --project=PROJECT_ID \
   --region=REGION_NAME \
   | grep pscConnectionStatus

   Effectuez les remplacements suivants :

   • ENDPOINT_NAME : nom du point de terminaison.
   • PROJECT_ID : ID ou numéro de projet du projet Google Cloud contenant le point de terminaison.
   • REGION_NAME : nom de la région du point de terminaison

   REST

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

   • PROJECT_ID : ID ou numéro de projet du projet Google Cloud contenant le point de terminaison Private Service Connect
   • REGION_NAME : nom de la région
   • ENDPOINT_NAME : nom du point de terminaison.

   Méthode HTTP et URL :

   GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/forwardingRules/ENDPOINT_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://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/forwardingRules/ENDPOINT_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://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/forwardingRules/ENDPOINT_NAME" | Select-Object -Expand Content

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

   {
     "kind": "compute#forwardingRule",
     "id": "ENDPOINT_ID",
     "creationTimestamp": "2024-05-09T12:03:21.383-07:00",
     "name": "ENDPOINT_NAME",
     "region": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME",
     "IPAddress": "IP_ADDRESS",
     "target": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/serviceAttachments/SERVICE_ATTACHMENT_NAME",
     "selfLink": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/forwardingRules/ENDPOINT_NAME",
     "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/default",
     "serviceDirectoryRegistrations": [
       {
         "namespace": "goog-psc-default"
       }
     ],
     "networkTier": "PREMIUM",
     "labelFingerprint": "LABEL_FINGERPRINT_ID",
     "fingerprint": "FINGERPRINT_ID",
     "pscConnectionId": "CONNECTION_ID",
     "pscConnectionStatus": "ACCEPTED",
     "allowPscGlobalAccess": true
   }
   

2. Vérifiez que l'état du point de terminaison est ACCEPTED. Si l'état est PENDING, l'instance n'autorise pas le projet Google Cloud contenant le point de terminaison. Assurez-vous que le projet réseau dans lequel le point de terminaison est créé est autorisé. Pour en savoir plus, consultez la page Modifier une instance avec Private Service Connect activé.

Tout d'abord, vérifiez que la valeur de l'option max_connections est supérieure ou égale à la valeur principale.

Si l'option max_connections est définie correctement, inspectez les journaux dans Cloud Logging pour rechercher l'erreur réelle.

Si l'erreur est : set Service Networking service account as servicenetworking.serviceAgent role on consumer project, désactivez et réactivez Service Networking API. Cette action crée le compte de service nécessaire pour poursuivre le processus.

Redémarrez l'instance dupliquée afin de récupérer l'espace de mémoire temporaire.

Modifiez l'instance pour activer automatic storage increase.

• Requêtes lentes sur l'instance dupliquée. Recherchez-les et corrigez-les.
• Toutes les tables doivent avoir une clé unique/primaire. Chaque mise à jour d'une table sans clé unique/primaire entraîne une analyse complète des tables de l'instance répliquée.
• Les requêtes telles que DELETE ... WHERE field < 50000000 allongent le délai de duplication, dans le cas des duplications basées sur les lignes, car un grand nombre de mises à jour s'accumulent sur l'instance dupliquée.

Voici quelques solutions possibles :

• Configurez la réplication parallèle.
• Définissez l'option innodb_flush_log_at_trx_commit sur l'instance dupliquée avec accès en lecture sur 2.

  Pour plus d'informations sur cette option, consultez la section Conseils pour l'utilisation d'options.

• Modifiez l'instance pour augmenter la taille de l'instance dupliquée.
• Réduisez la charge sur la base de données.
• Envoyez du trafic en lecture à l'instance dupliquée avec accès en lecture.
• Indexez les tables.
• Identifiez et corrigez les requêtes d'écriture lentes.
• Recréez l'instance dupliquée.

Voici quelques solutions possibles pour éviter une longue transaction :

• Diviser la transaction en plusieurs petites transactions
• Fragmenter une seule requête d'écriture volumineuse en lots plus petits
• Tenter de séparer les longues requêtes SELECT d'une transaction associée à des LMD

Sur l'instance principale qui affiche le message d'erreur, définissez les options de réplication parallèle comme suit :

1. Modifiez les options binlog_transaction_dependency_tracking et transaction_write_set_extraction :
   • binlog_transaction_dependency_tracking=COMMIT_ORDER
   • transaction_write_set_extraction=OFF
2. Ajoutez l'option slave_pending_jobs_size_max :

   slave_pending_jobs_size_max=33554432

3. Modifiez l'option transaction_write_set_extraction :

   transaction_write_set_extraction=XXHASH64

4. Modifiez l'option binlog_transaction_dependency_tracking :

   binlog_transaction_dependency_tracking=WRITESET

Recréez l'instance dupliquée après avoir arrêté toutes les requêtes en cours d'exécution.