Problèmes connus

Cette page répertorie les problèmes connus de Cloud SQL pour PostgreSQL et vous explique comment les éviter ou les résoudre.

Si vous rencontrez des problèmes avec votre instance, veillez également à consulter les informations décrites dans la section Diagnostiquer les problèmes liés aux instances Cloud SQL.

Problèmes de connexion à l'instance

  • Certificats SSL/TLS expirés

    Si votre instance est configurée pour utiliser SSL, accédez à la page "Instances Cloud SQL" dans Google Cloud Console et ouvrez l'instance. Accédez à la page Connexions, sélectionnez l'onglet Sécurité et vérifiez que le certificat de serveur est valide. S'il a expiré, vous devez ajouter un nouveau certificat et effectuer une rotation pour le mettre en application.

  • Version du proxy d'authentification Cloud SQL

    Si vous vous connectez à l'aide du proxy d'authentification Cloud SQL, assurez-vous d'utiliser la version la plus récente. Pour en savoir plus, consultez la section Maintenir le proxy d'authentification Cloud SQL à jour.

  • Connexion non autorisée

    Si vous essayez de vous connecter à une instance qui n'existe pas dans le projet concerné, un message d'erreur vous indique simplement que vous n'êtes pas autorisé à y accéder.

  • Impossible de créer une instance Cloud SQL

    Si le message d'erreur Failed to create subnetwork. Router status is temporarily unavailable. Please try again later. Help Token: [token-ID] s'affiche, essayez de créer à nouveau l'instance Cloud SQL.

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

    Si vous essayez de vous connecter à l'aide de cette commande avec un autre utilisateur, le message d'erreur indique FATAL: database 'user' does not exist. La solution consiste à vous connecter à l'aide de l'utilisateur par défaut ("postgres"), puis à utiliser la commande psql "\c" pour vous reconnecter en tant qu'un autre utilisateur.

  • Les connexions PostgreSQL se bloquent lorsque l'authentification IAM via proxy pour les bases de données est activée.

    Lorsque le proxy d'authentification Cloud SQL est lancé avec des sockets TCP et avec l'option -enable_iam_login, un client PostgreSQL se bloque pendant la connexion TCP. Une solution consiste à utiliser sslmode=disable dans la chaîne de connexion PostgreSQL. Exemple :

    psql "host=127.0.0.1 dbname=postgres user=me@google.com sslmode=disable"

    Une autre solution consiste à lancer le proxy d'authentification Cloud SQL avec des sockets Unix. Cela désactive le chiffrement SSL de PostgreSQL et permet au proxy d'authentification Cloud SQL d'effectuer le chiffrement SSL à la place.

Problèmes d'administration

  • Une seule opération d'importation ou d'exportation Cloud SQL de longue durée peut être exécutée à la fois sur une instance. Lorsque vous démarrez une opération, assurez-vous que vous n'avez pas besoin d'effectuer d'autres opérations sur l'instance. En outre, lorsque vous démarrez l'opération, vous pouvez l'annuler.

    PostgreSQL importe les données en une seule transaction. Par conséquent, si vous annulez l'opération d'importation, Cloud SQL ne conserve pas les données de l'importation.

    Problèmes d'importation et d'exportation des données

    • Si votre instance Cloud SQL utilise PostgreSQL 17, mais que vos bases de données utilisent PostgreSQL 16 ou une version antérieure, vous ne pouvez pas utiliser Cloud SQL pour importer ces bases de données dans votre instance. Pour ce faire, utilisez Database Migration Service.

    • Si vous utilisez Database Migration Service pour importer une base de données PostgreSQL 17 dans Cloud SQL, elle est importée en tant que base de données PostgreSQL 16.

    • 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 et un message d'erreur permission denied for schema public peut s'afficher. 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.

    • L'exportation de nombreux objets volumineux entraîne l'inactivité de l'instance

      Si votre base de données contient de nombreux objets volumineux (blobs), la consommation excessive de mémoire due à son exportation peut entraîner l'inactivité de l'instance. Cette réaction peut se produire même si les blobs sont vides.

    • Cloud SQL ne prend pas en charge les espaces de table personnalisés, mais il permet la migration des données depuis des espaces de table personnalisés vers l'espace de table par défaut, pg_default, dans l'instance de destination. Par exemple, si vous êtes propriétaire d'un espace de table nommé dbspace situé à l'emplacement /home/data, après la migration, toutes les données dans dbspace sont migrées vers pg_default. Cependant, Cloud SQL ne créera pas d'espace de table nommé "dbspace" sur son disque.

    • Si vous essayez d'importer et d'exporter des données à partir d'une base de données volumineuse (par exemple, une base de données contenant au moins 500 Go de données), les opérations d'importation et d'exportation peuvent prendre beaucoup de temps. En outre, d'autres opérations (par exemple, l'opération de sauvegarde) ne sont pas disponibles pendant l'importation ou l'exportation. Une option potentielle pour améliorer les performances du processus d'importation et d'exportation consiste à restaurer une sauvegarde précédente à l'aide de gcloud ou de l'API.

    • Cloud Storage accepte une taille d'objet unique maximale de 5 téraoctets. Si vous disposez de bases de données plus volumineuses, l'opération d'exportation vers Cloud Storage échoue. Dans ce cas, vous devez diviser vos fichiers d'exportation en segments plus petits.

    Journaux des transactions et augmentation de la taille du disque

    Les journaux sont supprimés définitivement une fois par jour, et non de manière continue. Lorsque le nombre de jours de conservation des journaux est configuré pour être identique au nombre de sauvegardes, une journée de journalisation peut être perdue, selon le moment où la sauvegarde se produit. Par exemple, si vous définissez la durée de conservation des journaux sur sept jours et la durée de conservation de sauvegarde sur sept sauvegardes, cela signifie que six à sept jours de journaux seront conservés.

    Nous vous recommandons de définir le nombre de sauvegardes sur une valeur correspondant au moins à la durée de conservation des journaux plus un, afin de garantir un minimum de jours spécifiés de conservation des journaux.

    Les instances portant les noms de région suivants s'affichent de manière incorrecte dans certains contextes, comme suit :

    • us-central1 s'affiche en tant que us-central
    • europe-west1 s'affiche en tant que europe
    • asia-east1 s'affiche en tant que asia

    Ce problème se produit dans les contextes suivants :

    • Alertes dans Cloud Monitoring
    • Explorateur de métriques
    • Cloud Logging

    Vous pouvez limiter les problèmes liés aux alertes dans Cloud Monitoring et à l'explorateur de métriques à l'aide des libellés de métadonnées de ressource. Utilisez le libellé de métadonnées système region au lieu du libellé de ressource surveillée cloudsql_database region.