Problemi noti

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

Se riscontri problemi con l'istanza, assicurati di esaminare anche le informazioni in Diagnosi dei problemi.

Problemi di connessione all'istanza

  • Certificati SSL/TLS scaduti

    Se l'istanza è configurata per utilizzare SSL, vai alla pagina Istanze Cloud SQL nella Google Cloud console 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 e ruotarlo.

  • 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 saperne di più, consulta Mantenere aggiornato il proxy di autenticazione Cloud SQL.

  • Non autorizzato a connettersi

    Se provi a connetterti a un'istanza che non esiste nel progetto, il messaggio di errore indica solo che non hai l'autorizzazione per accedere all'istanza.

  • Impossibile creare un'istanza Cloud SQL

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

  • Il seguente comando 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'), quindi utilizzare il "\c" comando psql per riconnettersi come utente diverso.

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

    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 consiste nell'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 il proxy di autenticazione Cloud SQL esegue la crittografia SSL.

Problemi amministrativi

  • Su un'istanza è possibile eseguire 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 dell'importazione.

Problemi di importazione ed esportazione dei dati

  • Se l'istanza Cloud SQL utilizza PostgreSQL 17, ma i database utilizzano PostgreSQL 16 e versioni precedenti, non puoi utilizzare Cloud SQL per importare questi database nell'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 le versioni di PostgreSQL 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 fa sì che l'istanza non risponda

    Se il database contiene molti oggetti di grandi dimensioni (blob), l'esportazione del database può consumare così tanta memoria che l'istanza non risponde. Questo 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 un tablespace 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à un tablespace 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) durante 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.

  • Cloud Storage supporta una dimensione massima di un singolo oggetto fino a cinque tebibyte (5 TiB). Poiché Cloud SQL comprime i dati prima di caricarli in Cloud Storage, un'operazione di esportazione non riesce solo se la dimensione compressa di un file di esportazione supera i 5 TiB.

    Il rapporto di compressione dipende dai tipi di dati nel database; ad esempio, il testo si comprime meglio dei dati binari come i BLOB. Pertanto, una dimensione del database o della tabella superiore a 5 TiB potrebbe non causare un errore di esportazione se i dati sono altamente comprimibili, mentre i dati non compressi che si avvicinano a 5 TiB potrebbero non riuscire.

    Se esegui un'operazione di esportazione standard, Cloud SQL in genere crea un singolo file di esportazione. Se utilizzi l'esportazione parallela, Cloud SQL crea più file di esportazione, in genere uno per ogni tabella. Con questo tipo di esportazione, l'operazione di esportazione non riesce se una tabella è abbastanza grande da superare i 5 TiB del file di esportazione compresso.

    Se l'esportazione non riesce a causa del limite di 5 TiB, devi suddividerla in segmenti più piccoli. Se utilizzi un'esportazione standard e raggiungi questo limite, valuta la possibilità di passare all'esportazione parallela.

    Se utilizzi già l'esportazione parallela e raggiungi il limite di 5 TiB, una delle tue tabelle è troppo grande per essere esportata, anche da sola. In questo caso, in alternativa, puoi connetterti da un'istanza Compute Engine e utilizzare l'utilità pg_dump per esportare la tabella.

Log delle transazioni e crescita del disco

I log vengono eliminati una volta al giorno, non in modo continuo. Quando il numero di giorni di conservazione dei log è configurato in modo che sia uguale al numero di backup, è possibile che un giorno di logging vada 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 tra sei e sette giorni di log.

Ti consigliamo di impostare il numero di backup su almeno uno in più 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 regione vengono visualizzate in modo errato in determinati contesti, come indicato di seguito:

  • 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
  • Metrics Explorer
  • Cloud Logging

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

Quando elimini un database creato nella Google Cloud console utilizzando il psql client, 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 ha gli attributi superuser di Cloud SQL. I database creati utilizzando la Google Cloud console sono di proprietà di cloudsqlsuperuser e i database creati utilizzando un psql client 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 saperne di più, consulta Restrizioni e privilegi di superuser.

A causa di questa limitazione, i database creati utilizzando la Google Cloud console possono essere eliminati solo utilizzando la Google Cloud console, 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 di cui vuoi trovare le informazioni sul proprietario.

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