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

Cette page inclut des conseils pour résoudre les problèmes de Cloud SQL pour les moteurs de base de données compatibles. Certains de ces conseils ne s'appliquent qu'à des moteurs de base de données spécifiques, tandis que d'autres sont communs à tous.

Pour obtenir des conseils de dépannage pour des moteurs de base de données spécifiques, consultez leurs pages individuelles :

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.
Aucune notification concernant les échecs de sauvegarde. Les notifications ne sont pas disponibles pour les échecs de sauvegarde. Utilisez l'API REST ou les commandes gcloud pour vérifier l'état d'une sauvegarde.
L'instance est bloquée entre l'état d'échec et l'état de restauration de sauvegarde. Trop de trafic ou trop de connexions ouvertes. Vérifiez les paramètres autovacuum et la logique de nouvelle tentative.
Des données sont manquantes dans une sauvegarde. Les tables non consignées ne sont pas restaurées à partir de la sauvegarde. Consultez ces remarques sur les tables non consigné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 :

  • 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 qu'il ne dépasse pas le quota de disque. 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.


L'instance est bloquée entre l'état d'échec et l'état de restauration de sauvegarde.

Une instance échoue à plusieurs reprises, car elle passe de l'état d'échec à l'état de restauration de sauvegarde. Tentatives de connexion à la base de données et d'utilisation de la base de données après un échec de la restauration.

Cause possible

  • Il se peut qu'il y ait trop de connexions ouvertes. Un trop grand nombre de connexions peut entraîner des erreurs se produisant au milieu d'une connexion où aucun paramètre autovacuum n'est configuré pour nettoyer les connexions interrompues.
  • Le passage d'un état à l'autre peut se produire si un code personnalisé utilise une logique de nouvelle tentative qui ne s'arrête pas après quelques échecs.
  • Le trafic est peut-être trop important. Utilisez le pooling de connexions et d'autres bonnes pratiques en termes de connectivité.

Solutions possibles

  1. Vérifiez que la base de données est configurée pour autovacuum.
  2. Vérifiez si une logique de nouvelle tentative de connexion est configurée dans le code personnalisé.
  3. Réduisez le trafic jusqu'à ce que la base de données récupère, puis augmentez lentement le trafic.

Des données sont manquantes dans une sauvegarde

Vous constatez qu'il manque des données lors d'une opération de sauvegarde/restauration.

Cause possible

Les tables ont été créées comme non consignées. Exemple :

CREATE UNLOGGED TABLE ....

Les tables suivantes ne sont pas incluses dans une restauration à partir d'une sauvegarde :

  • Le contenu des tables non consignées ne survit pas au basculement sur l'instance à haute disponibilité.
  • Les tables non consignées ne survivent pas aux plantages Postgres.
  • Les tables non consignées ne sont pas répliquées sur les instances dupliquées avec accès en lecture.
  • Les tables non consignées (UNLOGGED) sont automatiquement effacées lors de la restauration de la sauvegarde.

Solutions possibles

La solution consiste à éviter d'utiliser des tables non consignées si vous souhaitez restaurer ces tables via une sauvegarde. Si vous effectuez une restauration à partir d'une base de données contenant déjà des tables non consignées, vous pouvez vider la base de données dans un fichier, puis recharger les données après avoir modifié le fichier de vidage afin de modifier la table (ALTER TABLE) pour définir ces tables comme consignées (SET LOGGED).


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.

Aucune notification concernant les échecs de sauvegarde

La sauvegarde automatique a échoué et vous n'avez pas reçu de notification par e-mail.

Cause possible

Les notifications ne sont pas disponibles pour les échecs de sauvegarde.

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

Solutions possibles

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

gcloud sql --project=PROJECT_ID backups list --instance=INSTANCE_ID
gcloud sql --project=PROJECT_ID backups describe BACKUP-ID --instance=INSTANCE_ID

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.
FATAL: database 'user' does not exist. gcloud sql connect --user ne fonctionne qu'avec l'utilisateur postgres par défaut. Connectez-vous avec l'utilisateur par défaut, puis changez d'utilisateur.
SSL error: invalid padding. Erreur de certificat du serveur. Créez un certificat de serveur et effectuez une rotation.
Vous voulez savoir qui est connecté. ND 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. Le compte de service Service Networking n'est pas lié au rôle servicenetworking.serviceAgent. Associez le compte de service Service Networking au rôle servicenetworking.serviceAgent.
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.
Impossible d'analyser les certificats dans certains systèmes d'exploitation Les clients utilisant des bibliothèques x509 de macOS 11.0 (Big Sur) peuvent ne pas parvenir à analyser certains certificats d'instances mysql. L'erreur peut être présentée au client en tant qu'erreur générique, par exemple "Annulé". La solution consiste à effectuer une rotation du certificat du serveur et à recréer les certificats client.
Cannot modify allocated ranges in CreateConnection. Please use UpdateConnection. Les appairages VPC n'ont pas été mis à jour après la modification ou la suppression d'une plage allouée. Pour en savoir plus sur les mises à jour de l'appairage VPC, consultez la section Essayer.
Allocated IP range not found in network. Les appairages VPC n'ont pas été mis à jour après la modification ou la suppression d'une plage allouée. Pour en savoir plus sur les mises à jour de l'appairage VPC, consultez la section Essayer.
ERROR: (gcloud.sql.connect) It seems your client does not have ipv6 connectivity and the database instance does not have an ipv4 address. Please request an ipv4 address for this database instance.. Vous essayez de vous connecter à votre instance IP privée à l'aide de Cloud Shell. À l'heure actuelle, il n'est pas possible de se connecter depuis Cloud Shell à une instance avec une adresse IP privée seulement.

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.


FATAL: La base de données "user" n'existe pas

Le message d'erreur FATAL: database 'user' does not exist s'affiche lorsque vous essayez de vous connecter à une instance PostgreSQL à l'aide de gcloud sql connect --user.

Cause possible

La commande gcloud sql connect --user ne fonctionne qu'avec l'utilisateur par défaut (postgres).

Solutions possibles

La solution consiste à vous connecter à l'aide de l'utilisateur par défaut, puis à utiliser la commande psql "\c" pour vous reconnecter en tant qu'utilisateur différent.


Erreur SSL : marge intérieure incorrecte

Le message d'erreur SSL error: invalid padding s'affiche lorsque vous essayez de vous connecter à une instance PostgreSQL à l'aide de SSL.

Cause possible

Une erreur s'est peut-être produite au niveau du certificat server-ca.

Solutions possibles

Créez un certificat server-ca et effectuez une rotation des certificats du serveur.


Vous voulez savoir qui est connecté.

Vous voulez savoir qui est connecté et depuis combien de temps.

Cause possible

ND

Solutions possibles

Connectez-vous à la base de données et exécutez la commande suivante : SELECT datname, usename, application_name as appname, client_addr, state, now() - backend_start as conn_age, now() - state_change as last_activity_age FROM pg_stat_activity WHERE backend_type = 'client backend' ORDER BY 6 DESC LIMIT 20</code>


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 :

    Si vous vous connectez via le proxy d'authentification 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.


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

Le compte de service Service Networking n'est pas lié au rôle servicenetworking.serviceAgent.

Solutions possibles

Pour résoudre ce problème, essayez d'associer le compte de service Service Networking au rôle servicenetworking.serviceAgent via ces commandes gcloud.

gcloud beta services identity create --service=servicenetworking.googleapis.com --project=PROJECT_ID
gcloud projects add-iam-policy-binding PROJECT_ID --member="serviceAccount:service-PROJECT_NUMBER@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.


Impossible d'analyser les certificats dans certains systèmes d'exploitation

Lorsque vous utilisez des bibliothèques x509 de macOS 11.0 (Big Sur), il se peut que vous ne parveniez pas à analyser certains certificats d'instances mysql. L'erreur peut être présentée en tant qu'erreur générique, par exemple "Annulé".

Solutions possibles

Le bug est corrigé et les nouvelles instances ne rencontreront pas ce problème. Si d'anciennes instances rencontrent ce problème, effectuez une rotation du certificat de serveur et recréez les certificats client.


Impossible de modifier les plages allouées dans CreateConnection. Veuillez utiliser UpdateConnection

Le message d'erreur Cannot modify allocated ranges in CreateConnection. Please use UpdateConnection ou The operation "operations/1234" resulted in a failure "Allocated IP range 'xyz' not found in network s'affiche.

Cause possible

La première erreur se produit lorsque vous tentez d'établir à nouveau une connexion à l'aide d'une plage réservée différente.

Vous voyez la deuxième erreur lorsque la plage allouée a été modifiée, mais vpc-peerings n'a pas été mise à jour.

Solutions possibles

Vous devez modifier la connexion privée. Exécutez la commande suivante et veillez à utiliser l'argument --force :

gcloud services vpc-peerings update --network=VPC_NETWORK --ranges=ALLOCATED_RANGES --service=servicenetworking.googleapis.com --force

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

Il est possible que l'API Service Networking ne soit pas activée.

Vous essayez peut-être de créer une instance portant le même nom qu'une instance récemment supprimée.

Vous essayez peut-être de créer plusieurs instances simultanément.

La création de votre sous-réseau a peut-être échoué s'il n'y a plus d'adresses disponibles dans la plage d'adresses IP.

Activez l'API Service Networking.

Attribuez un autre nom à l'instance ou attendez une semaine à compter de sa suppression.

Créez des instances de façon consécutive.

Consultez les autres messages d'erreur inconnue si cela ne correspond pas à votre cas.

Allouez de nouvelles plages.

Failed to create subnetwork. Aucune autre adresse disponible dans la plage d'adresses IP. Allouez de nouvelles plages.

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

  • Il est possible que l'activation de l'API Service Networking n'ait pas réussi.
  • Vous tentez peut-être 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 avant de pouvoir réutiliser son nom.
  • Vous essayez peut-être de créer plusieurs instances simultanément. Dans ce cas, seule la première instance est créée et la nouvelle tentative échoue avec Unknown error. Vous ne pouvez exécuter qu'une seule opération de création à la fois.
  • La création de votre sous-réseau a peut-être échoué s'il n'y a plus d'adresses disponibles dans la plage d'adresses IP.

Solutions possibles

  • Activez l'API Service Networking.
  • 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.
  • Reportez-vous à la section Échec de la création du sous-réseau ci-dessous.

Échec de la création du sous-réseau

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.

Cause possible

Il n'y a plus d'adresses disponibles dans la plage d'adresses IP allouée.

Si vous rencontrez cette erreur lorsque vous essayez de créer une instance Cloud SQL avec une adresse IP privée sur un réseau VPC partagé utilisant des connexions de service privé, cinq 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é.

Solutions possibles

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 allouez une nouvelle plage, veillez à ne pas créer d'allocation qui chevauche des allocations existantes.

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]

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 LDD (langage de définition de données) ont été appliquées pendant le processus de vidage. Évitez les modifications du LDD pendant le processus de vidage.
Message d'erreur : Access denied; you need (at least one of) the SUPER privilege(s) for this operation. Il est possible qu'une vue, une fonction ou une procédure de la base de données source fasse référence à DEFINER d'une manière non acceptée par Cloud SQL. En savoir plus sur l'utilisation de DEFINER dans Cloud SQL.
Message d'erreur : ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost La base de données source contient une clause DEFINER qui n'existe pas dans l'instance dupliquée. 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 la paramétrage de ces 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 ces solutions.
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 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 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.


Message d'erreur ERROR 1045 (28000) à la ligne xxx : Accès refusé pour l'utilisateur 'cloudsqlimport'@'localhost

L'erreur ERROR 1045 (28000) at line xxx: Access denied for user 'cloudsqlimport'@'localhost s'affiche.

Cause possible

Un utilisateur de la base de données source avec la clause DEFINER n'existe pas dans la base de données dupliquée, alors qu'il est également référencé dans les définitions d'objets de la base de données source.

Solutions possibles

Les utilisateurs ne sont pas transférés avec les données. Créez les utilisateurs de la base de données source dans la base de données dupliquée avant de lancer la réplication.


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

  • Il est possible que l'instance dupliquée ne parvienne plus à se connecter à la source.

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

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 répliquée.

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

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.

Instance dupliquée externe

Cliquez sur les liens du tableau pour en savoir plus :

Pour ce problème... Le problème peut être... Essayez ce qui suit...
Message d'erreur : The slave is connecting ... master has purged binary logs containing GTIDs that the slave requires. L'instance dupliquée ne sait pas où commencer à lire les journaux. Créez un nouveau fichier de vidage avec les options appropriées puis configurez l'instance dupliquée externe en utilisant ce fichier.

Journaux binaires supprimés contenant des GTID

Le message d'erreur suivant s'affiche : The slave is connecting ... master has purged binary logs containing GTIDs that the slave requires dans MySQL.

Cause possible

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.

Solutions possibles

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 SQL 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

Cliquez sur les liens du tableau pour en savoir plus :

Pour ce problème... Le problème peut être... Essayez ce qui suit...
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.
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
Aucune option présente permettant de définir le fuseau horaire. Option de fuseau horaire non disponible. Il existe des solutions.

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.


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.

Aucune option présente permettant de définir le fuseau horaire

PostgreSQL et SQL Server pour Cloud SQL n'acceptent pas d'option de fuseau horaire pour ajuster le fuseau horaire en fonction des besoins de l'utilisateur.

Cause possible

Option de fuseau horaire non disponible.

Solutions possibles

Vous pouvez définir le fuseau horaire par session, mais celle-ci expire lorsque vous vous déconnectez. La meilleure solution consiste à vous connecter à la base de données et à définir le fuseau horaire souhaité pour celle-ci, par utilisateur ou par base de données :

ALTER DATABASE dbname SET TIMEZONE TO 'timezone';
ALTER USER username SET TIMEZONE TO 'timezone';

Ces paramètres restent accessibles même après la fermeture de la session, ce qui imite la configuration .conf.

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.

Importer

Cliquez sur les liens du tableau pour en savoir plus :

Pour ce problème... Le problème peut être... Essayez ce qui suit...
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.
Échec de l'importation. Le fichier exporté peut contenir des utilisateurs de base de données qui n'existent pas encore. Nettoyez la base de données en échec avant de relancer l'importation. Créez les utilisateurs de la base de données avant d'effectuer l'importation.
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.
Message d'erreur : ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost'. Le fichier de vidage contient une clause DEFINER qui n'existe pas dans la base de données. Découvrez plus d'informations sur l'utilisation de DEFINER et sur les solutions de contournement potentielles dans Cloud SQL.
Message d'erreur : Unknown table 'COLUMN_STATISTICS' in information_schema. Cela se produit si vous utilisez le binaire mysqldump de MySQL 8.0 pour vider les données d'une base de données MySQL 5.7 et les importer dans une base de données MySQL 8.0. Si vous videz les données d'une base de données MySQL 5.7 et que vous les importez dans une base de données MySQL 8.0, veillez à utiliser le binaire mysqldump de MySQL 5.7. Si vous utilisez le binaire mysqldump de MySQL 8.0, vous devez ajouter l'option --column-statistics=0.

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.


É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

Nettoyez la base de données en échec avant de relancer l'importation. Créez les utilisateurs de la base de données avant d'importer le fichier de vidage SQL.


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.


Message d'erreur : ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost'

L'erreur ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost' s'affiche.

Cause possible

L'origine du problème est qu'un utilisateur du fichier de vidage avec la clause DEFINER n'existe pas dans la base de données, alors qu'il est également référencé dans les définitions d'objets de la base de données.

Solutions possibles

Reportez-vous à ce document pour en savoir plus sur l'importation d'une base de données dont le fichier de vidage contient des clauses DEFINER. Vous devrez d'abord créer un ou plusieurs utilisateurs dans la base de données.


Message d'erreur : Table "COLUMN_STATISTICS" inconnue dans "information_schema"

Le message d'erreur Unknown table 'COLUMN_STATISTICS' in information_schema s'affiche.

Cause possible

Cela se produit si vous utilisez le binaire mysqldump de MySQL 8.0 pour vider les données d'une base de données MySQL 5.7 et les importer dans une base de données MySQL 8.0.

Solutions possibles

Si vous videz les données d'une base de données MySQL 5.7 et que vous les importez dans une base de données MySQL 8.0, veillez à utiliser le binaire mysqldump de MySQL 5.7. Si vous utilisez le binaire mysqldump de MySQL 8.0, vous devez ajouter l'option --column-statistics=0.

Exporter

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
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.
Erreur de création de l'extension Le fichier de vidage contient des références à une extension non compatible. Modifiez le fichier de vidage pour supprimer les références.
Erreur lors de l'utilisation de pg_dumpall. L'outil nécessite un rôle de super-utilisateur. Le rôle de super-utilisateur n'est pas compatible.
L'opération d'exportation expire avant d'exporter des données. La requête doit produire des données dans les sept premières minutes. Essayez une exportation manuelle à l'aide de l'outil pg_dump.
La connexion se ferme 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
Message d'erreur : Access denied; you need (at least one of) the SUPER privilege(s) for this operation. Il est possible qu'un événement, une vue, une fonction ou une procédure du fichier de vidage utilise un super-utilisateur@localhost (tel que root@localhost). Cette méthode n'est pas compatible avec Cloud SQL. En savoir plus sur l'utilisation de DEFINER et sur les solutions potentielles dans Cloud SQL.

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.


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.



Erreur lors de l'utilisation de pg_dumpall

Vous obtenez une erreur lorsque vous essayez d'utiliser l'outil de ligne de commande pg_dumpall externe.

Cause possible

Cet outil nécessite le rôle de super-utilisateur.

Solutions possibles

Cloud SQL est un service géré qui ne donne pas aux utilisateurs les rôles ou les autorisations de super-utilisateur.


Connexion réinitialisée par l’homologue

L'opération d'exportation expire avant l'exportation. Le message d'erreur Could not receive data from client: Connection reset by peer. s'affiche.

Cause possible

Si Cloud Storage ne reçoit aucune donnée dans un délai donné, la connexion est réinitialisée.

Solutions possibles

Effectuez une exportation manuelle à l'aide de l'outil pg_dump.


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.

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

Il est possible qu'un événement, une vue, une fonction ou une procédure du fichier de vidage utilise un super-utilisateur@localhost (tel que root@localhost). Cette méthode n'est pas compatible avec Cloud SQL.

Solutions possibles

Reportez-vous à ce document pour savoir comment importer une base de données avec des clauses DEFINER.

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.
Les fichiers journaux sont difficiles à lire. Vous préférez que les journaux soient au format JSON ou texte. Exécutez les commandes gcloud logging.
Les journaux de requêtes sont introuvables dans les journaux PostgreSQL. Vous devez activer les options pgaudit. Utilisez ces commandes gcloud sql.

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

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;

Les fichiers journaux sont difficiles à lire

Vous peinez à lire les journaux dans l'explorateur de journaux.

Cause possible

Nous vous conseillons de télécharger les journaux en local au format JSON ou texte.

Solutions possibles

Vous pouvez exécuter la commande gcloud logging read avec les commandes de post-traitement Linux pour télécharger les journaux.

Pour télécharger les journaux au format JSON, exécutez la commande suivante :

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

Pour télécharger les journaux sous forme de texte, exécutez la commande suivante :

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


Journaux de requête introuvables

Vous ne trouvez pas de journaux de requêtes dans Cloud Logging pour PostgreSQL.

Cause possible

Vous devez activer les options pgaudit.

Solutions possibles

  1. Depuis un terminal, connectez-vous à la base de données :

    gcloud sql connect $INSTANCE_NAME
    

  2. Une fois dans la base de données, exécutez la commande suivante pour créer l'extension :

    CREATE EXTENSION pgaudit;
    

  3. Quittez la base de données et exécutez la commande suivante à partir d'un terminal :

    gcloud sql instances patch $INSTANCE_NAME --database-flags cloudsql.enable_pgaudit=on,pgaudit.log=all
    

  4. Enfin, redémarrez l'instance Cloud SQL.

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 de MySQL. 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.
Vous souhaitez savoir quelles requêtes sont en cours d'exécution. ND Essayez cette requête de base de données.
Vous souhaitez savoir quelles unités sont utilisées pour un champ spécifique. ND Essayez cette requête de base de données.
Vous souhaitez connaître la valeur actuelle d'un paramètre de base de données. ND Essayez ces requêtes de base de données.
Vous souhaitez arrêter un processus en arrière-plan bloqué. L'utilisateur doit détenir le rôle pg_signal_backend. Attribuez le rôle et exécutez ces commandes.
L'instance consomme presque 100 % des ID de transaction. La tâche autovacuum peut être bloquée, ou ne pas récupérer les ID de transaction assez rapidement pour suivre la charge de travail. Consultez ces conseils d'auto-assistance.
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.
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 éviter de perdre des données, exportez-les vers Cloud Storage.
ERROR 1142 (42000): ANY command denied to user 'root'@'%' for table .... L'utilisateur ne dispose pas de toutes les autorisations requises pour effectuer cette opération. Connectez-vous, puis exécutez les commandes détaillées sur cette page.
Vous souhaitez renommer une instance Cloud SQL existante. Il n'est pas possible de renommer une instance existante. Il existe plusieurs façons d'atteindre cet objectif en créant une instance.
Metadata table locked. Une autre requête, un processus ou une transaction bloque votre requête et verrouille la table. Recherchez et arrêtez le processus à l'origine du blocage, puis redémarrez l'instance.

Lenteur des performances après le redémarrage de MySQL

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;
  • 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 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.


Déterminer quelles requêtes sont en cours d'exécution

Vous souhaitez savoir quelles requêtes s'exécutent actuellement dans PostgreSQL.

Cause possible

ND

Solutions possibles

Connectez-vous à la base de données et exécutez la requête suivante : SELECT datname, usename, application_name as appname, client_addr, state, now() - backend_start as conn_age, now() - xact_start as xact_age, now() - query_start as query_age, now() - state_change as last_activity_age, wait_event_type, wait_event, query FROM pg_stat_activity WHERE state <> 'idle' ORDER BY 8 DESC LIMIT 20;


Déterminer quelles unités sont en cours d'utilisation pour un champ

Vous voulez savoir quelles unités sont en cours d'utilisation pour un champ particulier.

Cause possible

ND

Solutions possibles

Connectez-vous à la base de données et exécutez cette requête (à l'aide de votre propre valeur FIELD_NAME) : SELECT name, setting, unit FROM pg_settings WHERE name = '[FIELD_NAME]'.


Vous souhaitez déterminer la valeur actuelle d'un paramètre

Vous souhaitez connaître la valeur actuelle d'un paramètre spécifique.

Cause possible

ND

Solutions possibles

Connectez-vous à la base de données et exécutez cette requête (à l'aide de votre propre valeur SETTING_NAME) : SHOW SETTING_NAME; ou SHOW ALL; pour afficher tous les paramètres.

Vous souhaitez arrêter un processus en arrière-plan bloqué

Vous souhaitez arrêter un processus en arrière-plan bloqué, tel que le processus autovacuum.

Cause possible

L'utilisateur ne dispose pas du rôle approprié. Il doit détenir le rôle pg_signal_backend.

Solutions possibles

  1. Connectez-vous à la base de données et exécutez la commande suivante :
      GRANT pg_signal_backend TO USERNAME;
      
  2. Recherchez l'ID du processus bloqué :
      SELECT pid, usename, state, query FROM pg_stat_activity;
      
  3. Arrêtez un processus en cours d'exécution ou inactif à l'aide des commandes suivantes :
      SELECT pg_cancel_backend(pid)
            FROM pg_stat_activity
            WHERE usename = 'USERNAME';
      
      
      SELECT pg_terminate_backend(pid)
            FROM pg_stat_activity
            WHERE usename = 'USERNAME';
      
      

L'instance consomme presque 100 % des ID de transaction.

Votre système de surveillance interne vous avertit que l'instance consomme presque 100 % des ID de transaction. Il convient d'éviter la réinitialisation des transactions, qui peut bloquer les écritures.

Cause possible

La tâche autovacuum peut être bloquée, ou ne pas récupérer les ID de transaction assez rapidement pour suivre la charge de travail.

Solutions possibles

Afin d'éviter toute interruption de service due à un problème de réinitialisation des transactions, consultez ces conseils d'auto-assistance pour gérer la réinitialisation des TXID.

Pour obtenir des conseils généraux de paramétrage, consultez la section Optimiser, surveiller et dépanner les opérations VACUUM dans PostgreSQL.


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.


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

Lorsqu'une instance est supprimée intentionnellement ou accidentellement, vous ne pouvez pas annuler sa suppression.

Cause possible

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

Solutions possibles

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.


Message d'erreur ERROR 1142 (42000) : utilisation de la commande 'ANY' refusée à l'utilisateur 'root'@'%' pour la table...

Si vous utilisez MySQL 5.7, vous pouvez rencontrer l'erreur ERROR 1142 (42000): ANY command denied to user 'root'@'%' for table ''" lorsque vous créez une vue comportant plusieurs niveaux de sélection.

Cause possible

L'utilisateur ne dispose pas de toutes les autorisations requises pour effectuer cette opération.

Solutions possibles

  1. Connectez-vous à la base de données (par exemple, en utilisant Cloud Shell) et ouvrez une session en tant qu'utilisateur root.
  2. Exécutez la commande USE mysql;.
  3. Exécutez la commande GRANT suivante :
    GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, SHUTDOWN, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER, CREATE TABLESPACE ON . TO 'root' WITH GRANT OPTION;
    
  4. Exécutez la commande USE 'Database_Name';, où Database_Name est la base de données dans laquelle vous créez les vues.
  5. Exécutez toutes les commandes de création de vue dans la session et validez-les.

Vous souhaitez renommer une instance Cloud SQL existante

Pour des raisons commerciales ou autres, vous souhaitez renommer une instance Cloud SQL existante.

Cause possible

Vous ne pouvez pas renommer une instance à partir de Google Cloud Console ou d'une API.

Solutions possibles

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

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

  2. 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 indicateurs, le type de machine, la taille de stockage et la mémoire).


Table des métadonnées verrouillée

Vous avez effectué une requête sur votre base de données (par exemple, ALTER TABLE) et vous avez reçu un message d'erreur indiquant que la table de métadonnées est verrouillée. La base de données ne termine pas votre requête et ne répond plus aux activités ultérieures.

Cause possible

Une autre requête, transaction ou processus bloque votre requête et verrouille la table des métadonnées.

Solutions possibles

Recherchez le processus qui a verrouillé la table et arrêtez-le.

  • Diagnostiquez à l'aide de la commande : sql> show processlist. Le premier élément de la liste peut être celui conservant le verrouillage, que les éléments suivants attendent.
  • La commande SHOW INNODB STATUS peut également être utile.
  • KILL <PID>;

Réplication

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. Il peut y avoir plusieurs causes. Consultez les journaux pour en savoir plus.
Impossible de créer l'instance dupliquée avec accès en lecture : erreur invalidFlagValue. L'un des indicateurs fournis explicitement ou par défaut n'est pas valide. Consultez les valeurs et les journaux des indicateurs pour obtenir plus d'informations.
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

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

Solutions possibles

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

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

Cause possible

L'un des indicateurs de la requête n'est pas valide. Il peut s'agir d'un indicateur que vous avez explicitement défini ou d'un indicateur défini sur une valeur par défaut.

Solutions possibles

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

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 :

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