Dépannage

Vérifiez si votre question ou votre problème a déjà été résolu sur l'une des pages suivantes :

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

Sauvegarde et récupération

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

Exécutez la commande gcloud sql operations list pour répertorier toutes les opérations pour l'instance Cloud SQL donnée.
Vous souhaitez savoir qui a initié une opération de sauvegarde à la demande. L'interface utilisateur n'affiche pas l'utilisateur qui a lancé une opération.

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

  • cloudsql.googleapis.com/postgres.log
  • Si Cloud Audit Logs est activé et que vous disposez des autorisations nécessaires pour les afficher, il est possible que cloudaudit.googleapis.com/activity soit également disponible.
Une fois qu'une instance est supprimée, vous ne pouvez plus en effectuer de sauvegarde.

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

Si vous avez exporté les données, créez une instance puis importez les données pour recréer la base de données. Les données exportées sont écrites dans Cloud Storage, d'où sont lues les données importées.
La sauvegarde automatique demeure bloquée pendant de nombreuses heures et ne peut pas être annulée. Les sauvegardes peuvent prendre beaucoup de temps en fonction de la taille de la base de données.

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

Créez les utilisateurs de la base de données avant d'effectuer une restauration à partir du fichier de vidage SQL.
Vous souhaitez augmenter le nombre de jours pendant lesquels vous pouvez conserver les sauvegardes automatiques de sept à 30 jours ou plus. Vous pouvez configurer le nombre de sauvegardes automatiques à conserver (de 1 à 365). Les sauvegardes automatiques sont régulièrement supprimées en fonction de la valeur de conservation configurée. Malheureusement, cela signifie que les sauvegardes visibles sont les seules sauvegardes automatiques à partir desquelles vous pourrez effectuer une restauration.

Pour conserver les sauvegardes indéfiniment, vous pouvez créer des sauvegardes à la demande, car elles ne sont pas supprimées de la même manière que les sauvegardes automatiques. Les sauvegardes à la demande sont conservées indéfiniment, c'est-à-dire jusqu'à leur suppression ou la suppression de l'instance à laquelle elles appartiennent. En revanche, comme les sauvegardes de ce type ne sont pas automatiquement supprimées, elles peuvent affecter la facturation.
La sauvegarde automatique a échoué et vous n'avez pas reçu de notification par e-mail. Pour que Cloud SQL vous informe de l'état de la sauvegarde, configurez une alerte basée sur les journaux.
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.
  • 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 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.
Vous constatez qu'il manque des données lors d'une opération de sauvegarde/restauration. 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 sont automatiquement effacées lors de la restauration de la sauvegarde.

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

Annuler l'importation et l'exportation

Problème Dépannage
Message d'erreur : You can't cancel operation [operation-ID] because this operation isn't in progress.

Vous essayez d'annuler une opération d'importation ou d'exportation terminée, échouée ou annulée. Si l'opération est en cours d'exécution, vous pouvez l'annuler.
Message d'erreur : You can't cancel operation [operation-ID] because Cloud SQL doesn't support the cancellation of an [operation-type] operation.

Cloud SQL n'est pas compatible avec l'annulation de l'opération, car son type d'opération est différent de IMPORT ou EXPORT.
Message d'erreur : The [operation-type] operation isn't cancelled. Wait and retry in a few seconds.

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

Cloner

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

Si possible, supprimez toutes les entrées Authorized Networks de l'instance Cloud SQL. Sinon, créez une instance dupliquée sans aucune entrée Authorized Networks.
Message d'erreur : Failed to create subnetwork. Couldn't find free blocks in allocated IP ranges. Please allocate new ranges for this service provider. Help Token: [help-token-id].

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

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

Connecter

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

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

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

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

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

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

Générez à nouveau les certificats en les recréant.
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.
Vous voulez savoir qui est connecté. 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

Hostname/IP does not match certificate's altnames: Host: localhost. is not in the cert's altnames.

L'adresse hôte ne correspond pas à l'adresse figurant dans les autres noms du certificat de serveur.

Si vous utilisez Node.js avec verify-full ou son équivalent, veuillez utiliser le nom DNS pour le paramètre servername. Le nom DNS se trouve dans le certificat du serveur à l'aide de openssl. Par exemple : openssl x509 -in server-cert.pem -noout -text |grep 'DNS:'.

 ssl: {
  rejectUnauthorized: true,
  ca: fs.readFileSync("/path/to/server/CA"),
  servername: 'N-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx.us-central1.sql.goog'
}

Créer des instances

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

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

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

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

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

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

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

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

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

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

gcloud services vpc-peerings update \
--service=servicenetworking.googleapis.com \
--ranges=RESERVED_RANGE_NAME \
--network=VPC_NETWORK \
--project=PROJECT_ID
Message d'erreur : Failed to create subnetwork. Router status is temporarily unavailable. Please try again later. Help Token: [token-ID]. Essayez de créer à nouveau l'instance Cloud SQL.
Message d'erreur : Failed to create subnetwork. Required 'compute.projects.get' permission for PROJECT_ID. Lorsque vous créez une instance à l'aide d'une adresse IP privée, un compte de service est créé avec le juste-à-temps à l'aide de l'API Service Networking. Si vous avez activé l'API Service Networking récemment, le compte de service peut ne pas être créé et la création de l'instance échoue. Dans ce cas, vous devez attendre que le compte de service se propage dans le système ou l'ajouter manuellement avec les autorisations requises.

Exporter

Problème Dépannage
HTTP Error 409: Operation failed because another operation was already in progress. Une opération est déjà en attente pour votre instance. Il n'est possible d'exécuter qu'une seule opération à la fois. Envoyez votre requête lorsque l'opération en cours est terminée.
HTTP Error 403: The service account does not have the required permissions for the bucket. Assurez-vous que le bucket existe et que le compte de service de l'instance Cloud SQL (qui effectue l'exportation) dispose du rôle Storage Object Creator (roles/storage.objectCreator) pour autoriser l'exportation vers le bucket. Consultez la page Rôles IAM pour Cloud Storage.
L'exportation au format CSV a fonctionné, mais pas l'exportation au format SQL. Les formats CSV et SQL sont exportés de manière différente. Comme le format SQL exporte l'intégralité de la base de données, l'exportation prend probablement plus de temps. Le format CSV vous permet de définir les éléments de la base de données à exporter.

Exportez uniquement les données dont vous avez besoin à l'aide du format CSV.
L'exportation prend trop de temps. Cloud SQL n'est pas compatible avec les opérations synchrones simultanées.

Utilisez le déchargement des exportations. En règle générale, lors du déchargement des exportations, au lieu d'exécuter une exportation sur l'instance source, Cloud SQL lance une instance de déchargement pour effectuer l'exportation. Le déchargement des exportations présente plusieurs avantages, y compris une amélioration des performances sur l'instance source et le déblocage des opérations d'administration pendant l'exportation. Avec le déchargement des exportations, la latence totale peut augmenter en fonction du temps nécessaire à l'affichage de l'instance de déchargement. En règle générale, la latence n'est pas significative pour les exportations de taille raisonnable. Toutefois, si votre exportation est suffisamment petite, vous pouvez constater une augmentation de la latence.
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'utilisation de l'utilitaire pg_dumpall avec l'option --global nécessite le rôle de super-utilisateur, mais ce rôle n'est pas disponible dans Cloud SQL pour PostgreSQL. Pour éviter les erreurs lors de l'exécution d'opérations d'exportation incluant des noms d'utilisateur, utilisez également l'option --no-role-passwords.
L'opération d'exportation expire avant d'exporter des données et le message d'erreur Could not receive data from client: Connection reset by peer. s'affiche. Si Cloud Storage ne reçoit aucune donnée dans les délais impartis (généralement environ sept minutes), la connexion est réinitialisée. Il est possible que l'exécution de la requête d'exportation initiale soit trop longue.

Effectuez une exportation manuelle à l'aide de l'outil pg_dump.
Vous souhaitez automatiser les exportations. Cloud SQL ne permet pas d'automatiser les exportations.

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

Options

Problème Dépannage
Vous définissez le fuseau horaire d'une session, mais celui-ci expire lorsque vous vous déconnectez.

Connectez-vous à la base de données et définissez le fuseau horaire souhaité pour celle-ci, par utilisateur ou par base de données.

Dans Cloud SQL pour PostgreSQL, vous pouvez spécifier les éléments suivants. Ces paramètres restent accessibles après la fermeture d'une session, et imitent une configuration .conf :

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

Ces paramètres ne s'appliquent qu'aux nouvelles connexions à la base de données. Pour constater la modification du fuseau horaire, déconnectez-vous de l'instance, puis reconnectez-vous à celle-ci.

Haute disponibilité

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

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

Importer

Problème Dépannage
Message d'erreur : permission denied for schema public Pour PostgreSQL 15 et versions ultérieures, si la base de données cible est créée à partir de template0, l'importation des données peut échouer. Pour résoudre ce problème, fournissez les droits de schéma public à l'utilisateur cloudsqlsuperuser en exécutant la commande SQL GRANT ALL ON SCHEMA public TO cloudsqlsuperuser.
HTTP Error 409: Operation failed because another operation was already in progress. Une opération est déjà en attente pour votre instance. Il n'est possible d'exécuter qu'une seule opération à la fois. Envoyez votre requête lorsque l'opération en cours est terminée.
L'opération d'importation prend trop de temps. Un trop grand nombre de connexions actives peut interférer avec les opérations d'importation.

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

Un redémarrage :

  • ferme toutes les connexions ;
  • met fin à toutes les tâches susceptibles de consommer des ressources.
Une opération d'importation peut échouer lorsqu'un ou plusieurs utilisateurs référencés dans le fichier de dump n'existent pas. Avant d'importer un fichier de dump, tous les utilisateurs de la base de données qui possèdent des objets ou disposent d'autorisations sur les objets qu'elle contient doivent exister dans la base de données cible. Si ce n'est pas le cas, l'opération d'importation ne parvient pas à recréer les objets en rétablissant les propriétaires ou les autorisations d'origine.

Créez les utilisateurs de la base de données avant de l'importer.
Après l'importation des données, votre taille d'espace disque de données utilisée est beaucoup plus élevée.

L'importation des données peut conduire à une utilisation inattendue du disque. Cette utilisation peut par exemple être due à la récupération à un moment précis.

Pour résoudre ce problème, une fois les données importées, désactivez la récupération à un moment précis si vous souhaitez supprimer les journaux et récupérer de l'espace de stockage. N'oubliez pas que la réduction du stockage utilisé ne réduit pas la taille du stockage provisionné pour l'instance.
Message d'erreur : GRANT stderr: ERROR: must be member of role ROLE_NAME

Ce message d'erreur s'affiche si vous essayez d'importer un fichier de vidage SQL importé dans Cloud Storage dans une base de données Cloud SQL, et que la tâche d'importation s'est exécutée pendant environ quatre jours.

ROLE_NAME est un rôle de base de données personnalisé défini dans la base de données PostgreSQL source. L'utilisateur cloudsqlsuperuser par défaut importe le fichier de vidage SQL. Toutefois, cet utilisateur peut ne pas appartenir au rôle ROLE_NAME.

Pour résoudre ce problème, procédez comme suit :

  1. Créez le rôle ROLE_NAME dans la base de données de destination dans laquelle vous importez le fichier de vidage SQL.

  2. N'utilisez pas l'utilisateur cloudsqlsuperuser pour importer le fichier. Dans la base de données de destination, spécifiez plutôt un utilisateur membre du rôle ROLE_NAME. Pour spécifier l'utilisateur, exécutez la commande suivante :

    gcloud sql import sql INSTANCE URI [--async]
    [--database=DATABASE, -d DATABASE] [--user=USER] [GCLOUD_WIDE_FLAG …]

Intégration de Vertex AI

Problème Dépannage
Message d'erreur : Google ML integration API is supported only on Postgres version 12 or above. Pour activer l'intégration de Vertex AI dans Cloud SQL, vous devez disposer d'une base de données Cloud SQL pour PostgreSQL version 12 ou ultérieure. Pour mettre à niveau votre base de données vers cette version, consultez la page Mettre à niveau la version majeure de la base de données sur place.
Message d'erreur : Google ML Integration API is not supported on shared core instance. Please upsize your machine type. Si vous avez sélectionné un cœur partagé pour le type de machine de votre instance, vous ne pouvez pas activer l'intégration de Vertex AI dans Cloud SQL. Mettez à niveau votre type de machine pour utiliser un cœur dédié. Pour en savoir plus, consultez la section Type de machine.
Message d'erreur : Google ML Integration is unsupported for this maintenance version. Please follow https://cloud.google.com/sql/docs/postgres/self-service-maintenance to update the maintenance version of the instance. Pour activer l'intégration de Vertex AI dans Cloud SQL, la version de maintenance de votre instance doit être une version R20240130 ou ultérieure. Pour mettre à niveau votre instance vers cette version, consultez la section Maintenance en libre-service.
Message d'erreur : Cannot invoke ml_predict_row if 'cloudsql.enable_google_ml_integration' is off. L'option de base de données cloudsql.enable_google_ml_integration est désactivée. Cloud SQL ne peut pas intégrer Vertex AI.

Pour activer cette option, utilisez la commande gcloud sql instances patch :

gcloud sql instances patch INSTANCE_NAME --database-flags cloudsql.enable_google_ml_integration=on

Remplacez INSTANCE_NAME par le nom de l'instance Cloud SQL principale.
Message d'erreur : Failed to connect to remote host: Connection refused. L'intégration entre Cloud SQL et Vertex AI n'est pas activée. Pour activer cette intégration, utilisez la commande gcloud sql instances patch :

gcloud sql instances patch INSTANCE_NAME
--enable-google-ml-integration

Remplacez INSTANCE_NAME par le nom de l'instance Cloud SQL principale.
Message d'erreur : Vertex AI API has not been used in project PROJECT_ID before or it is disabled. Enable it by visiting /apis/api/aiplatform.googleapis.com/overview?project=PROJECT_ID then retry. L'API Vertex AI n'est pas activée. Pour en savoir plus sur l'activation de cette API, consultez la section Activer l'intégration de base de données avec Vertex AI.
Message d'erreur : Permission 'aiplatform.endpoints.predict' denied on resource. Les autorisations Vertex AI ne sont pas ajoutées au compte de service Cloud SQL pour le projet où se trouve l'instance Cloud SQL. Pour en savoir plus sur l'ajout de ces autorisations au compte de service, consultez la section Activer l'intégration de base de données avec Vertex AI.
Message d'erreur : Publisher Model `projects/PROJECT_ID/locations/REGION_NAME/publishers/google/models/MODEL_NAME` not found. Le modèle de machine learning ou le LLM n'existe pas dans Vertex AI.
Message d'erreur : Resource exhausted: grpc: received message larger than max. La taille de la requête que Cloud SQL transmet à Vertex AI dépasse la limite gRPC de 4 Mo par requête.
Message d'erreur : Cloud SQL attempts to send a request to Vertex AI. However, the instance is in the %s region, but the Vertex AI endpoint is in the %s region. Make sure the instance and endpoint are in the same region. Cloud SQL tente d'envoyer une requête à Vertex AI. Cependant, l'instance se trouve dans une région, mais le point de terminaison Vertex AI se trouve dans une région différente. Pour résoudre ce problème, l'instance et le point de terminaison doivent se trouver dans la même région.
Message d'erreur : The Vertex AI endpoint isn't formatted properly. Le format du point de terminaison Vertex AI n'est pas correct. Pour en savoir plus, consultez la section Utiliser des points de terminaison privés pour la prédiction en ligne.
Message d'erreur : Quota exceeded for aiplatform.googleapis.com/online_prediction_requests_per_base_model with base model: textembedding-gecko. Le nombre de requêtes que Cloud SQL transmet à Vertex AI dépasse la limite de 1 500 requêtes par minute par région par modèle par projet.

Journalisation

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

Vous pouvez définir l'option log_statement sur "aucun" et désactiver l'option logging_collector. Si la journalisation continue, d'autres options liées aux journaux peuvent être réglées. Vous pouvez modifier l'instance afin de changer ces options.
Les journaux d'audit sont introuvables. Les journaux d'accès aux données ne sont écrits que si l'opération est un appel d'API authentifié qui crée, modifie ou lit des données créées par l'utilisateur, ou si l'opération accède à des fichiers de configuration ou à des métadonnées de ressources.
Les informations sur les opérations sont introuvables dans les journaux. Vous souhaitez obtenir davantage d'informations sur une opération.

Par exemple, un utilisateur a été supprimé, mais vous ne pouvez pas savoir qui est à l'origine de cette opération. Les journaux indiquent que l'opération a commencé, mais ne fournissent pas plus d'informations. Pour obtenir des informations détaillées et des informations permettant d'identifier personnellement l'utilisateur telles que celles-ci, vous devez activer la journalisation d'audit.
Les fichiers journaux sont difficiles à lire. Vous préférez afficher les journaux au format JSON ou texte. Pour télécharger les journaux, vous pouvez utiliser la commande gcloud logging read avec les commandes Linux de post-traitement.

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

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

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

gcloud logging read \
"resource.type=cloudsql_database \
AND logName=projects/PROJECT_ID \
/logs/cloudsql.googleapis.com%2FLOG_NAME" \
--format json \
--project=PROJECT_ID \
--freshness="1d"| jq -rnc --stream 'fromstream(1|truncate_stream(inputs)) \
| .textPayload' \
--order=asc
> downloaded-log.txt
Les journaux de requêtes sont introuvables dans les journaux PostgreSQL. Vous devez activer les options pgaudit.
  1. Depuis un terminal, connectez-vous à la base de données : 
    gcloud sql connect INSTANCE_NAME
  2. 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

Gérer les instances

Problème Dépannage
Vous souhaitez savoir quelles requêtes sont en cours d'exécution. 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;

Vous souhaitez savoir quelles unités sont utilisées pour un champ spécifique. Connectez-vous à la base de données et exécutez la requête suivante (en utilisant votre propre valeur de FIELD_NAME) :

SELECT name, setting, unit FROM pg_settings WHERE name = 'FIELD_NAME'.
Vous souhaitez connaître la valeur actuelle d'un paramètre de base de données. Connectez-vous à la base de données et exécutez la requête suivante (en utilisant votre propre valeur de SETTING_NAME) :

SHOW SETTING_NAME;

Exécutez SHOW ALL; pour afficher tous les paramètres.
Vous souhaitez arrêter un processus en arrière-plan bloqué. L'utilisateur doit détenir le rôle pg_signal_backend.

Exécutez les commandes suivantes :

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

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.

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. L'augmentation automatique de l'espace de stockage est activée.

Le redémarrage supprime les fichiers temporaires sans réduire l'espace de stockage. Seul le service client est en mesure de réinitialiser la taille de l'instance.
Les données sont automatiquement supprimées. Il est probable qu'un script s'exécute quelque part dans votre environnement.

Examinez les journaux au moment de la suppression et vérifiez si un script malveillant est en cours d'exécution à partir d'un tableau de bord ou d'un autre processus automatisé.
Impossible de supprimer l'instance. Le message d'erreur ERROR: (gcloud.sql.instances.delete) HTTP Error 409: The instance or operation is not in an appropriate state to handle the request s'affiche, ou l'instance affiche INSTANCE_RISKY_FLAG_CONFIG pour l'état d'une option.

Voici quelques explications possibles :

  • Une autre opération est en cours. Les opérations Cloud SQL ne s'exécutent pas simultanément. Attendez que l'autre opération se termine.
  • L'avertissement INSTANCE_RISKY_FLAG_CONFIG est déclenché chaque fois qu'au moins une option beta est utilisée. Supprimez les paramètres risqués de l'option et redémarrez l'instance.
L'instance se bloque en raison du volume important des données temporaires. Le système peut créer plusieurs tables temporaires à la fois, en fonction des requêtes et de la charge.

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

L'une des mesures d'atténuation consiste à créer la table temporaire avec ROW_FORMAT=COMPRESSED, afin de stocker ce fichier dans des espaces de tables de type "un fichier par table" dans le répertoire de fichiers temporaires. Toutefois, cette méthode génère des coûts de performances liés à la création et à la suppression d'un espace de table de type "un fichier par table" pour chaque table temporaire.
Erreur fatale lors de la mise à niveau. Les journaux peuvent fournir davantage d'informations, mais dans tous les cas, vous devrez peut-être contacter le service client pour forcer la recréation de l'instance.
L'instance se bloque au redémarrage après avoir épuisé l'espace disque. La fonctionnalité d'augmentation automatique de l'espace de stockage n'est pas activée.

Si l'espace de stockage de votre instance est insuffisant et que la fonctionnalité d'augmentation automatique de l'espace de stockage n'est pas activée, l'instance se déconnecte. Pour éviter ce problème, vous pouvez modifier l'instance afin d'activer l'augmentation automatique de l'espace de stockage.
Blocage de l'instance principale sur site Google Cloud ne peut pas vous aider avec des instances qui ne sont pas dans Cloud SQL.
Arrêt lent au redémarrage. Lorsqu'une instance s'arrête, toutes les connexions en attente qui ne se terminent pas au bout de 60 secondes entraînent un arrêt incorrect.

En limitant les connexions à moins de 60 secondes, y compris les connexions à partir de l'invite de commande de base de données, vous pouvez éviter la plupart des arrêts non propres. Si vous laissez ces connexions ouvertes pendant des heures ou plusieurs jours, cela peut entraîner des arrêts incorrects.
Impossible de supprimer un utilisateur. L'utilisateur dispose d'objets dans la base de données qui en dépendent. Vous devez supprimer ces objets ou les réattribuer à un autre utilisateur.

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

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

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

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

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

Pour réduire la latence, nous vous recommandons de placer les ressources sources et de destination dans la même région.
Mémoire insuffisante signalée, mais non reportée dans les graphiques de surveillance. Une instance peut échouer et signaler Out of memory, mais les graphiques Cloud Monitoring ou Google Cloud Console semblent indiquer qu'il reste encore de la mémoire.

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

Assurez-vous que l'instance dispose d'une marge suffisante pour prendre en compte votre charge de travail et une utilisation supplémentaire de la mémoire.
Récupérer une instance supprimée. Toutes les données d'une instance, y compris les sauvegardes, sont définitivement perdues lors de sa suppression.

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

Le rôle d'administrateur Cloud SQL inclut l'autorisation de supprimer l'instance. Pour éviter toute suppression accidentelle, accordez ce rôle uniquement si nécessaire.
Vous souhaitez renommer une instance Cloud SQL existante. Il n'est pas possible de renommer une instance existante.

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

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

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

Private Service Connect
Problème Dépannage
Le rattachement de service de l'instance n'accepte pas le point de terminaison Private Service Connect.
  1. Vérifiez l'état du point de terminaison.

    gcloud

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

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

    Effectuez les remplacements suivants :

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

    REST

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

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

    Méthode HTTP et URL : 

    GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/forwardingRules/ENDPOINT_NAME

    Pour envoyer votre requête, développez l'une des options suivantes :

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

    {
  "kind": "compute#forwardingRule",
  "id": "ENDPOINT_ID",
  "creationTimestamp": "2024-05-09T12:03:21.383-07:00",
  "name": "ENDPOINT_NAME",
  "region": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME",
  "IPAddress": "IP_ADDRESS",
  "target": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/serviceAttachments/SERVICE_ATTACHMENT_NAME",
  "selfLink": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/forwardingRules/ENDPOINT_NAME",
  "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/default",
  "serviceDirectoryRegistrations": [
    {
      "namespace": "goog-psc-default"
    }
  ],
  "networkTier": "PREMIUM",
  "labelFingerprint": "LABEL_FINGERPRINT_ID",
  "fingerprint": "FINGERPRINT_ID",
  "pscConnectionId": "CONNECTION_ID",
  "pscConnectionStatus": "ACCEPTED",
  "allowPscGlobalAccess": true
}
  2. Vérifiez que l'état du point de terminaison est ACCEPTED. Si l'état est PENDING, l'instance n'autorise pas le projet Google Cloud contenant le point de terminaison. Assurez-vous que le projet réseau dans lequel le point de terminaison est créé est autorisé. Pour en savoir plus, consultez la page Modifier une instance avec Private Service Connect activé.

Réplication

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

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

Si l'option max_connections est définie correctement, inspectez les journaux dans Cloud Logging pour rechercher l'erreur réelle.
Impossible de créer l'instance dupliquée avec accès en lecture : erreur inconnue. Les fichiers journaux indiquent probablement une erreur plus spécifique. Inspectez les journaux dans Cloud Logging pour rechercher l'erreur en question.

Si l'erreur est : set Service Networking service account as servicenetworking.serviceAgent role on consumer project, désactivez et réactivez Service Networking API. Cette action crée le compte de service nécessaire pour poursuivre le processus.
Le disque est saturé. Le disque de l'instance principale peut arriver à saturation lors de la création de l'instance dupliquée. Modifiez l'instance principale en augmentant la taille du disque.
L'espace disque augmente considérablement. Un emplacement qui n'est pas activement utilisé pour suivre les données oblige PostgreSQL à conserver les segments WAL indéfiniment, ce qui entraîne une augmentation permanente de l'espace disque. Si vous utilisez les fonctionnalités de réplication logique et de décodage logique de Cloud SQL, les emplacements de réplication sont créés et supprimés automatiquement. Vous pouvez détecter les emplacements de réplication inutilisés en interrogeant la vue système pg_replication_slots et en filtrant suivant la colonne active. La suppression des emplacements inutilisés, en vue d'éliminer des segments WAL, s'effectue à l'aide de la commande pg_drop_replication_slot.
L'instance dupliquée utilise trop de mémoire. L'instance dupliquée met en cache les opérations de lecture souvent demandées dans une mémoire temporaire, ce qui peut l'amener à utiliser plus de mémoire que l'instance principale.

Redémarrez l'instance dupliquée afin de récupérer l'espace de mémoire temporaire.
La duplication s'est arrêtée. La limite de stockage maximale a été atteinte et l'augmentation automatique de l'espace de stockage n'est pas activée.

Modifiez l'instance pour activer automatic storage increase.
Le délai de duplication est systématiquement long. La charge d'écriture est trop élevée pour que l'instance dupliquée puisse la traiter. Le délai de duplication s'allonge lorsque le thread SQL d'une instance dupliquée ne parvient pas à suivre le thread d'E/S. Certains types de requêtes ou de charges de travail peuvent allonger le délai de duplication de manière temporaire ou permanente pour un schéma donné. Voici quelques causes typiques affectant le délai de duplication :
  • Requêtes lentes sur l'instance dupliquée. Recherchez-les et corrigez-les.
  • Toutes les tables doivent avoir une clé unique/primaire. Chaque mise à jour d'une table sans clé unique/primaire entraîne une analyse complète des tables de l'instance répliquée.
  • Les requêtes telles que DELETE ... WHERE field < 50000000 allongent le délai de duplication, dans le cas des duplications basées sur les lignes, car un grand nombre de mises à jour s'accumulent sur l'instance dupliquée.

Voici quelques solutions possibles :

  • Modifiez l'instance pour augmenter la taille de l'instance dupliquée.
  • Réduisez la charge sur la base de données.
  • Envoyez du trafic en lecture à l'instance dupliquée avec accès en lecture.
  • Indexez les tables.
  • Identifiez et corrigez les requêtes d'écriture lentes.
  • Recréez l'instance dupliquée.
Erreurs lors de la reconstruction d'index dans PostgreSQL 9.6. Une erreur de PostgreSQL vous indique que vous devez reconstruire un index particulier. Cette opération n'est possible que sur l'instance principale. Si vous créez une nouvelle instance dupliquée, vous obtiendrez rapidement la même erreur. Les index de hachage ne sont pas propagés aux instances dupliquées dans les versions de PostgreSQL antérieures à la version 10.

Si vous devez absolument utiliser des index de hachage, effectuez une mise à niveau vers PostgreSQL 10 ou une version ultérieure. Sinon, si vous souhaitez également utiliser des instances dupliquées, n'utilisez pas d'index de hachage dans PostgreSQL 9.6.
La requête sur l'instance principale est toujours en cours d'exécution. Après avoir créé une instance répliquée, la requête SELECT * from pg_stat_activity where state = 'active' and pid = XXXX and username = 'cloudsqlreplica' doit s'exécuter en continu sur votre instance principale.
La création d'une instance dupliquée échoue avec un délai d'expiration. Les transactions non validées de longue durée sur l'instance principale peuvent entraîner l'échec de la création d'une instance dupliquée avec accès en lecture.

Recréez l'instance dupliquée après avoir arrêté toutes les requêtes en cours d'exécution.
Si l'instance principale et l'instance dupliquée disposent de tailles de processeurs virtuels différentes, des problèmes de performances des requêtes peuvent survenir, car l'optimiseur de requêtes prend en compte les tailles de processeurs virtuels.

Pour résoudre ce problème, procédez comme suit :

  1. Activez l'option log_duration et définissez le paramètre log_statement sur ddl. Vous obtenez ainsi à la fois les requêtes et le temps d'exécution sur la base de données. Toutefois, en fonction de votre charge de travail, cela peut entraîner des problèmes de performances.
  2. Sur l'instance principale et sur l'instance dupliquée avec accès en lecture, exécutez explain analyze pour les requêtes.
  3. Comparez le plan de requête et recherchez les différences.

S'il s'agit d'une requête spécifique, modifiez-la. Par exemple, vous pouvez modifier l'ordre des jointures pour voir si vous obtenez de meilleures performances.