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

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

Sauvegarde et récupération

Cliquez sur les liens du tableau pour en savoir plus :

Pour ce problème... Le problème peut être... Essayez ce qui suit...
Impossible d'afficher l'état actuel de l'opération. L'interface utilisateur n'affiche que les opérations réussies ou échouées. Exécutez ces commandes de base de données pour en savoir plus.
Impossible de trouver l'utilisateur à l'origine de l'opération. L'interface utilisateur n'affiche pas l'utilisateur qui a lancé une opération. Consultez les journaux d'audit pour le savoir.
Épuisement de l'espace disque pendant la sauvegarde automatique. L'instance a atteint les limites d'espace disque. Vérifiez la taille et le quota du système de fichiers.
Impossible d'effectuer une sauvegarde après la suppression de l'instance. L'instance a été supprimée. Recréez l'instance à partir d'une exportation ou contactez le service client si le délai de grâce est écoulé.
La sauvegarde automatique semble bloquée. Le moment de la sauvegarde dépend de la taille de la base de données. Contactez le service client si vous devez vraiment annuler l'opération.
Échec de restauration. Le fichier de vidage peut contenir des utilisateurs de base de données qui n'existent pas encore. Créez les utilisateurs de la base de données avant la restauration.
L'opération n'est pas valide pour cette instance. La taille de l'instance de destination est inférieure à celle de la source. Augmentez la taille de l'instance de destination.
Augmentez le nombre de jours de conservation des sauvegardes automatiques. Sept sauvegardes automatiques seulement sont conservées. Gérez vos propres sauvegardes manuelles.
La sauvegarde a échoué en raison d'une erreur inconnue. La sauvegarde a peut-être expiré. Cochez ces options.
Pas de notification en cas d'échec de la sauvegarde. Il n'y a pas de notification par défaut. Configurez des alertes personnalisées.

Impossible d'afficher l'état actuel de l'opération

Vous ne pouvez pas consulter l'état d'une opération dans Google Cloud Console.

Cause possible

Une fois l'opération terminée, Google Cloud Console ne signale que les réussites ou les échecs, mais n'est pas conçu pour renvoyer des avertissements.

Solutions possibles

Connectez-vous à la base de données et exécutez SHOW WARNINGS.


Impossible de trouver l'utilisateur à l'origine de l'opération

Vous souhaitez savoir qui a initié une opération de sauvegarde à la demande.

Cause possible

La page des opérations sur les instances de Google Cloud Console n'affiche pas l'auteur de l'opération.

Solutions possibles

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
  • Le journal "cloudaudit.googleapis.com/activity" peut également être disponible si les journaux d'audit Cloud sont activés.


Épuisement de l'espace disque pendant la sauvegarde automatique

Le message d'erreur [ERROR] InnoDB: Write to file ./ibtmp1 failed at offset XXXX, YYYY bytes should have been written, only 0 were written. s'affiche.

Cause possible

L'instance a atteint une limite stricte lors d'une sauvegarde automatique. Lors d'une sauvegarde, la taille des fichiers temporaires peut dépasser l'espace disque disponible.

Solutions possibles

Vérifiez que le disque n'est pas saturé ou que le quota d'espace disque n'est pas épuisé. Vous pouvez augmenter manuellement la taille du disque ou activer l'augmentation automatique de l'espace de stockage.


Impossible d'effectuer une sauvegarde après la suppression de l'instance

Vous ne parvenez pas à effectuer de sauvegarde après la suppression de l'instance.

Cause possible

L'instance a été supprimée.

Solutions possibles

  • Le délai de grâce avant la suppression définitive d'une instance Cloud SQL est de quatre jours. 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 est bloquée

La sauvegarde automatique demeure bloquée pendant de nombreuses heures et ne peut pas être annulée.

Cause possible

Les sauvegardes peuvent prendre beaucoup de temps en fonction de la taille de la base de données.

Solutions possibles

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


Échec de restauration à partir d'une sauvegarde

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.

Cause possible

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. Si ce n'est pas le cas, la restauration ne parvient pas à recréer les objets en rétablissant les propriétaires et/ou les autorisations d'origine.

Solutions possibles

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


Opération non valide pour cette instance

Le message d'erreur HTTP Error 400: This operation isn't valid for this instance provenant d'un appel d'API à instances.restoreBackup s'affiche.

Cause possible

Vous ne pouvez pas effectuer de restauration à partir d'une sauvegarde d'instance dont la taille de l'espace de stockage (XX Go) est inférieure à celle de la sauvegarde (YY Go).

Solutions possibles

Modifiez l'instance cible en augmentant la taille de l'espace de stockage.


Augmenter le nombre de jours de conservation des sauvegardes automatiques

Vous souhaitez augmenter le nombre de jours pendant lesquels vous pouvez conserver les sauvegardes automatiques de sept à 30 jours ou plus.

Cause possible

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.

Solutions possibles

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.


Échec de la sauvegarde : erreur inconnue

La sauvegarde a échoué et Unknown error s'affiche.

Cause possible

La création de la sauvegarde atteint le délai avant expiration de dix minutes. Un délai de dix minutes est défini pour la sauvegarde automatique, et celle-ci doit s'achever dans ce délai.

Solutions possibles

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.

Pas de notification en cas d'échec de la sauvegarde

La sauvegarde automatique a échoué et vous n'avez reçu aucune notification.

Cause possible

Lorsqu'une sauvegarde automatique échoue, le message Operation error s'affiche sur la page Details de l'instance Cloud SQL. Les notifications par e-mail ne sont pas envoyées en cas d'échec de la sauvegarde.

Solutions possibles

Vous pouvez créer une alerte Monitoring ou utiliser des notifications de rapports d'erreurs pour configurer vos propres notifications personnalisées.

Clonage

Cliquez sur les liens du tableau pour en savoir plus :

Pour ce problème... Le problème peut être... Essayez ce qui suit...
Échec du clonage : erreur constraints/sql.restrictAuthorizedNetworks. Blocage dû à la configuration des réseaux autorisés. Essayez l'une des options suivantes :

Échec du clonage : erreur constraints/sql.restrictAuthorizedNetworks

Échec du clonage : erreur constraints/sql.restrictAuthorizedNetworks.

Cause possible

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

Solutions possibles

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é

Cliquez sur les liens du tableau pour en savoir plus :

Pour ce problème... Le problème peut être... Essayez ce qui suit...
Aborted connection Erreur lors de la lecture des paquets ou connexion annulée. Consultez ces solutions possibles.
Erreurs Unauthorized to connect. Il peut y avoir de nombreuses causes premières. Consultez ces solutions possibles.
Échec d'association de réseau. L'API Service Networking API n'est pas activée dans le projet. Activez l'API Service Networking API dans le projet.
Remaining connection slots are reserved Le nombre maximal de connexions a été atteint. Augmentez la valeur de l'option max_connections.
Set Service Networking service account as servicenetworking.serviceAgent role on consumer project. Les autorisations réseau sur le compte de service sont manquantes ou incorrectes. Désactivez et réactivez l'API Service Networking.
error x509: certificate is not valid for any names, but wanted to match project-name:db-name. Problème connu : les appels de proxy Cloud SQL ne sont pas compatibles avec Go 1.15 pour le moment. En attendant, consultez cette discussion sur GitHub, qui inclut une solution de contournement.

Connexion annulée

Le message d'erreur Got an error reading communication packets ou Aborted connection xxx to db: DB_NAME s'affiche.

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.

Solutions possibles

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.


Connexion non autorisée

Le message d'erreur Unauthorized to connect s'affiche.

Cause possible

Il peut exister plusieurs causes, car l'autorisation se produit à plusieurs niveaux.

  • Au niveau de la base de données, il doit exister un utilisateur avec un mot de passe correspondant.
  • Au niveau du projet, l'utilisateur peut ne pas disposer des autorisations IAM appropriées.
  • Au niveau de Cloud SQL, la cause première peut dépendre de la façon dont vous vous connectez à votre instance. Si vous vous connectez directement à une instance via l'adresse IP publique, l'adresse IP source de la connexion doit se trouver dans le réseau autorisé de l'instance.

    La connectivité IP privée est autorisée par défaut, sauf si vous vous connectez à partir d'une adresse non-RFC 1918. Les adresses clientes non-RFC 1918 doivent être configurées en tant que réseaux autorisés.

    Par défaut, Cloud SQL n'apprend pas les routes de sous-réseau non-RFC 1918 à partir de votre VPC. Vous devez mettre à jour l'appairage de réseaux vers Cloud SQL pour exporter les routes non-RFC 1918. Exemple :

    gcloud compute networks peerings update cloudsql-mysql-googleapis-com --network=NETWORK --export-subnet-routes-with-public-ip --project=PROJECT
    

    Si vous vous connectez via le proxy Cloud SQL, assurez-vous d'avoir correctement configuré les autorisations IAM.

  • Au niveau du réseau, si l'instance Cloud SQL utilise une adresse IP publique, l'adresse IP source de la connexion doit se trouver dans un réseau autorisé.

Solutions possibles

  • Vérifiez le nom d'utilisateur et le mot de passe.
  • Vérifiez les rôles et les autorisations IAM de l'utilisateur.
  • Si vous utilisez une adresse IP publique, assurez-vous que la source se trouve dans les réseaux autorisés.

Échec d'association de réseau

Le message d'erreur Error: Network association failed due to the following error s'affiche indiquant de définir le compte de service Service Networking en tant que rôle servicenetworking.serviceAgent sur le projet client.

Cause possible

L'API Service Networking API n'est pas activée dans le projet.

Solutions possibles

Activez l'API Service Networking API dans votre projet. Si cette erreur s'affiche lorsque vous tentez d'attribuer une adresse IP privée à une instance Cloud SQL et que vous utilisez un VPC partagé, vous devez également activer l'API Service Networking API pour le projet hôte.


Les emplacements de connexion restants sont réservés

Le message d'erreur FATAL: remaining connection slots are reserved for non-replication superuser connections s'affiche.

Cause possible

Le nombre maximal de connexions a été atteint.

Solutions possibles

Modifiez la valeur de l'option max_connections. Augmenter max_connections au-delà d'une certaine valeur entraîne la perte de l'assistance liée au contrat de niveau de service.


Définir le compte de service Service Networking en tant que rôle servicenetworking.serviceAgent sur le projet client

Le message d'erreur set Service Networking service account as servicenetworking.serviceAgent role on consumer project. s'affiche.

Cause possible

Les autorisations des utilisateurs ou des comptes de service sont incorrectes. Cela peut se produire lors de l'exécution de scripts de configuration automatique, tels qu'un script de configuration Terraform.

Solutions possibles

Pour réparer les autorisations de service, désactivez l'API Service Networking API, attendez cinq minutes, puis réactivez-la.

Vous pouvez également essayer d'utiliser ces commandes gcloud pour attribuer le rôle au projet.

gcloud beta services identity create --service=servicenetworking.googleapis.com --project=project-id
gcloud projects add-iam-policy-binding project-id --member="service-account-prefix@service-networking.iam.gserviceaccount.com" --role="roles/servicenetworking.serviceAgent"

Erreur x509 : le certificat n'est valide pour aucun nom

Le message d'erreur error x509: certificate is not valid for any names, but wanted to match project-name:db-name s'affiche.

Cause possible

Problème connu : les appels de proxy Cloud SQL ne sont pas compatibles avec Go 1.15 pour le moment.

Solutions possibles

En attendant que le bug soit corrigé, consultez cette discussion sur GitHub, qui inclut une solution de contournement.


Créer des instances

Cliquez sur les liens du tableau pour en savoir plus :

Pour ce problème... Le problème peut être... Essayez ce qui suit...
Internal error Compte de service Service Networking manquant. Désactivez et réactivez l'API Service Networking API.
Échec de création de l'instance. Erreur de configuration Terraform. Inspectez et corrigez le fichier de configuration Terraform.
HTTP Error 409 dans le script Terraform. Une autre opération est déjà en cours. Corrigez le script Terraform pour attendre la fin de chaque opération.
Unknown error Tentative de création d'une instance portant le même nom qu'une instance récemment supprimée. Ou tentative de création de plusieurs instances simultanément avec une nouvelle plage d'adresses IP privées utilisée. Attribuez un autre nom à l'instance ou attendez une semaine à compter de sa suppression. Recréez les instances ayant échoué de manière consécutive en utilisant des noms différents.

Erreur interne

Le message d'erreur {"ResourceType":"sqladmin.v1beta4.instance", "ResourceErrorCode":"INTERNAL_ERROR","ResourceErrorMessage":null} s'affiche.

Cause possible

Le projet de service ne contient probablement pas le compte de service Service Networking requis pour cette fonctionnalité.

Solutions possibles

Pour réparer les autorisations de service, désactivez l'API Service Networking API, attendez cinq minutes, puis réactivez-la.


Échec de création de l'instance Terraform

Échec de création de l'instance.

Cause possible

Il s'agit généralement d'un problème dans le script Terraform lui-même.

Solutions possibles

Inspectez et corrigez le fichier de configuration Terraform.


Erreur 409 dans le script Terraform

Le message d'erreur HTTP Error 409 s'affiche dans les scripts Terraform.

Cause possible

Operation failed because another operation was already in progress

Solutions possibles

Révisez le script de façon à interrompre son exécution jusqu'à ce que chaque opération d'instance se termine. Demandez au script d'effectuer une interrogation et d'attendre le retour d'un code 200 pour l'ID de l'opération précédente avant de passer à l'étape suivante.


Erreur inconnue

Lorsque vous tentez de créer une instance, un message d'erreur tel que Cloud SQL creation failed, error UNKNOWN s'affiche.

Cause possible

Vous tentez très probablement de réutiliser le nom d'une instance que vous avez récemment supprimée. Une fois une instance supprimée, vous devez attendre une semaine afin de pouvoir réutiliser son nom. Vous essayez peut-être également de créer plusieurs instances simultanément à l'aide d'une nouvelle plage d'adresses IP privées, et seule la première instance est créée alors que les autres échouent avec l'erreur Unknown error.

Solutions possibles

Attribuez un autre nom à l'instance ou attendez une semaine pour en créer une autre avec ce nom. Créez plusieurs instances de manière consécutive plutôt que simultanément.

Instance principale externe

Cliquez sur les liens du tableau pour en savoir plus :

,
Pour ce problème... Le problème peut être... Essayez ce qui suit...
Specified key was too long; max key length is 767 bytes. La variable innodb_large_prefix est peut-être définie sur l'instance principale externe. Définissez l'option innodb_large_prefix sur ON lors de la création de l'instance dupliquée ou mettez à jour l'instance dupliquée existante avec l'option.
Table definition has changed. Des modifications ont été apportées au langage de définition de données (LDD) pendant le processus de vidage. Évitez les modifications du LDD pendant le processus de vidage.
Access denied; you need (at least one of) the SUPER privilege(s) for this operation. Il est possible qu'une vue ou une fonction dans la base de données fasse référence à DEFINER, d'une manière qui n'est pas compatible avec Cloud SQL. En savoir plus sur l'utilisation de DEFINER dans Cloud SQL.
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.
Got packet bigger than 'max_allowed_packet' bytes when dumping table. La taille du paquet est supérieure à celle autorisée par les paramètres. Utilisez mysqldump avec l'option max_allowed_packet.
La migration initiale des données a abouti, mais aucune donnée n'est répliquée. Des options de réplication peuvent être en conflit. Vérifiez ces paramètres d'options.
La migration initiale des données a abouti, mais la réplication des données cesse de fonctionner après un certain temps Il peut y avoir de nombreuses causes. Nous vous suggérons d'essayer les solutions suivantes.
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.

La clé spécifiée est trop longue. La longueur maximale de la clé est de 767 octets

L'erreur Specified key was too long; max key length is 767 bytes. s'affiche.

Cause possible

La variable innodb_large_prefix est peut-être définie sur l'instance principale externe. Cela autorise les préfixes de clé d'index de plus de 767 octets. La valeur par défaut est OFF pour MySQL 5.6.

Solutions possibles

Définissez l'option innodb_large_prefix sur ON lors de la création de l'instance dupliquée ou mettez à jour l'instance dupliquée existante avec l'option.


La définition de la table a changé

L'erreur Table definition has changed s'affiche.

Cause possible

Des modifications LDD ont été appliquées pendant le processus de vidage.

Solutions possibles

Ne modifiez pas les tables et n'effectuez aucune autre modification du LDD pendant le processus de vidage.


Accès refusé. Vous avez besoin d'au moins un des privilèges SUPER pour cette opération

L'erreur Access denied; you need (at least one of) the SUPER privilege(s) for this operation s'affiche.

Cause possible

L'origine du problème peut être due au fait que le client spécifie VIEW/FUNCTION/PROCEDURE avec DEFINER à l'aide d'un super-utilisateur user@localhost (tel que root@localhost). Cette méthode n'est pas compatible avec Cloud SQL.

Solutions possibles

La solution consiste à mettre à jour la clause DEFINER dans les bases de données externes, par exemple pour passer de root@localhost à root@% ou à un utilisateur qui n'est pas un super-utilisateur. Pour en savoir plus, consultez la page sur le contrôle des accès aux objets stockés.


Connexion au serveur MySQL interrompue pendant la requête lors du vidage de la table

L'erreur Lost connection to MySQL server during query when dumping table s'affiche.

Cause possible

  • La source n'est peut-être plus disponible depuis l'instance dupliquée.

  • La base de données source peut contenir des tables avec des blobs volumineux ou des chaînes longues nécessitant de définir max_allowed_packet sur un plus grand nombre de valeurs.

Solutions possibles

  • Redémarrez et assurez-vous que l'instance principale externe est disponible.

  • Utilisez mysqldump avec l'option max_allowed_packet pour vider les données et effectuer la migration avec le fichier de vidage.


Le nombre d'octets du paquet est supérieur à "max_allowed_packet" lors du vidage de la table

L'erreur Got packet bigger than 'max_allowed_packet' bytes when dumping table s'affiche.

Cause possible

La taille du paquet est supérieure à celle autorisée par les paramètres.

Solutions possibles

Utilisez mysqldump avec l'option max_allowed_packet pour vider les données et effectuer la migration avec le fichier de vidage.


Aucune donnée n'est en cours de réplication.

La migration initiale des données a abouti, mais aucune donnée n'est répliquée.

Cause possible

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.

Solutions possibles

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

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

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

Cause possible

Il peut y avoir de nombreuses causes à ce problème.

Solutions possibles

  • Vérifiez les métriques de réplication de votre instance dupliquée dans l'interface utilisateur de Cloud Monitoring.

  • Les erreurs du thread d'E/S MySQL ou du thread SQL sont disponibles dans Cloud Logging, depuis les fichiers journaux mysql.err.

  • 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

Échec de la vérification mysqld : le disque de données est saturé

L'erreur mysqld check failed: data disk is full s'affiche.

Cause possible

Si cette erreur s'affiche lors d'une opération DRAIN, le disque de données de l'instance dupliquée est saturé.

Solutions possibles

Augmentez la taille du disque de l'instance dupliquée.

Indicateurs

Cliquez sur les liens du tableau pour en savoir plus :

Pour ce problème... Le problème peut être... Essayez ce qui suit...
Données utilisant le jeu de caractères utf8mb4. Ce jeu de caractères n'est pas disponible. Filtrez les chaînes utf8mb4 pour les exclure de vos données.
L'activation d'un indicateur fait planter l'instance. L'option max_connections est peut-être définie sur une valeur trop élevée. Contactez le service client pour demander la suppression d'une option.
Impossible d'ajouter l'option performance_schema. La taille de l'instance est trop faible. Effectuez une mise à jour vers une instance plus grande.
Le fuseau horaire n'est pas modifié automatiquement. Le changement automatique du fuseau horaire n'est pas disponible. L'heure doit être modifiée manuellement. En savoir plus
Bad syntax for dict arg. Les valeurs de paramètres complexes nécessitent un traitement particulier. En savoir plus

Données utilisant le jeu de caractères utf8mb4

Échec de l'importation de données utilisant le jeu de caractères utf8mb4.

Cause possible

Le jeu de caractères utf8mb4 n'est pas accepté, même si la documentation le mentionnait précédemment.

Solutions possibles

Filtrez les chaînes utf8mb4 pour les exclure de vos données.


L'activation d'une option fait planter l'instance

Une fois que vous avez activé une option, une boucle se produit entre la panique et le plantage de l'instance.

Cause possible

Définir l'option max_connections sur une valeur trop élevée entraîne cette erreur.

Solutions possibles

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 indicateur ni paramètre indésirables.


Impossible d'ajouter l'indicateur performance_schema

Vous ne pouvez pas ajouter l'option performance_schema, car elle ne figure pas dans le menu déroulant des options compatibles.

Cause possible

L'option performance_schema et ses variantes (performance_schema_accounts_size, performance_schema_accounts_size, etc.) ne peuvent pas être activées sur des instances de niveau inférieur à db-n1-standard-8 ou db-n1-highmem-4.

Solutions possibles

Modifiez l'instance pour obtenir une taille plus grande si vous devez utiliser cette option.


Le fuseau horaire n'est pas modifié automatiquement

Le fuseau horaire ne s'est pas automatiquement mis à jour pour le passage à l'heure d'été.

Cause possible

Les changements automatiques du fuseau horaire ne sont pas compatibles avec Cloud SQL et doivent être effectués manuellement, et ce non par chaîne, mais par valeur de décalage de fuseau horaire.

Solutions possibles

Modifiez l'instance pour changer l'indicateur default_time_zone. Les zones nommées ne sont pas compatibles. Exemple : Londres (Europe/London) est dans le fuseau horaire UTC, qui serait une valeur acceptée de +00:00 pour l'option default_time_zone.


Syntaxe incorrecte pour l'argument dict

Le message d'erreur Bad syntax for dict arg s'affiche lorsque vous tentez de définir une option.

Cause possible

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.

Solutions possibles

Utilisez le paramètre gcloud --flags-file, qui spécifie un fichier YAML ou JSON contenant un dictionnaire --flag:value utile pour les valeurs d'options complexes.

Haute disponibilité

Cliquez sur les liens du tableau pour en savoir plus :

Pour ce problème... Le problème peut être... Essayez ce qui suit...
Impossible de trouver les métriques pour le basculement manuel. Seuls les basculements automatiques entrent dans les métriques. ND
Utilisation du processeur et de la mémoire RAM proche de 100 % La taille de la machine de l'instance est insuffisante pour la charge. Augmentez la taille de la machine de l'instance.

Métriques introuvables pour le basculement manuel

Vous avez effectué un basculement manuel et vous ne trouvez pas l'entrée correspondante dans l'Explorateur de métriques pour le basculement automatique.

Cause possible

Seuls les basculements automatiques sont pris en compte dans les métriques. Les basculements manuels ne le sont pas.

Solutions possibles

ND


Utilisation du processeur et de la mémoire RAM proche de 100 %

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

Cause possible

La taille de la machine de l'instance est insuffisante pour la charge.

Solutions possibles

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

Importation et exportation

Cliquez sur les liens du tableau pour en savoir plus :

Pour ce problème... Le problème peut être... Essayez ce qui suit...
Impossible d'afficher l'état de l'opération. L'interface utilisateur n'affiche que les opérations réussies ou échouées. Exécutez ces commandes de base de données pour en savoir plus.
Le message 408 Error (Timeout) s'affiche pendant l'exportation. L'exportation au format SQL peut prendre beaucoup de temps en fonction de la taille de la base de données et du contenu exporté. Effectuez plusieurs exportations CSV pour réduire la taille de chaque opération.
L'exportation au format CSV a fonctionné, mais pas l'exportation au format SQL. L'exportation au format SQL est plus susceptible de générer des problèmes de compatibilité avec Cloud SQL. Exportez uniquement les données dont vous avez besoin au 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 savoir plus
L'importation prend trop de temps. Un trop grand nombre de connexions actives peut interférer avec les opérations d'importation. Fermez les connexions inutilisées ou redémarrez l'instance Cloud SQL avant de lancer une opération d'importation.
Error 1412: Table definition has changed. La table a été changée lors de l'exportation. Supprimez toutes les instructions de changement de table de l'opération de vidage.
Échec de l'importation. Le fichier exporté peut contenir des utilisateurs de base de données qui n'existent pas encore. Créez les utilisateurs de la base de données avant d'effectuer l'importation.
Fermeture de la connexion lors de l'exportation. La requête doit produire des données dans les sept premières minutes. Testez la requête manuellement. En savoir plus
Erreur inconnue lors de l'exportation. Problème de bande passante possible. Assurez-vous que l'instance et le bucket Cloud Storage se trouvent dans la même région.
Vous souhaitez automatiser les exportations. Cloud SQL ne permet pas d'automatiser les exportations. Créez votre propre pipeline pour exécuter cette fonctionnalité. En savoir plus
ERROR_RDBMS: system error occurred Autorisations Cloud Storage ou table inexistante. Vérifiez les autorisations OU assurez-vous que la table existe.
Erreur lors de l'importation : la table n'existe pas. Une table obligatoire n'existe pas encore. Désactivez FOREIGN_KEY_CHECKS au début de l'importation.

Impossible d'afficher l'état de l'opération

Vous ne pouvez pas voir l'état d'une opération en cours.

Cause possible

Une fois l'opération terminée, Google Cloud Console ne signale que les réussites ou les échecs, mais n'est pas conçu pour renvoyer des avertissements.

Solutions possibles

Connectez-vous à la base de données et exécutez SHOW WARNINGS.


Erreur 408 (Expiration du délai) lors de l'exportation

Le message d'erreur 408 Error (Timeout) s'affiche lors de l'exécution d'une tâche d'exportation dans Cloud SQL.

Cause possible

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.

Solutions possibles

Utilisez le format CSV et exécutez plusieurs tâches d'exportation plus petites pour réduire la taille et la durée de chaque opération.


Échec de l'exportation au format CSV

L'exportation au format CSV a fonctionné, mais pas l'exportation au format SQL.

Cause possible

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.

Solutions possibles

Exportez uniquement les données dont vous avez besoin au format CSV.


L'exportation prend trop de temps.

L'exportation prend trop de temps et bloque les autres opérations.

Cause possible

Cloud SQL n'est pas compatible avec les opérations synchrones simultanées.

Solutions possibles

Essayez d'exporter des ensembles de données plus petits.


L'importation prend trop de temps.

L'importation prend trop de temps, ce qui bloque d'autres opérations.

Cause possible

Un trop grand nombre de connexions actives peut interférer avec les opérations d'importation. Les connexions consomment des ressources de processeur et de mémoire, limitant ainsi leur disponibilité.

Solutions possibles

Fermez les opérations inutilisées. Examinez l'utilisation du processeur et de la mémoire pour vérifier que vous disposez de ressources suffisantes. 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.


mysqldump : Erreur 1412 : La définition de la table a changé

Le message d'erreur mysqldump: Error 1412: Table definition has changed, retry transaction when dumping the table s'affiche.

Cause possible

Au cours du processus d'exportation, une modification a été apportée à la table.

Solutions possibles

La transaction de vidage peut échouer si vous utilisez les instructions ci-dessous lors de l'opération d'exportation :

  • ALTER TABLE
  • CREATE TABLE
  • DROP TABLE
  • RENAME TABLE
  • TRUNCATE TABLE
Supprimez l'une de ces instructions de l'opération de vidage.


Échec de l'importation

L'importation échoue lorsqu'un ou plusieurs utilisateurs référencés dans le fichier de vidage SQL exporté n'existent pas.

Cause possible

Avant d'importer 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. Si ce n'est pas le cas, la restauration ne parvient pas à recréer les objets en rétablissant les propriétaires et/ou les autorisations d'origine.

Solutions possibles

Créez les utilisateurs de la base de données avant d'importer le fichier de vidage SQL.


Fermeture de la connexion lors de l'exportation

La connexion se ferme lors de l'exportation.

Cause possible

La connexion à Cloud Storage expire peut-être parce que la requête exécutée lors de l'exportation ne produit aucune donnée dans les sept minutes suivant le lancement de l'exportation.

Solutions possibles

Testez la requête manuellement en vous connectant depuis n'importe quel client et en envoyant le résultat de votre requête à STDOUT à l'aide de la commande ci-dessous :

COPY (INSERT_YOUR_QUERY_HERE) TO STDOUT WITH ( FORMAT csv, DELIMITER ',', ENCODING 'UTF8', QUOTE '"', ESCAPE '"' )

Ce comportement est normal, car le client est censé commencer à envoyer des données immédiatement après le lancement de l'exportation. Une connexion maintenue ouverte sans envoyer de données finit par s'interrompre, ce qui entraîne l'échec de l'exportation et laisse l'opération dans un état d'incertitude. En outre, le message d'erreur de gcloud suivant s'affiche :

operation is taking longer than expected


Erreur inconnue lors de l'exportation

Le message d'erreur Unknown error s'affiche lorsque vous tentez d'exporter une base de données vers un bucket Cloud Storage.

Cause possible

Le transfert peut échouer en raison d'un problème de bande passante.

Solutions possibles

L'instance Cloud SQL peut se trouver dans une région différente de celle du bucket Cloud Storage. La lecture et l'écriture de données d'un continent à l'autre impliquent une utilisation importante du réseau, pouvant entraîner ce type de problèmes intermittents. Vérifiez les régions de votre instance et de votre bucket.


Vous souhaitez automatiser les exportations

Vous souhaitez automatiser les exportations.

Cause possible

Cloud SQL ne permet pas d'automatiser les exportations.

Solutions possibles

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.


Erreur système de type ERROR_RDBMS

Le message d'erreur [ERROR_RDBMS] system error occurred s'affiche.

Cause possible

  • Il se peut que l'utilisateur ne dispose pas de toutes les autorisations Cloud Storage dont il a besoin.
  • La table de base de données n'existe peut-être pas

Solutions possibles

  1. Vérifiez que vous disposez tout au moins des autorisations WRITER sur le bucket et READER sur le fichier d'exportation. Pour en savoir plus sur la configuration du contrôle d'accès dans Cloud Storage, consultez la page Créer et gérer des listes de contrôle d'accès.
  2. Assurez-vous que la table existe. Si tel est le cas, vérifiez que vous disposez des autorisations appropriées sur le bucket.

Erreur lors de l'importation : la table n'existe pas.

Une importation échoue et une erreur indiquant qu'une table n'existe pas s'affiche.

Cause possible

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

Cliquez sur les liens du tableau pour en savoir plus :

Pour ce problème... Le problème peut être... Essayez ce qui suit...
La journalisation consomme une grande quantité de processeurs et de mémoire. Vous devez régler la journalisation. Essayez de régler l'utilisation des ressources de journalisation.
Les journaux d'audit sont introuvables. Authentification des utilisateurs. Vérifiez les rôles et les autorisations des utilisateurs.
Les informations sur les opérations sont introuvables dans les journaux. Les journaux d'audit ne sont pas activés. Activez la journalisation d'audit.
La journalisation consomme une grande quantité d'espace disque. Les journaux de rétablissement, les journaux binaires et les journaux généraux utilisent de l'espace disque. Exécutez ces commandes pour obtenir des informations sur l'utilisation du disque.

La journalisation consomme une grande quantité de processeurs et de mémoire

La journalisation consomme une grande quantité de processeurs et de mémoire.

Cause possible

L'utilisation de la journalisation doit être ajustée.

Solutions possibles

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.


Journaux d'audit

Vous avez activé la journalisation d'audit pour Cloud SQL, mais vous ne trouvez aucun journal d'audit dans Cloud Logging.

Cause possible

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.

Solutions possibles

Vérifiez les rôles et les autorisations de l'utilisateur qui effectue les opérations.


Informations sur les opérations 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.

Cause possible

Pour obtenir des informations détaillées et des informations personnelles telles que celles-ci, vous devez activer la journalisation d'audit.

Solutions possibles

Activez la journalisation d'audit dans votre projet.


La journalisation consomme une grande quantité d'espace disque

Vous souhaitez connaître l'espace disque utilisé par les fichiers journaux.

Cause possible

Trois types de fichiers journaux utilisent l'espace disque : les journaux de rétablissement, les journaux généraux et les journaux binaires.

Solutions possibles

Exécutez les commandes suivantes pour en savoir plus sur chaque type de fichier journal :

SHOW VARIABLES LIKE 'innodb_log_file%';

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

SHOW BINARY LOGS;

Gérer les instances

Cliquez sur les liens du tableau pour en savoir plus :

Pour ce problème... Le problème peut être... Essayez ce qui suit...
Lenteur des performances après le redémarrage Le cache InnoDB est vide après le redémarrage. Par conséquent, toutes les lectures nécessitent un aller-retour vers le backend pour obtenir des données. Attendez que toutes les données soient récupérées.
Récupération lente après un plantage Un general_log volumineux s'est peut-être accumulé. Gérez la journalisation générale. En savoir plus
Vous voulez savoir ce qui consomme de l'espace de stockage. Ce sont principalement les tables de base de données, les journaux binaires ou les fichiers temporaires. Consultez ces conseils pour savoir comment vérifier.
Les requêtes sont bloquées. Un processus bloque tous les autres. Recherchez et arrêtez le processus à l'origine du blocage. En savoir plus
Impossible de supprimer manuellement les journaux binaires Les journaux binaires ne peuvent pas être supprimés manuellement. Les journaux binaires sont automatiquement supprimés, ainsi que leur sauvegarde automatique associée, généralement au bout de sept jours environ.
Vous souhaitez obtenir des informations sur les fichiers temporaires. Le nom du fichier temporaire est ibtmp1. Essayez cette requête de base de données pour en savoir plus.
Vous souhaitez connaître les tailles des tables. Ces informations sont disponibles dans la base de données. Essayez ces requêtes de base de données pour en savoir plus.
mysqld a reçu un signal 11. L'instance a planté, car les requêtes créent trop de connexions. Refactorisez les requêtes pour éviter ce problème.
InnoDB: page_cleaner: 1000ms intended loop took 5215ms. The settings might not be optimal. L'opération de nettoyage de page ne peut pas suivre le rythme des changements sur l'instance. La segmentation de l'instance peut s'avérer utile.
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. En savoir plus.
Les données sont automatiquement supprimées. Un script est en cours d'exécution quelque part. Essayez de trouver le script.
Impossible de supprimer l'instance. Il peut y avoir plusieurs causes premières. Il peut y avoir plusieurs solutions.
L'instance se bloque en raison du volume important des données temporaires. Trop de tables temporaires ont été créées à la fois. Redémarrez l'instance et essayez cette mesure d'atténuation.
Erreur fatale lors de la mise à niveau. Il peut y avoir de nombreuses causes. Les journaux peuvent fournir davantage d'informations. Vous devrez peut-être contacter le service client pour forcer le redémarrage.
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. Activez l'augmentation automatique de l'espace de stockage.
L'instance principale sur site est bloquée. ND Le service client Cloud SQL ne peut pas vous aider au niveau des instances qui ne sont pas dans Cloud SQL.
Un arrêt lent se produit au redémarrage. Les connexions en attente qui ne se terminent pas au bout de 60 secondes peuvent entraîner des arrêts incorrects. Limitez les connexions à moins de 60 secondes.
Access denied for user Authentification des utilisateurs, ou certificats SSL/TLS arrivés à expiration. Vérifiez les états des utilisateurs et des certificats.
Impossible de supprimer un utilisateur. Il se peut que l'utilisateur possède des objets dans la base de données. Vous devrez peut-être supprimer ou réattribuer des objets.
Impossible d'attribuer une adresse IP privée à une instance existante dans un VPC partagé. Les adresses d'instance sont liées à leurs projets lors de leur création. Créez une instance Cloud SQL pour remplacer l'instance existante.
Certaines requêtes sont lentes. Problèmes spécifiques liés à la base de données ou latence du réseau. Consultez ces suggestions.
Mémoire insuffisante signalée, mais non reportée dans les graphiques de surveillance. Une partie de la mémoire RAM est peut-être utilisée par des processus internes. Assurez-vous que l'instance présente une surcharge suffisante pour votre charge de travail.

Lenteur des performances après le redémarrage

Lenteur des performances après le redémarrage

Cause possible

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.

Solutions possibles

ND


Récupération lente après un plantage

Récupération lente après un plantage

Cause possible

Un general_log volumineux s'est peut-être accumulé.

Solutions possibles

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;


Déterminer ce qui consomme l'espace de stockage.

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.

Cause possible

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;

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

Cause possible

Un processus bloque tous les autres.

Solutions possibles

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

Vous constatez que vous ne parvenez pas à supprimer manuellement les journaux binaires.

Cause possible

Les journaux binaires ne peuvent pas être supprimés manuellement.

Solutions possibles

Les journaux binaires sont automatiquement supprimés, ainsi que leur sauvegarde automatique associée, au bout de sept jours environ.


Vous souhaitez trouver des informations sur les fichiers temporaires.

Vous souhaitez obtenir des informations sur les fichiers temporaires.

Cause possible

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.

Solutions possibles

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


Déterminer les tailles des tables.

Vous souhaitez connaître les tailles des tables dans votre base de données.

Cause possible

Ces informations sont disponibles dans la base de données.

Solutions possibles

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

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'erreur suivante se produit :

mysqld got signal 11.

Cause possible

L'instance a probablement planté, car les requêtes créent trop de connexions.

Solutions possibles

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


InnoDB: page_cleaner

Le serveur continue de se bloquer, et vous obtenez une erreur de ce type : InnoDB: page_cleaner: 1000ms intended loop took 5215ms. The settings might not be optimal.

Cause possible

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.

Solutions possibles

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.

Les tables temporaires ont augmenté l'utilisation de l'espace de stockage et généré l'augmentation automatique de l'espace de stockage.

Cause possible

L'augmentation automatique de l'espace de stockage est activée.

Solutions possibles

La suppression des tables temporaires par le redémarrage ne réduit pas la taille de l'espace de stockage automatiquement augmentée.


Suppression automatique des données

Vous constatez que les données sont automatiquement supprimées à intervalles réguliers.

Cause possible

Il est probable qu'un script s'exécute quelque part dans votre environnement.

Solutions possibles

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.

Cause possible

  1. Une autre opération est en cours d'exécution.
  2. L'avertissement INSTANCE_RISKY_FLAG_CONFIG est déclenché chaque fois qu'au moins une option beta est utilisée.

Solutions possibles

  1. Les opérations Cloud SQL ne s'exécutent pas simultanément. Attendez que l'autre opération se termine.
  2. Supprimez les paramètres risqués de l'option et redémarrez l'instance.

Blocage du système en raison d'un volume important de données temporaires

Le système se bloque en raison du volume important des données temporaires.

Cause possible

Le système peut créer plusieurs tables temporaires à la fois, en fonction des requêtes et de la charge.

Solutions possibles

Malheureusement, vous ne pouvez pas réduire le fichier ibtmp1 sans redémarrer 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

Le message d'erreur ERROR_INTERNAL_FATAL s'affiche lorsque vous mettez à niveau des ressources sur une instance.

Cause possible

Il peut y avoir de nombreuses causes.

Solutions possibles

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.


Blocage de l'instance au redémarrage en raison d'un espace disque insuffisant

L'instance se bloque au redémarrage, car l'espace disque est épuisé.

Cause possible

La fonctionnalité d'augmentation automatique de l'espace de stockage n'est pas activée.

Solutions possibles

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

Vous souhaitez savoir si le service client de Cloud SQL peut vous aider lorsqu'une instance principale sur site est bloquée.

Cause possible

L'instance n'est pas dans Cloud SQL.

Solutions possibles

Le service client Cloud SQL ne peut pas vous aider au niveau des instances qui ne sont pas dans Cloud SQL


Arrêt lent au redémarrage

Un arrêt lent se produit au redémarrage.

Cause possible

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.

Solutions possibles

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 non propres.


Accès refusé pour l'utilisateur

Le message d'erreur Access denied for user 'XXX'@'XXX' (using password: XXX) s'affiche.

Cause possible

Plusieurs causes premières sont possibles, dont les suivantes :

  • Le nom d'utilisateur (ou le mot de passe) est incorrect.
  • L'utilisateur se connecte depuis une adresse autre que @XXX.
  • L'utilisateur ne dispose pas des droits appropriés pour la base de données à laquelle il tente de se connecter.

Solutions possibles

  • Vérifiez le nom d'utilisateur et le mot de passe correspondant.
  • Vérifiez l'origine de la connexion pour voir si elle correspond aux droits d'accès accordés à l'utilisateur.
  • Vérifiez les droits de l'utilisateur dans la base de données.

Impossible de supprimer l'utilisateur

Vous ne pouvez pas supprimer un utilisateur de base de données.

Cause possible

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

Solutions possibles

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.


Impossible d'attribuer une adresse IP privée à une instance existante dans un VPC partagé

Vous ne pouvez pas attribuer d'adresse IP privée à une instance existante dans un VPC partagé.

Cause possible

En effet, lorsqu'une instance Cloud SQL est créée, elle est automatiquement associée à un projet locataire, de même que toutes les instances Cloud SQL de ce même projet. Cependant, lorsque l'instance créée utilise une adresse IP privée dans un VPC partagé, elle est associée au projet locataire lui-même associé au projet hôte de VPC partagé.

Solutions possibles

Vous pouvez créer une instance Cloud SQL pour remplacer l'instance existante.


Certaines requêtes sont lentes

L'utilisation du processeur est toujours élevée.

Cause possible

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.

Solutions possibles

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 :

  • 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 échoue et renvoie Out of memory, mais les graphiques de la console ou de Cloud Monitoring semblent indiquer qu'il reste encore de la mémoire.

Cause possible

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 affichés dans les graphiques de surveillance.

Solutions possibles

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

Duplication

Cliquez sur les liens du tableau pour en savoir plus :

Pour ce problème... Le problème peut être... Essayez ce qui suit...
L'instance dupliquée avec accès en lecture n'a pas commencé à se dupliquer lors de la création. Au moins une sauvegarde doit avoir été créée depuis que la journalisation binaire a été activée. Attendez qu'au moins une sauvegarde ait été créée après avoir activé les journaux binaires.
Impossible de créer l'instance dupliquée avec accès en lecture : erreur inconnue. Il peut y avoir plusieurs causes. Consultez les journaux pour en savoir plus.
Le disque est saturé. Le disque de l'instance principale peut arriver à saturation lors de la création de l'instance dupliquée. Mettez à niveau l'instance principale en augmentant la taille du disque.
L'instance dupliquée utilise trop de mémoire. Les instances dupliquées peuvent mettre en cache les opérations de lecture souvent demandées. Redémarrez l'instance dupliquée afin de récupérer l'espace de mémoire temporaire.
La duplication s'est arrêtée. L'espace de stockage maximal a été atteint et l'augmentation automatique de l'espace de stockage n'est pas activée. Activez l'augmentation automatique de l'espace de stockage.
Le délai de duplication est systématiquement long. Il peut y avoir de nombreuses causes premières. Voici quelques astuces à essayer.

L'instance dupliquée avec accès en lecture n'a pas commencé à se dupliquer lors de la création

L'instance dupliquée avec accès en lecture n'a pas commencé à se dupliquer lors de la création.

Cause possible

Pour que les instances dupliquées commencent à se dupliquer, l'instance principale doit comporter au moins une semaine de binlogs.

Solutions possibles

Attendez qu'il y ait suffisamment de binlogs.


Impossible de créer l'instance dupliquée avec accès en lecture : erreur inconnue

Impossible de créer l'instance dupliquée avec accès en lecture : unknown error.

Cause possible

Les fichiers journaux indiquent probablement une erreur plus spécifique.

Solutions possibles

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é

Erreur UPDATE_DISK_SIZE ou mysqld: disk is full.

Cause possible

Le disque de l'instance principale peut arriver à saturation lors de la création de l'instance dupliquée.

Solutions possibles

Modifiez l'instance principale en augmentant la taille du disque.


L'instance dupliquée utilise trop de mémoire

L'instance dupliquée utilise trop de mémoire.

Cause possible

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.

Solutions possibles

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


Duplication arrêtée

La duplication s'est arrêtée.

Cause possible

La limite maximale de l'espace de stockage a été atteinte et l'augmentation automatique de l'espace de stockage est désactivée (>automatic storage increase is disabled).

Solutions possibles

Modifiez l'instance en activant automatic storage increase.


Délai de duplication systématiquement long

Le délai de duplication est systématiquement long.

Cause possible

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. Vous pouvez les identifier en activant log_slow_slave_statements, puis les corriger.
  • 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.

Solutions possibles

Voici quelques solutions possibles :

  • Modifiez l'instance pour augmenter la taille de l'instance dupliquée.
  • Réduisez la charge sur la base de données.
  • Indexez les tables.
  • Identifiez et corrigez les requêtes lentes.
  • Recréez l'instance dupliquée.