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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Connectez-vous avec l'utilisateur par défaut, puis changez d'utilisateur.

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

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

Modifiez le fichier de vidage pour supprimer les références.

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

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

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

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

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

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

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

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

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

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

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

   En savoir plus.

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

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

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

Un redémarrage :

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

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

Solutions possibles

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

SET FOREIGN_KEY_CHECKS=0;
  

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

SET FOREIGN_KEY_CHECKS=1;
  

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

EXEC sp_serveroption
    @server='LINKED_SERVER_NAME',
    @optname='data access',
    @optvalue='TRUE'

Remplacez LINKED_SERVER_NAME par le nom du serveur associé.

EXEC master.dbo.sp_addlinkedserver
   @server = N'LINKED_SERVER_NAME',
   @srvproduct= N'',
   @provider= N'SQLNCLI',
   @datasrc= N'TARGET_SERVER_ID',
   @provstr= N'Encrypt=yes;TrustServerCertificate=yes;User ID=USER_ID'

Remplacez les éléments suivants :

• LINKED_SERVER_NAME par le nom du serveur associé.
• TARGET_SERVER_ID par le nom du serveur cible, ou par l'adresse IP et le numéro de port du serveur cible.
• USER_ID par l'utilisateur qui se connecte.

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

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

SHOW VARIABLES LIKE 'innodb_log_file%';

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

SHOW BINARY LOGS;
    

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

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

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

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

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
        

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

Solutions possibles

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

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

SHOW PROCESSLIST.

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

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

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

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

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

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

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;

SELECT name, setting, unit FROM pg_settings WHERE name = 'FIELD_NAME'.

SHOW SETTING_NAME;

Exécutez SHOW ALL; pour afficher tous les paramètres.

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

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.

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

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

Voici quelques explications possibles :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   gcloud

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

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

   Effectuez les remplacements suivants :

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

   REST

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

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

   Méthode HTTP et URL :

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

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

   curl (Linux, macOS ou Cloud Shell)

   Exécutez la commande suivante :

   curl -X GET \
        -H "Authorization: Bearer $(gcloud auth print-access-token)" \
        "https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/forwardingRules/ENDPOINT_NAME"

   PowerShell (Windows)

   Exécutez la commande suivante :

   $cred = gcloud auth print-access-token
   $headers = @{ "Authorization" = "Bearer $cred" }
   
   Invoke-WebRequest `
       -Method GET `
       -Headers $headers `
       -Uri "https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/forwardingRules/ENDPOINT_NAME" | Select-Object -Expand Content

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

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

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

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

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

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

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

Modifiez l'instance pour activer automatic storage increase.

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

Voici quelques solutions possibles :

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

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