Résoudre les problèmes liés à Cloud SQL pour MySQL

Les thèmes traités sur cette page sont les suivants :

Si vous recherchez des informations sur des messages d'erreur spécifiques, consultez la page Messages d'erreur.

Sauvegarde et récupération

Problème Dépannage
Vous ne pouvez pas voir l'état de l'opération en cours. Google Cloud Console signale les réussites ou les échecs d'exécution lorsque l'opération est terminée. Il n'est pas conçu pour afficher des avertissements ni d'autres mises à jour.

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

Vous souhaitez savoir qui a initié une opération de sauvegarde à la demande. L'interface utilisateur n'affiche pas l'utilisateur qui a lancé une opération.

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 Logging est activé et que vous disposez des autorisations nécessaires pour les afficher, il est possible que cloudaudit.googleapis.com/activity soit également disponible.
Vous ne pouvez pas effectuer de sauvegarde après la suppression d'une instance. Le délai de grâce avant la suppression définitive d'une instance Cloud SQL est de quatre jours, à l'exception des instances dupliquées avec accès en lecture qui sont supprimées définitivement. Pendant cette période, le service client est en mesure de recréer l'instance. Une fois les instances définitivement supprimées, la récupération des données est impossible.

Si vous avez exporté les données, vous pouvez créer une instance, puis importer 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.

La sauvegarde automatique demeure bloquée pendant de nombreuses heures et ne peut pas être annulée. Les sauvegardes peuvent prendre beaucoup de temps en fonction de la taille de la base de donné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.

Une opération de restauration peut échouer lorsqu'un ou plusieurs utilisateurs référencés dans le fichier de vidage SQL n'existent pas. Avant de restaurer un fichier de vidage SQL, tous les utilisateurs de la base de données qui possèdent des objets ou disposent d'autorisations sur les objets qu'elle contient doivent exister dans la base de données cible. Si ce n'est pas le cas, l'opération de restauration ne recrée pas les objets avec les autorisations ou la propriété d'origine.

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

Vous souhaitez augmenter le nombre de jours pendant lesquels vous pouvez conserver les sauvegardes automatiques de sept à 30 jours ou plus. Sept sauvegardes seulement sont conservées. Les sauvegardes sont régulièrement supprimées en raison de leur coût et de leur taille. Malheureusement, cela signifie que les sauvegardes visibles sont les seules sauvegardes automatiques à partir desquelles vous pourrez effectuer une restauration.

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.

La sauvegarde a échoué et le message Unknown error s'affiche. L'opération de sauvegarde a peut-être expiré.

Deux options influencent la création de la sauvegarde : checkpoint_timeout et checkpoint_completion_target. Au début de la sauvegarde, un point de contrôle slow est exécuté et multiplie checkpoint_completion_target par checkpoint_timeout.

Par exemple, 900 sec * 0.9 sec = 810 sec = 13.5 min.

Pour cette raison, un délai avant expiration se produit. Dans ce cas, diminuer la valeur de checkpoint_completion_target résout le problème.

La sauvegarde automatique a échoué et vous n'avez pas reçu de notification par e-mail. Les notifications ne sont pas compatibles avec les échecs de sauvegarde.

Lorsqu'une sauvegarde automatique échoue, le message Operation error s'affiche sur la page Details de l'instance Cloud SQL.

Vous pouvez consulter l'état d'une sauvegarde via l'API REST ou les commandes gcloud. Vous pouvez commencer par répertorier les sauvegardes d'une instance puis décrire une sauvegarde spécifique par son ID :


gcloud sql backups list \
--project=PROJECT_ID \
--instance=INSTANCE_ID
   

gcloud sql backups describe BACKUP-ID \
--instance=INSTANCE_ID
    

En cours de clonage

Problème Dépannage
Échec du clonage : erreur constraints/sql.restrictAuthorizedNetworks. L'opération de clonage est bloquée par la configuration Authorized Networks. Les Authorized Networks sont configurés pour les adresses IP publiques dans la section "Connectivité" de Google Cloud Console, et le clonage n'est pas autorisé pour des raisons de sécurité.

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.

Connectivité

Problème Dépannage
Aborted connection. Cause possible :
  • 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.

Créer des instances

Problème Dépannage
Le message d'erreur suivant s'affiche : Failed to create subnetwork. Couldn't find free blocks in allocated IP ranges. Please allocate new ranges for this service provider Il n'y a plus d'adresses disponibles dans la plage d'adresses IP allouée. Plusieurs scénarios sont possibles :

  • 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.
  • Vous essayez de créer des instances MySQL ou SQL Server et PostgreSQL sur la même connexion de service privée dans le projet hôte du VPC. MySQL et SQL Server peuvent partager la même connexion de service. PostgreSQL nécessite sa propre connexion de service.
  • Vous essayez de créer des instances sur la même connexion de service privé dans différentes régions, ce qui n'est pas accepté.

Pour chacun des scénarios ci-dessus, vous pouvez choisir de développer la plage d'adresses IP existante ou d'allouer une plage d'adresses IP supplémentaire à la connexion de service privée.

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
    

Exporter

Problème Dépannage
L'exportation au format CSV a fonctionné, mais pas l'exportation au format SQL. Les formats CSV et SQL sont exportés de manière différente. Comme le format SQL exporte l'intégralité de la base de données, l'exportation prend probablement plus de temps. Le format CSV vous permet de définir les éléments de la base de données à exporter.

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

L'exportation prend trop de temps. Cloud SQL n'est pas compatible avec les opérations synchrones simultanées.

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 souhaitez automatiser les exportations. Cloud SQL ne permet pas d'automatiser les exportations.

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

Instance principale externe

Cliquez sur les liens du tableau pour en savoir plus :

Problème Dépannage
Lost connection to MySQL server during query when dumping table. Peut-être que la source est devenue indisponible ou que le vidage contenait des paquets trop volumineux.

Assurez-vous que l'instance principale externe est disponible, ou utilisez mysqldump avec l'option max_allowed_packet.

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.

La migration initiale des données a abouti, mais aucune donnée n'est répliquée. Il se peut que votre base de données source ait défini des options de réplication qui empêchent la réplication de certaines ou de toutes les modifications de la base de données.

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.

La migration initiale des données a abouti, mais la réplication des données cesse de fonctionner après un certain temps. Solutions possibles

  • Vérifiez les métriques de réplication de votre instance dupliquée dans la section Cloud Monitoring de Google Cloud Console.
  • 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
mysqld check failed: data disk is full. Le disque de données de l'instance dupliquée est saturé.

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.

Instance dupliquée externe

Problème Dépannage
Message d'erreur : The slave is connecting ... master has purged binary logs containing GTIDs that the slave requires. L'instance principale Cloud SQL dispose de sauvegardes automatiques, de journaux binaires et de la récupération à un moment précis. Elle devrait donc disposer de suffisamment de journaux pour que l'instance dupliquée puisse rattraper son retard. Toutefois, même si les journaux binaires existent, l'instance dupliquée ne sait pas sur quelle ligne commencer à lire.

Créez un nouveau fichier de vidage avec les options appropriées puis configurez l'instance dupliqué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 vidage que vous venez de créer contient la ligne SET @@GLOBAL.GTID_PURGED='...'.
  4. Importez le fichier de vidage dans un bucket Cloud Storage puis configurez l'instance dupliquée en utilisant ce fichier de vidage.

Options

Problème Dépannage
Une fois que vous avez activé une option, une boucle se produit entre la panique et le plantage de l'instance. Contactez le service client pour demander la suppression de l'option et un hard drain. Cela force l'instance à redémarrer sur un autre hôte avec une nouvelle configuration, sans option ni paramètre indésirables.
Le message d'erreur Bad syntax for dict arg s'affiche lorsque vous tentez de définir une option. Les valeurs de paramètre complexes, telles que les listes d'éléments séparés par une virgule, nécessitent un traitement particulier lorsqu'elles sont utilisées avec des commandes gcloud.
Le fuseau horaire n'est pas modifié automatiquement. Les changements automatiques du fuseau horaire ne sont pas compatibles avec Cloud SQL pour MySQL et doivent être effectués manuellement en utilisant une valeur de décalage de fuseau horaire plutôt qu'une chaîne.

Modifiez l'instance pour changer l'indicateur default_time_zone. Les zones de noms ne sont pas compatibles. Exemple :

Europe/LondonLondres est dans le fuseau horaire UTC, qui serait une valeur acceptée de +00:00 pour l'option default_time_zone.

Haute disponibilité

Problème Dépannage
Vous ne trouvez pas les métriques d'un basculement manuel. Seuls les basculements automatiques sont pris en compte dans les métriques.
L'utilisation des ressources d'instance Cloud SQL (processeur et mémoire RAM) arrive bientôt à 100 %, ce qui entraîne l'arrêt de l'instance à haute disponibilité. La taille de la machine de l'instance est insuffisante pour la charge.

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

Import

Problème Dépannage
L'opération d'importation prend trop de temps. Un trop grand nombre de connexions actives peut interférer avec les opérations d'importation.

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.
Une opération d'importation peut échouer lorsqu'un ou plusieurs utilisateurs référencés dans le fichier de vidage n'existent pas. Avant d'importer un fichier de vidage, tous les utilisateurs de la base de données qui possèdent des objets ou disposent d'autorisations sur les objets qu'elle contient doivent exister dans la base de données cible. Si ce n'est pas le cas, l'opération d'importation ne parvient pas à recréer les objets en rétablissant les propriétaires ou les autorisations d'origine.

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

Une importation échoue et une erreur indiquant qu'une table n'existe pas s'affiche. Les tables peuvent comporter des dépendances de clés étrangères sur d'autres tables. En fonction de l'ordre des opérations, il est possible qu'une ou plusieurs de ces tables n'existent pas encore lors de l'importation.

Solutions possibles

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


SET FOREIGN_KEY_CHECKS=0;
  

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


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.

Logging

Problème Dépannage
La journalisation consomme une grande quantité de processeurs et de mémoire sur votre instance Cloud SQL. Vous devez régler la journalisation.

Vous pouvez définir l'option log_statement sur "aucun" et désactiver l'option logging_collector. Si la journalisation continue, d'autres options liées aux journaux peuvent être réglées. Vous pouvez modifier l'instance afin de changer ces options.

Les journaux d'audit sont introuvables. Les journaux d'accès aux données ne sont écrits que si l'opération est un appel d'API authentifié qui crée, modifie ou lit des données créées par l'utilisateur, ou si l'opération accède à des fichiers de configuration ou à des métadonnées de ressources.
Les informations sur les opérations sont introuvables dans les journaux. Vous souhaitez obtenir davantage d'informations sur une opération.

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 personnelles telles que celles-ci, vous devez activer la journalisation d'audit.

Certains journaux sont filtrés à partir du journal error.log d'une instance Cloud SQL pour SQL Server. Les journaux filtrés incluent les journaux AD sans horodatage, et incluent les éléments suivants : Login failed for user 'x'. Reason: Token-based server access validation failed with an infrastructure error. Login lacks connect endpoint permission. [CLIENT: 127.0.0.1]. Ces journaux sont filtrés, car ils peuvent prêter à confusion.
La journalisation consomme une grande quantité d'espace disque. Trois types de fichiers journaux utilisent l'espace disque : les journaux de rétablissement, les journaux généraux et les journaux binaires.

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;
    
Les fichiers journaux sont difficiles à lire. Vous préférez afficher les journaux au format JSON ou texte. Pour télécharger les journaux, vous pouvez utiliser la commande gcloud logging read avec les commandes Linux de post-traitement.

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 text \
--project=PROJECT_ID \
--freshness="1d"| jq -rnc --stream 'fromstream(1|truncate_stream(inputs)) \
| .textPayload' \
> downloaded-log.txt
   

Gérer les instances

Problème Dépannage
Lenteur des performances après le redémarrage de MySQL. Cloud SQL autorise la mise en cache des données dans le pool de mémoire tampon InnoDB. Cependant, après un redémarrage, ce cache est toujours vide, et toutes les lectures nécessitent un aller-retour vers le backend pour obtenir des données. Par conséquent, les requêtes peuvent être plus lentes que prévu jusqu'à ce que le cache soit rempli.
Récupération lente après un plantage Un general_log volumineux s'est peut-être accumulé. Vous pouvez réduire le temps de récupération après plantage en empêchant un general_log volumineux de s'accumuler. Si vous avez activé general_log, tronquez la table et n'activez general_log que pendant de courtes périodes.

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

SELECT ROUND(SUM(LENGTH(argument)/POW(1024,2)),2) from mysql.general_log;
Vous voulez savoir ce qui consomme de l'espace de stockage. Par exemple, vous remarquez que votre base de données n'utilise que 3 Go, alors que le stockage indique que 14 Go sont utilisés. La plupart de l'espace non utilisé par les tables est utilisé par les journaux binaires et/ou les fichiers temporaires.

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.
Les requêtes sont bloquées. Les requêtes peuvent verrouiller la base de données MySQL, ce qui entraîne le blocage/l'expiration de toutes les requêtes suivantes.

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.

Impossible de supprimer manuellement les journaux binaires Les journaux binaires ne peuvent pas être supprimés manuellement. Ils sont automatiquement supprimés, ainsi que leur sauvegarde automatique associée, au bout de sept jours environ.
Vous souhaitez obtenir des informations sur les fichiers temporaires. Un fichier nommé ibtmp1 est utilisé pour stocker des données temporaires. Ce fichier est réinitialisé au redémarrage de la base de données. Pour trouver des informations sur l'utilisation des fichiers temporaires, connectez-vous à la base de données et exécutez la requête suivante:

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

Vous souhaitez connaître les tailles des tables. Ces informations sont disponibles dans la base de données.

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;

mysqld a reçu un signal 11. L'instance a probablement planté, car les requêtes créent trop de connexions.

Refactorisez les requêtes afin qu'elles créent moins de connexions.

InnoDB: page_cleaner: 1000ms intended loop took 5215ms. The settings might not be optimal. Le nettoyage de page ne peut pas suivre le rythme des changements sur l'instance. Une fois par seconde, le nettoyage de page analyse le pool de mémoire tampon pour identifier les pages modifiées afin de vider le pool de mémoire tampon sur le disque. L'avertissement vous montre qu'il contient de nombreuses pages modifiées à vider, et il faut plus d'une seconde pour vider un lot de pages sur le disque.

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

L'espace de stockage temporaire a entraîné l'augmentation automatique de l'espace de stockage. L'augmentation automatique de l'espace de stockage est activée.

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.

Les données sont automatiquement supprimées. Il est probable qu'un script s'exécute quelque part dans votre environnement.

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

Impossible de supprimer l'instance. Le message d'erreur ERROR: (gcloud.sql.instances.delete) HTTP Error 409: The instance or operation is not in an appropriate state to handle the request s'affiche, ou l'instance affiche INSTANCE_RISKY_FLAG_CONFIG pour l'état d'une option.

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.
L'instance se bloque en raison du volume important des données temporaires. Le système peut créer plusieurs tables temporaires à la fois, en fonction des requêtes et de la charge.

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.

Erreur fatale lors de la mise à niveau. Les journaux peuvent fournir davantage d'informations, mais dans tous les cas, vous devrez peut-être contacter le service client pour forcer la recréation de l'instance.
L'instance se bloque au redémarrage après avoir épuisé l'espace disque. La fonctionnalité d'augmentation automatique de l'espace de stockage n'est pas activée.

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.

Blocage de l'instance principale sur site Google Cloud ne peut pas vous aider avec des instances qui ne sont pas dans Cloud SQL.
Arrêt lent au redémarrage. Lorsqu'une instance s'arrête, toutes les connexions en attente qui ne se terminent pas au bout de 60 secondes entraînent un arrêt incorrect.

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.

Impossible de supprimer un utilisateur. L'utilisateur dispose d'objets dans la base de données qui en dépendent. Vous devez supprimer ces objets ou les réattribuer à un autre utilisateur.

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

Cet article explique comment trouver les objets appartenant à l'utilisateur.
Certaines requêtes sont lentes. Les requêtes peuvent être lentes pour de nombreuses raisons, principalement à cause de certains aspects de la base de données. L'une des raisons pouvant impliquer Cloud SQL est la latence du réseau, lorsque la ressource source (rédacteur ou lecteur) et la ressource de destination (Cloud SQL) se trouvent dans différentes régions.

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.

Mémoire insuffisante signalée, mais non reportée dans les graphiques de surveillance. Une instance peut échouer et signaler Out of memory, mais les graphiques Cloud Monitoring ou Google Cloud Console semblent indiquer qu'il reste encore de la mémoire.

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.

Récupérer une instance supprimée. Toutes les données d'une instance, y compris les sauvegardes, sont définitivement perdues lors de sa suppression.

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.

Vous souhaitez renommer une instance Cloud SQL existante. Il n'est pas possible de renommer une instance existante.

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

Réplication

Problème Dépannage
L'instance dupliquée avec accès en lecture n'a pas commencé à se dupliquer lors de la création. Les fichiers journaux indiquent probablement une erreur plus spécifique. Inspectez les journaux dans Cloud Logging pour rechercher l'erreur en question.
Impossible de créer l'instance dupliquée avec accès en lecture : erreur invalidFlagValue. L'un des indicateurs de la requête n'est pas valide. Il peut s'agir d'une option que vous avez explicitement définie ou d'une option définie sur une valeur par défaut.

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.

Impossible de créer l'instance dupliquée avec accès en lecture : erreur inconnue. Les fichiers journaux indiquent probablement une erreur plus spécifique. Inspectez les journaux dans Cloud Logging pour rechercher l'erreur en question.

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.

Le disque est saturé. Le disque de l'instance principale peut arriver à saturation lors de la création de l'instance dupliquée. Modifiez l'instance principale en augmentant la taille du disque.
L'instance dupliquée utilise trop de mémoire. L'instance dupliquée met en cache les opérations de lecture souvent demandées dans une mémoire temporaire, ce qui peut l'amener à utiliser plus de mémoire que l'instance principale.

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

La duplication s'est arrêtée. La limite de stockage maximale a été atteinte et l'augmentation automatique de l'espace de stockage n'est pas activée.

Modifiez l'instance pour activer automatic storage increase.

Le délai de duplication est systématiquement long. La charge d'écriture est trop élevée pour que l'instance dupliquée puisse la traiter. Le délai de duplication s'allonge lorsque le thread SQL d'une instance dupliquée ne parvient pas à suivre le thread d'E/S. Certains types de requêtes ou de charges de travail peuvent allonger le délai de duplication de manière temporaire ou permanente pour un schéma donné. Voici quelques causes typiques affectant le délai de duplication :
  • 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 dupliqué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:

La modification des options de réplication parallèle génère une erreur. Une valeur incorrecte est définie pour une ou plusieurs de ces options.

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

La création d'une instance dupliquée échoue avec un délai d'expiration. Les transactions non validées de longue durée sur l'instance principale peuvent entraîner l'échec de la création d'une instance dupliquée avec accès en lecture.

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