Problemi noti

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

Se riscontri problemi con l'istanza, assicurati di consultare anche le informazioni contenute in Diagnostica dei problemi.

Problemi di connessione all'istanza

  • Certificati SSL/TLS scaduti

    Se l'istanza è configurata per l'utilizzo di 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 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 maggiori informazioni, consulta Mantenere aggiornato il proxy di autenticazione Cloud SQL.

  • Connessione non autorizzata

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

  • Impossibile creare un'istanza Cloud SQL

    Se viene visualizzato 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 qualsiasi altro utente, il messaggio di errore indica FATAL: database 'user' does not exist. La soluzione alternativa consiste nel connetterti utilizzando l'utente predefinito ("postgres"), quindi utilizzare il comando psql "\c" per riconnetterti come utente diverso.

Problemi amministrativi

  • Su un'istanza può essere eseguita una sola operazione di importazione o esportazione a lunga esecuzione di Cloud SQL 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. Di conseguenza, se annulli l'operazione di importazione, Cloud SQL non rende persistenti i dati dall'importazione.

    Problemi con l'importazione e l'esportazione dei dati

    • Per PostgreSQL 15 e versioni 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 di 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 talmente tanta memoria che l'istanza non risponde. Ciò può verificarsi anche se i blob sono vuoti.

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

    • Se stai tentando di importare ed esportare i dati da un database di grandi dimensioni (ad esempio un database con 500 GB di dati o più), il completamento delle operazioni di importazione ed esportazione potrebbe richiedere molto tempo. Inoltre, non puoi eseguire altre operazioni, ad esempio l'operazione di backup, mentre l'importazione o l'esportazione è in corso. 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 definitivamente una volta al giorno, non in modo continuo. Se il numero di giorni di conservazione dei log è configurato in modo da corrispondere al numero di backup, un giorno di logging potrebbe andare perso, a seconda di quando si verifica il backup. Ad esempio, impostare la conservazione dei log su sette giorni e la conservazione dei backup su sette giorni di backup, significa che i log verranno conservati da sei a sette giorni.

    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 specificati di conservazione dei log.

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

    • us-central1 è visualizzato come us-central
    • europe-west1 è visualizzato come europe
    • asia-east1 è 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 Metrics Explorer utilizzando Etichette metadati delle risorse. Utilizza l'etichetta dei metadati di sistema region anziché l'etichetta della risorsa monitorata cloudsql_database region.