Problemi noti

Questa pagina elenca i problemi noti di Cloud SQL per PostgreSQL, insieme ai modi in cui puoi evitarli o risolverli.

Se riscontri problemi con la tua istanza, assicurati di esaminare anche le informazioni contenute in Diagnosi dei problemi.

Problemi di connessione dell'istanza

  • Certificati SSL/TLS scaduti

    Se la tua istanza è configurata per utilizzare SSL, vai alla pagina Istanze Cloud SQL nella console Google Cloud e apri l'istanza. Apri la pagina Connessioni, seleziona la scheda Sicurezza e assicurati che il certificato del server sia valido. Se è scaduto, devi aggiungere un nuovo certificato ed eseguirne la rotazione.

  • Versione del proxy di autenticazione Cloud SQL

    Se ti connetti utilizzando il proxy di autenticazione Cloud SQL, assicurati di utilizzare la versione più recente. Per maggiori informazioni, vedi Mantenere aggiornato il proxy di autenticazione Cloud SQL.

  • Non autorizzato a connettersi

    Se provi a connetterti a un'istanza che non esiste in quel progetto, il messaggio di errore indica solo che non sei autorizzato ad accedere a quell'istanza.

  • Impossibile creare un'istanza Cloud SQL

    Se visualizzi il messaggio di errore Failed to create subnetwork. Router status is temporarily unavailable. Please try again later. Help Token: [token-ID], prova a creare di nuovo l'istanza Cloud SQL.

  • Quanto segue funziona solo con l'utente predefinito ("postgres"): gcloud sql connect --user

    Se provi a connetterti utilizzando questo comando con un altro utente, il messaggio di errore indica FATAL: database 'user' does not exist. La soluzione alternativa consiste nel connettersi utilizzando l'utente predefinito ("postgres") e poi utilizzare il comando "\c" psql per riconnettersi come utente diverso.

  • Le connessioni PostgreSQL si bloccano quando è abilitata l'autenticazione del proxy di database IAM.

    Quando il proxy di autenticazione Cloud SQL viene avviato utilizzando i socket TCP e con il flag -enable_iam_login, un client PostgreSQL si blocca durante la connessione TCP. Una soluzione alternativa è utilizzare sslmode=disable nella stringa di connessione PostgreSQL. Ad esempio:

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

    Un'altra soluzione alternativa consiste nell' avviare il proxy di autenticazione Cloud SQL utilizzando i socket Unix. In questo modo la crittografia SSL di PostgreSQL viene disattivata e viene utilizzata la crittografia SSL del proxy di autenticazione Cloud SQL.

Problemi amministrativi

  • Su un'istanza può essere eseguita una sola operazione di importazione o esportazione Cloud SQL a lunga esecuzione alla volta. Quando avvii un'operazione, assicurati di non dover eseguire altre operazioni sull'istanza. Inoltre, quando avvii l'operazione, puoi annullarla.

    PostgreSQL importa i dati in una singola transazione. Pertanto, se annulli l'operazione di importazione, Cloud SQL non conserva i dati importati.

Problemi con l'importazione e l'esportazione dei dati

  • Se la tua istanza Cloud SQL utilizza PostgreSQL 17, ma i tuoi database utilizzano PostgreSQL 16 e versioni precedenti, non puoi utilizzare Cloud SQL per importare questi database nella tua istanza. Per farlo, utilizza Database Migration Service.

  • Se utilizzi Database Migration Service per importare un database PostgreSQL 17 in Cloud SQL, viene importato come database PostgreSQL 16.

  • Per PostgreSQL versione 15 e successive, se il database di destinazione viene creato da template0, l'importazione dei dati potrebbe non riuscire e potresti visualizzare un messaggio di errore permission denied for schema public. Per risolvere il problema, fornisci i privilegi dello schema pubblico all'utente cloudsqlsuperuser eseguendo il comando SQL GRANT ALL ON SCHEMA public TO cloudsqlsuperuser.

  • L'esportazione di molti oggetti di grandi dimensioni causa la mancata risposta dell'istanza

    Se il database contiene molti oggetti di grandi dimensioni (blob), l'esportazione del database può consumare così tanta memoria che l'istanza non risponde più. Ciò può accadere anche se i blob sono vuoti.

  • Cloud SQL non supporta i tablespace personalizzati, ma supporta la migrazione dei dati dai tablespace personalizzati al tablespace predefinito, pg_default, nell'istanza di destinazione. Ad esempio, se possiedi uno spazio delle tabelle denominato dbspace che si trova in /home/data, dopo la migrazione tutti i dati all'interno di dbspace vengono migrati in pg_default. Tuttavia, Cloud SQL non creerà uno spazio delle tabelle denominato "dbspace" sul disco.

  • Se stai tentando di importare ed esportare dati da un database di grandi dimensioni (ad esempio, un database con 500 GB di dati o più), le operazioni di importazione ed esportazione potrebbero richiedere molto tempo per essere completate. Inoltre, non puoi eseguire altre operazioni (ad esempio, l'operazione di backup) mentre è in corso l'importazione o l'esportazione. Una potenziale opzione per migliorare le prestazioni del processo di importazione ed esportazione è ripristinare un backup precedente utilizzando gcloud o l'API.

Log delle transazioni e crescita del disco

I log vengono eliminati una volta al giorno, non in modo continuo. Se il numero di giorni di conservazione dei log è configurato in modo che sia uguale al numero di backup, un giorno di registrazione potrebbe andare perso, a seconda di quando viene eseguito il backup. Ad esempio, se imposti la conservazione dei log su sette giorni e la conservazione dei backup su sette backup, verranno conservati i log per un periodo compreso tra sei e sette giorni.

Ti consigliamo di impostare il numero di backup su un valore superiore di almeno uno rispetto ai giorni di conservazione dei log per garantire un minimo di giorni di conservazione dei log specificati.

Problemi relativi a Cloud Monitoring o Cloud Logging

Le istanze con i seguenti nomi di regioni vengono visualizzate in modo errato in determinati contesti, come segue:

  • us-central1 viene visualizzato come us-central
  • europe-west1 viene visualizzato come europe
  • asia-east1 viene visualizzato come asia

Questo problema si verifica nei seguenti contesti:

  • Avvisi in Cloud Monitoring
  • Esplora metriche
  • Cloud Logging

Puoi mitigare il problema per gli avvisi in Cloud Monitoring e per Metrics Explorer utilizzando le etichette dei metadati delle risorse. Utilizza l'etichetta dei metadati di sistema region anziché l'etichetta della risorsa monitorata cloudsql_database region.

Quando elimini un database creato nella console Google Cloud utilizzando il clientpsql, potresti riscontrare il seguente errore:

ERROR: must be owner of database [DATABASE_NAME]

Si tratta di un errore di autorizzazione perché il proprietario di un database creato utilizzando un client psql non dispone degli attributi superuser di Cloud SQL. I database creati utilizzando la console Google Cloud sono di proprietà di cloudsqlsuperuser, mentre i database creati utilizzando un client psql sono di proprietà degli utenti connessi a quel database. Poiché Cloud SQL è un servizio gestito, i clienti non possono creare o avere accesso a utenti con attributi superuser. Per ulteriori informazioni, vedi Restrizioni e privilegi di superutente.

A causa di questa limitazione, i database creati utilizzando la console Google Cloud possono essere eliminati solo utilizzando la console Google Cloud , mentre i database creati utilizzando un client psql possono essere eliminati solo connettendosi come proprietario del database.

Per trovare il proprietario di un database, utilizza il seguente comando:

SELECT d.datname as Name,
pg_catalog.pg_get_userbyid(d.datdba) as Owner
FROM pg_catalog.pg_database d
WHERE d.datname = 'DATABASE_NAME';

Sostituisci quanto segue:

  • DATABASE_NAME: il nome del database per cui vuoi trovare le informazioni sul proprietario.

Se il proprietario del database è cloudsqlsuperuser, utilizza la consoleGoogle Cloud per eliminare il database. Se il proprietario del database è un utente del database client psql, connettiti come proprietario del database e esegui il comando DROP DATABASE.