Risolvere i problemi

Controlla se la tua domanda o il tuo problema è già stato risolto in uno dei pagine seguenti:

Gli argomenti trattati in questa pagina includono:

Backup e ripristino

Problema Risoluzione dei problemi
Non puoi vedere lo stato dell'operazione in corso. La console Google Cloud segnala l'esito positivo o negativo solo quando l'operazione al termine dell'operazione. Non è progettata per mostrare avvisi o altri aggiornamenti.

Esegui il comando gcloud sql operations list per elencare tutte le operazioni per l'istanza Cloud SQL specificata.

Vuoi scoprire chi ha emesso un'operazione di backup on demand. L'interfaccia utente non mostra l'utente che ha avviato un'operazione.

Cerca nei log. e filtrarli in base al testo per trovare l'utente. Potresti dover utilizzare i log di controllo informazioni private. I file di log pertinenti includono:

  • cloudsql.googleapis.com/postgres.log
  • Se Cloud Audit Logs è abilitato e disponi delle autorizzazioni necessarie per visualizzarle, Potrebbe essere disponibile anche cloudaudit.googleapis.com/activity.
Dopo aver eliminato un'istanza, non puoi eseguirne il backup.

Dopo l'eliminazione definitiva di un'istanza, non è possibile recuperare i dati. Tuttavia, Se l'istanza viene ripristinata, vengono ripristinati anche i backup. Per maggiori informazioni informazioni sul recupero di un'istanza eliminata, consulta Backup di recupero.

Se hai eseguito un'operazione di esportazione, crea una nuova istanza ed eseguire un'operazione di importazione per ricreare il database. Le esportazioni sono vengono scritte in Cloud Storage e le importazioni vengono lette da lì.

Un backup automatico è bloccato per molte ore e non può essere annullato. I backup possono richiedere molto tempo, a seconda delle dimensioni del database.

Se devi davvero annullare l'operazione, puoi chiedere assistenza clienti a force restart l'istanza.

Un'operazione di ripristino può non riuscire quando uno o più utenti a cui viene fatto riferimento nel Il file di dump SQL non esiste. Prima di ripristinare un dump SQL, tutti gli utenti del database che sono proprietari degli oggetti a cui sono state concesse le autorizzazioni per gli oggetti nel database di cui è stato eseguito il dump, database di destinazione. In caso contrario, l'operazione di ripristino non riesce a ricreare gli oggetti con la proprietà o le autorizzazioni originali.

Crea gli utenti del database prima di ripristinare il dump SQL.

Vuoi aumentare il numero di giorni per i quali puoi conservare i backup automatici da sette a 30 giorni o più. Puoi e configurare il numero di backup automatici da conservare, da 1 a 365. I backup automatici vengono eliminati regolarmente in base al valore di conservazione configurato. Purtroppo, ciò significa i backup attualmente visibili sono gli unici da cui puoi eseguire il ripristino.

Per conservare i backup a tempo indeterminato, puoi creare un backup on demand, in quanto non vengono eliminati come i backup automatici. I backup on demand rimangono indefinitamente. Vale a dire che rimangono valide finché non vengono eliminate o non viene eliminata l'istanza a cui appartengono. Poiché questo tipo di backup non viene eliminato automaticamente, può influire sulla fatturazione.

Un backup automatico non è riuscito e non hai ricevuto una notifica via email. Per fare in modo che Cloud SQL ti invii una notifica sullo stato del backup, configura un avviso basato su log.
Un'istanza si verifica ripetutamente con errori perché si sta ciclicamente tra gli stati di errore e di ripristino del backup. I tentativi di connettersi e utilizzare il database dopo il ripristino non vanno a buon fine.
  • Potrebbero esserci troppe connessioni aperte. Un numero eccessivo di connessioni può derivare da errori che si verificano nel mezzo di una connessione in cui non sono presenti impostazioni autovacuum per eliminare le connessioni non attive.
  • Il ciclo può verificarsi se un codice personalizzato utilizza una logica di ripetizione che non si interrompe dopo alcuni errori.
  • Potrebbe esserci troppo traffico. Utilizza il pooling delle connessioni e altre best practice per la connettività.

Tentativi da effettuare

  1. Verifica che il database sia configurato per autovacuum.
  2. Controlla se è stata configurata una logica per i nuovi tentativi di connessione nel codice personalizzato.
  3. Riduci il traffico finché il database non si ripristina, quindi riattivalo lentamente.
Mancano dati durante l'esecuzione di un'operazione di backup/ripristino. Le tabelle sono state create come non registrate. Ad esempio:

CREATE UNLOGGED TABLE ....

Queste tabelle non sono incluse in un ripristino da un backup:

  • I contenuti delle tabelle non registrate non sopravvivono al failover su un'istanza ad alta disponibilità.
  • Le tabelle non registrate non sopravvivono agli arresti anomali postgres.
  • Le tabelle non registrate non vengono replicate in repliche di lettura.
  • Le tabelle non registrate vengono cancellate automaticamente durante il ripristino del backup.

La soluzione è evitare di utilizzare tabelle non registrate se vuoi ripristinarle tramite un backup. Se esegui il ripristino da un database che ha già tabelle non registrate, puoi eseguire il dump del database in un file e ricaricare i dati dopo aver modificato il file dumpato in ALTER TABLE in SET LOGGED in queste tabelle.

Annulla importazione ed esportazione

Problema Risoluzione dei problemi
Messaggio di errore: You can't cancel operation [operation-ID] because this operation isn't in progress.

Stai tentando di annullare un'operazione di importazione o esportazione completata, non riuscito o annullato. Se l'operazione è in esecuzione, puoi annullarla.

Messaggio di errore: You can't cancel operation [operation-ID] because Cloud SQL doesn't support the cancellation of an [operation-type] operation.

Cloud SQL non supporta l'annullamento dell'operazione perché ha un tipo di operazione diverso da IMPORT o EXPORT.

Messaggio di errore: The [operation-type] operation isn't cancelled. Wait and retry in a few seconds.

Al momento Cloud SQL non può annullare l'operazione di importazione o esportazione. Riprova tra qualche secondo. Se il problema persiste, contatta Assistenza Google Cloud.

Clona

Problema Risoluzione dei problemi
La clonazione non riesce con l'errore constraints/sql.restrictAuthorizedNetworks. L'operazione di clonazione è bloccata dalla configurazione Authorized Networks. Authorized Networks sono configurati per gli indirizzi IP pubblici nella sezione Connettività della console Google Cloud e la clonazione non è consentita per motivi di sicurezza.

Se possibile, rimuovi tutte le voci Authorized Networks dall'istanza Cloud SQL. Altrimenti, crea una replica senza voci Authorized Networks.

Messaggio di errore: Failed to create subnetwork. Couldn't find free blocks in allocated IP ranges. Please allocate new ranges for this service provider. Help Token: [help-token-id].

Stai tentando di utilizzare la console Google Cloud per clonare un'istanza con un IP privato ma non hai specificato l'intervallo IP allocato desiderato da utilizzare e l'istanza di origine non viene creata con l'intervallo specificato. Come come risultato, l'istanza clonata viene creata in un intervallo casuale.

Utilizza gcloud per clonare l'istanza e fornire un valore per il parametro
--allocated-ip-range-name. Per ulteriori informazioni, consulta Clonare un'istanza con un IP privato.

Connetti

Problema Risoluzione dei problemi
Aborted connection. Il problema potrebbe essere:
  • Instabilità della rete.
  • Nessuna risposta ai comandi keep-alive TCP (client o server non reattivo, probabilmente sovraccarico)
  • Il lifetime della connessione al motore del database è stato superato e il server termina la connessione.

Le applicazioni devono tollerare gli errori di rete e seguire best practice come il pool di connessioni e nuovi tentativi. La maggior parte dei pool di connessione rileva questi errori, se possibile. In caso contrario, l'applicazione deve riprovare o interrompersi in modo corretto.

Per riprovare la connessione, consigliamo i seguenti metodi:

  1. Exponential il backoff. Aumenta in modo esponenziale l'intervallo di tempo tra ogni nuovo tentativo.
  2. Aggiungi anche un backoff casuale.

La combinazione di questi metodi consente di ridurre la limitazione.

Certificate verify failed.

I certificati client sono scaduti o il percorso dei certificati non è corretto.

Rigenera i certificati ricreandoli.

FATAL: database 'user' does not exist. gcloud sql connect --user funziona solo con l'impostazione predefinita postgres utente.

Accedi con l'utente predefinito, quindi cambia utente.

Vuoi scoprire chi è connesso. Accedi al database ed esegui questo comando:

SELECT datname,
usename,
application_name as appname,
client_addr,
state,
now() - backend_start as conn_age,
now() - state_change as last_activity_age
FROM pg_stat_activity
WHERE backend_type = 'client backend'
ORDER BY 6 DESC
LIMIT 20
   

Hostname/IP does not match certificate's altnames: Host: localhost. is not in the cert's altnames.

L'indirizzo host non corrisponde all'indirizzo nei nomi alternativi del certificato del server.

Se utilizzi Node.js con verify-full o un equivalente, utilizza il nome DNS per il parametro servername. Il nome DNS è disponibile sul server utilizzando openssl. Ad esempio: openssl x509 -in server-cert.pem -noout -text |grep 'DNS:'.

 ssl: {
  rejectUnauthorized: true,
  ca: fs.readFileSync("/path/to/server/CA"),
  servername: 'N-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx.us-central1.sql.goog'
}

Creazione delle istanze

Problema Risoluzione dei problemi
Messaggio di errore: Failed to create subnetwork. Couldn't find free blocks in allocated IP ranges. Please allocate new ranges for this service provider. Non sono disponibili altri indirizzi nell'intervallo IP allocato. Là sono possibili i seguenti scenari:

  • La dimensione dell'intervallo IP allocato per la connessione privata al servizio è minore di /24.
  • La dimensione dell'intervallo IP allocato per la connessione al servizio privato è troppo piccola per il numero di istanze Cloud SQL.
  • Il requisito relativo alla dimensione dell'intervallo IP allocato sarà maggiore se vengono create in più regioni. Vedi la dimensione intervallo allocato

Per risolvere il problema, puoi espandere l'intervallo IP allocato esistente o allocare un intervallo IP aggiuntivo alla connessione del servizio privato. Per ulteriori informazioni, consulta Allocare un intervallo di indirizzi IP.

Se hai utilizzato il flag --allocated-ip-range-name durante la creazione nell'istanza Cloud SQL, puoi espandere solo l'intervallo IP specificato.

Se stai allocando un nuovo intervallo, assicurati che l'allocazione non che si sovrappongono a eventuali allocazioni esistenti.

Dopo aver creato un nuovo intervallo IP, aggiorna il peering VPC con quanto segue :

gcloud services vpc-peerings update \
--service=servicenetworking.googleapis.com \
--ranges=OLD_RESERVED_RANGE_NAME,NEW_RESERVED_RANGE_NAME \
--network=VPC_NETWORK \
--project=PROJECT_ID \
--force
    

Se stai espandendo un'allocazione esistente, assicurati di aumentare solo l'intervallo di allocazione e non diminuirlo. Ad esempio, se l'allocazione originale era 10.0.10.0/24, imposta la nuova allocazione su almeno 10.0.10.0/23.

In generale, se parte da un'allocazione /24, riduci la dimensione /mask del 1 per ogni condizione (gruppo di tipi di istanze aggiuntivi, regione aggiuntiva) è una buona regola empirica. Ad esempio, se stai tentando di creare entrambi i gruppi di tipo di istanza nella stessa allocazione, è sufficiente passare da /24 a /23.

Dopo aver ampliato un intervallo IP esistente, aggiorna il peering VPC con il seguente comando:

gcloud services vpc-peerings update \
--service=servicenetworking.googleapis.com \
--ranges=RESERVED_RANGE_NAME \
--network=VPC_NETWORK \
--project=PROJECT_ID
    
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.
Messaggio di errore: Failed to create subnetwork. Required 'compute.projects.get' permission for PROJECT_ID. Quando crei un'istanza utilizzando un indirizzo IP privato, viene creato un account di servizio just in time utilizzando l'API Service Networking. Se hai abilitato solo di recente l'API Service Networking, quindi l'account di servizio potrebbe non essere creato e la creazione dell'istanza non riesce. In questo caso, devi attendere che l'account di servizio venga propagato nel sistema o aggiungerlo manualmente con le autorizzazioni richieste.

Esporta

Problema Risoluzione dei problemi
HTTP Error 409: Operation failed because another operation was already in progress. Esiste già un'operazione in attesa per l'istanza. Solo un'operazione è consentito alla volta. Prova la richiesta dopo che l'operazione attuale è completato.
HTTP Error 403: The service account does not have the required permissions for the bucket. Assicurati che il bucket esista e l'account di servizio per Cloud SQL istanza (che sta eseguendo l'esportazione) ha Ruolo Storage Object Creator (roles/storage.objectCreator) per consentire l'esportazione nel bucket. Vedi Ruoli IAM per Cloud Storage.
L'esportazione in formato CSV è riuscita, ma l'esportazione SQL non è riuscita. I formati CSV e SQL vengono esportati in modo diverso. Il formato SQL esporta l'intero database e probabilmente richiede più tempo per il completamento. Il formato CSV consente di definire gli elementi del database da includere nell'esportazione.

Utilizzare le esportazioni CSV ed esportare solo ciò che serve.

L'esportazione sta richiedendo troppo tempo. Cloud SQL non supporta le operazioni sincrone simultanee.

Utilizza il caricamento di esportazione. A un livello generale, durante il trasferimento delle esportazioni, anziché eseguire un'esportazione sull'istanza di origine, Cloud SQL avvia un'istanza di offload per eseguire l'esportazione. La distribuzione dell'esportazione ha diverse vantaggi, tra cui l'aumento delle prestazioni sull'istanza di origine e sblocco di operazioni amministrative durante l'esecuzione dell'esportazione. Con il ribaltamento dell'esportazione, la latenza totale può aumentare in base al tempo necessario per avviare l'istanza di ribaltamento. In genere, per le esportazioni di dimensioni ragionevoli, la latenza non è significativa. Tuttavia, se l'esportazione è sufficientemente ridotta, potresti notare un aumento della latenza.

Errore di creazione estensione. Il file di dump contiene riferimenti a un'estensione non supportata.

Modifica il file dump per rimuovere i riferimenti.

Errore durante l'utilizzo di pg_dumpall. Utilizzo dell'utilità pg_dumpall con il flag --global richiede ruolo super user, questo ruolo non è supportato in Cloud SQL per PostgreSQL. Per evitare errori che si verificano durante l'esecuzione di operazioni di esportazione che includono nomi utente, utilizza anche --no-role-passwords flag.
L'operazione di esportazione scade prima di esportare qualcosa e vedrai il messaggio di errore Could not receive data from client: Connection reset by peer. Se Cloud Storage non riceve dati in un di tempo, in genere circa sette minuti, la connessione viene reimpostata. È è possibile che l'esecuzione della query di esportazione iniziale richieda troppo tempo.

Esegui un'esportazione manuale utilizzando lo strumento pg_dump.

Vuoi che le esportazioni siano automatiche. Cloud SQL non fornisce un modo per automatizzare le esportazioni.

Potresti creare il tuo sistema di esportazione automatizzato utilizzando Google Cloud come Cloud Scheduler, funzioni di Pub/Sub e Cloud Run, simile a questo articolo su l'automazione dei backup.

Bandiere

Problema Risoluzione dei problemi
Puoi impostare il fuso orario per una sessione, ma farlo scade quando ti disconnetti.

Connettiti al database e imposta fuso orario del database in base a quello desiderato per utente o per database.

In Cloud SQL per PostgreSQL, puoi specificare quanto segue. Queste impostazioni rimangono dopo la chiusura di una sessione, simulando una configurazione di .conf:

ALTER DATABASE dbname SET TIMEZONE TO 'timezone';
ALTER USER username SET TIMEZONE TO 'timezone';

Queste impostazioni si applicano solo alle nuove connessioni al database. Per visualizzare la variazione del fuso orario, scollega l'istanza e ricollegala.

Alta disponibilità

Problema Risoluzione dei problemi
Non riesci a trovare le metriche per un failover manuale. Nelle metriche vengono inclusi solo i failover automatici.
Le risorse dell'istanza Cloud SQL (CPU e RAM) sono vicine al 100% di utilizzo, causando l'interruzione dell'istanza ad alta disponibilità. La dimensione della macchina dell'istanza è troppo piccola per il caricamento.

Modifica l'istanza per eseguire l'upgrade a una dimensione della macchina più grande per ottenere più CPU e memoria.

Importa

Problema Risoluzione dei problemi
Messaggio di errore: permission denied for schema public Per PostgreSQL 15 e versioni successive, se il database di destinazione viene creato da template0, l'importazione dei dati potrebbe non riuscire. Per risolvere il problema, concedi all'utente cloudsqlsuperuser i privilegi dello schema pubblico eseguendo il comando SQL GRANT ALL ON SCHEMA public TO cloudsqlsuperuser.
HTTP Error 409: Operation failed because another operation was already in progress. Esiste già un'operazione in attesa per l'istanza. È consentita una sola operazione alla volta. Prova la richiesta dopo che l'operazione attuale è completato.
L'operazione di importazione sta richiedendo troppo tempo. Troppe connessioni attive possono interferire con le operazioni di importazione.

Chiudi le operazioni inutilizzate. Controlla l'utilizzo di CPU e memoria della tua istanza Cloud SQL per assicurarti che siano disponibili moltissime risorse. Il modo migliore per garantire il massimo delle risorse per l'importazione è riavviare l'istanza prima di iniziare l'operazione.

Un riavvio:

  • Chiude tutte le connessioni.
  • Termina qualsiasi attività che potrebbe consumare risorse.
Un'operazione di importazione può non riuscire quando uno o più utenti a cui viene fatto riferimento nel il file di dump non esiste. Prima di importare un file di dump, tutti gli utenti del database che possiedono gli oggetti a cui sono state concesse le autorizzazioni per gli oggetti nel database di cui è stato eseguito il dump, database di destinazione. In caso contrario, l'operazione di importazione non riesce a ricreare gli oggetti con la proprietà o le autorizzazioni originali.

Crea gli utenti del database prima dell'importazione.

Dopo aver importato i dati, la dimensione di utilizzo del disco dati sarà molto maggiore.

Potrebbe verificarsi un utilizzo imprevisto del disco dopo l'importazione dei dati. Questo utilizzo potrebbe essere dovuto all'utilizzo del recupero point-in-time.

Per risolvere il problema, dopo aver importato i dati, disattiva il recupero point-in-time se vuoi eliminare i log e recuperare spazio di archiviazione. Tieni presente che la riduzione dello spazio di archiviazione utilizzato non riduce le dimensioni dello spazio di archiviazione di cui è stato eseguito il provisioning per l'istanza.

Messaggio di errore: GRANT stderr: ERROR: must be member of role ROLE_NAME

Questo messaggio di errore viene visualizzato se tenti di importare un file di dump SQL che viene caricato in Cloud Storage in un database Cloud SQL e il job di importazione è stato eseguito per circa quattro giorni.

ROLE_NAME è un ruolo di database personalizzato definito nel database PostgreSQL di origine. L'utente predefinito di cloudsqlsuperuser importa i il file di dump SQL. Tuttavia, questo utente potrebbe non appartenere al ruolo ROLE_NAME.

Per risolvere il problema, svolgi i seguenti passaggi:

  1. Crea il ruolo ROLE_NAME nel database di destinazione in cui stai importando il file di dump SQL.
  2. Non utilizzare l'utente cloudsqlsuperuser per importare il file. Invece, Nel database di destinazione, specifica un utente membro del ruolo ROLE_NAME. Per specificare l'utente, esegui il seguente comando:

    gcloud sql import sql INSTANCE URI [--async]
    [--database=DATABASE, -d DATABASE] [--user=USER] [GCLOUD_WIDE_FLAG …]

Integrazione con Vertex AI

Problema Risoluzione dei problemi
Messaggio di errore: Google ML integration API is supported only on Postgres version 12 or above. Per attivare l'integrazione di Vertex AI in Cloud SQL, devi disporre di un database Cloud SQL per PostgreSQL, versione 12 o successiva. Per eseguire l'upgrade del database a questa versione, consulta Eseguire l'upgrade della versione principale del database sul posto.
Messaggio di errore: Google ML Integration API is not supported on shared core instance. Please upsize your machine type. Se hai selezionato un core condiviso per il tipo di macchina dell'istanza, non puoi attivare l'integrazione di Vertex AI in Cloud SQL. Esegui l'upgrade del tipo di macchina a un core dedicato. Per ulteriori informazioni, vedi Tipo di macchina.
Messaggio di errore: Google ML Integration is unsupported for this maintenance version. Please follow https://cloud.google.com/sql/docs/postgres/self-service-maintenance to update the maintenance version of the instance. Per attivare l'integrazione di Vertex AI in Cloud SQL, la versione di manutenzione dell'istanza deve essere R20240130 o successiva. Per eseguire l'upgrade dell'istanza a questa versione, consulta Manutenzione self-service.
Messaggio di errore: Cannot invoke ml_predict_row if 'cloudsql.enable_google_ml_integration' is off. Il flag di database cloudsql.enable_google_ml_integration è disattivato. Cloud SQL non può essere integrato con Vertex AI.

Per attivare questo flag, utilizza il comando gcloud sql instances patch:

gcloud sql instances patch INSTANCE_NAME --database-flags cloudsql.enable_google_ml_integration=on

Sostituisci INSTANCE_NAME con il nome dell'istanza Cloud SQL principale.
Messaggio di errore: Failed to connect to remote host: Connection refused. L'integrazione tra Cloud SQL e Vertex AI non è abilitata. Per attivare questa integrazione, utilizza il comando gcloud sql instances patch:

gcloud sql instances patch INSTANCE_NAME
--enable-google-ml-integration


Sostituisci INSTANCE_NAME con il nome dell'istanza Cloud SQL principale.
Messaggio di errore: Vertex AI API has not been used in project PROJECT_ID before or it is disabled. Enable it by visiting /apis/api/aiplatform.googleapis.com/overview?project=PROJECT_ID then retry. L'API Vertex AI non è abilitata. Per saperne di più sull'abilitazione di questa API, consulta Abilitare l'integrazione del database con Vertex AI.
Messaggio di errore: Permission 'aiplatform.endpoints.predict' denied on resource. Le autorizzazioni Vertex AI non vengono aggiunte all'account di servizio Cloud SQL per il progetto in cui si trova l'istanza Cloud SQL. Per saperne di più sull'aggiunta di queste autorizzazioni all'account di servizio, consulta Abilitare l'integrazione del database con Vertex AI.
Messaggio di errore: Publisher Model `projects/PROJECT_ID/locations/REGION_NAME/publishers/google/models/MODEL_NAME` not found. Il modello di machine learning o l'LLM non esiste in Vertex AI.
Messaggio di errore: Resource exhausted: grpc: received message larger than max. Le dimensioni della richiesta che Cloud SQL passa a Vertex AI superano il limite di gRPC di 4 MB per richiesta.
Messaggio di errore: Cloud SQL attempts to send a request to Vertex AI. However, the instance is in the %s region, but the Vertex AI endpoint is in the %s region. Make sure the instance and endpoint are in the same region. Cloud SQL tenta di inviare una richiesta a Vertex AI. Tuttavia, l'istanza si trova in una regione, ma l'endpoint Vertex AI si trova in un'altra. Per risolvere il problema, l'istanza e l'endpoint devono trovarsi entrambi nella stessa regione.
Messaggio di errore: The Vertex AI endpoint isn't formatted properly. Il formato dell'endpoint Vertex AI non è corretto. Per ulteriori informazioni, consulta Utilizzare endpoint privati per la previsione online.
Messaggio di errore: Quota exceeded for aiplatform.googleapis.com/online_prediction_requests_per_base_model with base model: textembedding-gecko. Il numero di richieste che Cloud SQL passa a Vertex AI supera il limite di 1500 richieste al minuto per regione, per modello e per progetto.

Logging

Problema Risoluzione dei problemi
La registrazione utilizza molta CPU e memoria nell'istanza Cloud SQL. Il logging deve essere ottimizzato.

Il flag log_statement può essere impostato su Nessuno e il flag Il flag logging_collector può essere disattivato. Se il logging è ancora potrebbero verificarsi altri flag relativi ai log che possono essere ottimizzati. Puoi modifica l'istanza per modificare questi flag.

Log di controllo non trovati. I log di accesso ai dati vengono scritti solo se l'operazione è autenticata chiamata API basata sull'utente che crea, modifica o legge i dati creati dall'utente. o se l'operazione accede ai file di configurazione o ai metadati delle risorse.
Informazioni sulle operazioni non trovate nei log. Vuoi trovare ulteriori informazioni su un'operazione.

Ad esempio, un utente è stato eliminato, ma non riesci a scoprire chi l'ha fatto. I log mostrano è stata avviata, ma non fornisci altre informazioni. Per consentire la registrazione di informazioni dettagliate e che consentono l'identificazione personale (PII) come queste, devi attivare la registrazione dei controlli.

I file di log sono difficili da leggere. Preferisci visualizzare i log in formato json o text.Puoi utilizzare gcloud logging read insieme ai comandi di post-elaborazione di Linux per scaricare i log.

Per scaricare i log in formato JSON:

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
    

Per scaricare i log come TEXT:

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
   
I log delle query non sono presenti nei log PostgreSQL. Devi attivare i flag pgaudit.
  1. Da un terminale, connettiti al tuo database:
    gcloud sql connect INSTANCE_NAME
          
  2. Esegui questo comando per creare l'estensione:
    CREATE EXTENSION pgaudit;
          
  3. Esci dal database ed esegui questo comando da un terminale:
    gcloud sql instances patch INSTANCE_NAME \
    --database-flags=cloudsql.enable_pgaudit=on,pgaudit.log=all
         

Gestione delle istanze

Problema Risoluzione dei problemi
Vuoi scoprire quali query sono in esecuzione al momento. Connettiti al database ed esegui questa query:

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;

Vuoi sapere quali unità vengono utilizzate per un campo specifico. Connettiti al database ed esegui la seguente query (utilizzando il tuo FIELD_NAME):

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

Vuoi trovare il valore attuale di un'impostazione di database. Connettiti al database ed esegui questa query (con il tuo SETTING_NAME):

SHOW SETTING_NAME;

Esegui SHOW ALL; per visualizzare tutte le impostazioni.

Vuoi interrompere un processo in background bloccato. L'utente deve disporre del ruolo pg_signal_backend.

Esegui questi comandi:

  1.       GRANT pg_signal_backend TO USERNAME;
          
  2. Trova l'ID del processo bloccato o bloccato:
          SELECT pid, usename, state, query FROM pg_stat_activity;
          
  3. Interrompi un processo in esecuzione o inattivo utilizzando questi comandi:
          SELECT pg_cancel_backend(pid)
                FROM pg_stat_activity
                WHERE usename = 'USERNAME';
          
          
          SELECT pg_terminate_backend(pid)
                FROM pg_stat_activity
                WHERE usename = 'USERNAME';
          
          
L'istanza sta per raggiungere il 100% di consumo degli ID transazione. Il monitoraggio interno ti avvisa che l'istanza sta per raggiungere il 100% di utilizzo degli ID transazione. Vuoi evitare il wrapping delle transazioni, che può bloccare le scritture.

Il job di autovacuum potrebbe essere bloccato o potrebbe non recuperare gli ID transazione abbastanza velocemente da stare al passo con il carico di lavoro.

Per evitare interruzioni del servizio a causa di problemi di wraparound delle transazioni, puoi esaminare questi suggerimenti per il self-service per gestire il wraparound degli TXID.

Per consigli generali sull'ottimizzazione, consulta Ottimizzazione, monitoraggio e risoluzione dei problemi delle operazioni VACUUM in PostgreSQL.

L'archiviazione temporanea ha aumentato l'archiviazione automatica. Lo spazio di archiviazione automatico è attivo.

Il riavvio elimina i file temporanei, ma non riduce lo spazio di archiviazione. Solo l' assistenza clienti può reimpostare le dimensioni dell'istanza.

I dati vengono eliminati automaticamente. Molto probabilmente uno script è in esecuzione da qualche parte nel tuo ambiente.

Controlla i log intorno al momento dell'eliminazione e verifica se è in esecuzione uno script malintenzionato da una dashboard o da un'altra procedura automatica.

Impossibile eliminare l'istanza. Potresti visualizzare il messaggio di errore ERROR: (gcloud.sql.instances.delete) HTTP Error 409: The instance or operation is not in an appropriate state to handle the request oppure l'istanza potrebbe presentare un INSTANCE_RISKY_FLAG_CONFIG la segnalazione dello stato.

Ecco alcune possibili spiegazioni:

  • È in corso un'altra operazione. Le operazioni di Cloud SQL contemporaneamente. Attendi il completamento dell'altra operazione.
  • Viene attivato l'avviso INSTANCE_RISKY_FLAG_CONFIG ogni volta che viene utilizzato almeno un flag beta. Rimuovi il le impostazioni dei flag rischiosi e riavvia l'istanza
L'istanza è bloccata a causa di grandi dimensioni di dati temporanei. Il sistema può creare molte tabelle temporanee contemporaneamente, a seconda delle query e del carico.

Purtroppo, non puoi ridurre le dimensioni del file ibtmp1 con nessun altro metodo oltre a riavviare il servizio.

Un'opzione di mitigazione è creare la tabella temporanea con ROW_FORMAT=COMPRESSED, in modo che venga archiviata negli spazi tabella file per tabella nella directory dei file temporanei. Tuttavia, lo svantaggio è costituito dai costi delle prestazioni associati alla creazione e alla rimozione per ogni tabella temporanea.

Errore fatale durante l'upgrade. I log potrebbero rivelare di più, ma in ogni caso potrebbe essere necessaria l'assistenza clienti per forzare la ricostituzione dell'istanza.
L'istanza è bloccata durante il riavvio dopo aver esaurito lo spazio su disco. La funzionalità di aumento automatico dello spazio di archiviazione non è abilitata.

Se lo spazio di archiviazione dell'istanza finisce e la funzionalità di aumento automatico dello spazio di archiviazione non è abilitata, l'istanza diventa offline. Per evitare questo problema, puoi modificare l'istanza per abilitare l'aumento automatico dello spazio di archiviazione.

L'istanza principale on-premise è bloccata. Google Cloud non può aiutarti con le istanze non in Cloud SQL.
Arresto lento al riavvio. Quando un'istanza viene arrestata, tutte le connessioni in sospeso che non termini entro 60 secondi rendono l'arresto sporco.

Poiché le connessioni durano meno di 60 secondi, la maggior parte delle è possibile evitare gli arresti, incluse le connessioni dal database al prompt dei comandi. Se mantieni queste connessioni aperte per ore o giorni, gli arresti anomali possono non essere corretti.

Un utente non può essere eliminato. L'utente ha probabilmente oggetti nel database che dipendono da questo. Tu devono rilasciare gli oggetti o riassegnarli a un altro utente.

Scopri quali oggetti dipendono dall'utente, poi rilasciali o riassegnali per questi oggetti a un altro utente.

Questo thread su Stack Exchange spiega come trovare gli oggetti di proprietà per l'utente.
Alcune query sono lente. Le query possono essere lente per molti motivi, principalmente per aspetti specifici del database. Un motivo che può coinvolgere Cloud SQL è la latenza della rete, quando la risorsa di origine (autore o lettore) e la risorsa di destinazione (Cloud SQL) si trovano in regioni diverse.

Fai riferimento in particolare ai suggerimenti generali sul rendimento.

Per inserimenti, aggiornamenti o eliminazioni lenti dei database, considera quanto segue azioni:

  • Controlla le posizioni del writer e del database. inviare i dati per molto tempo la distanza introduce latenza.
  • Controlla la posizione del lettore e del database. la latenza influisce sulla lettura il rendimento è ancora superiore a quello della scrittura

Per ridurre la latenza, il consiglio è di individuare sia l'origine che risorse di destinazione nella stessa regione.

È indicato che la memoria è insufficiente, ma non è indicato dai grafici di monitoraggio. Un'istanza può non riuscire e generare il codice di errore Out of memory, ma i grafici della console Google Cloud o di Monitoraggio di Cloud sembrano indicare che è ancora disponibile della memoria.

Oltre al carico di lavoro, esistono altri fattori che possono influire sulla memoria di rete, ad esempio il numero di connessioni attive e l'overhead interno i processi di machine learning. Questi aspetti non sempre si riflettono nei grafici di monitoraggio.

Assicurati che l'istanza abbia un overhead sufficiente per tenere conto del tuo carico di lavoro più un overhead aggiuntivo.

Recupero di un'istanza eliminata. Tutti i dati su un'istanza, inclusi i backup, vengono persi definitivamente quando viene eliminata l'istanza.

Per preservare i dati, esportali in Cloud Storage prima di eliminare un'istanza.

Il ruolo Amministratore Cloud SQL include l'autorizzazione per eliminare in esecuzione in un'istanza Compute Engine. Per evitare l'eliminazione accidentale, concedi questo ruolo solo se necessario.

Vuoi rinominare un'istanza Cloud SQL esistente. La ridenominazione di un'istanza esistente non è supportata.

Esistono altri modi per raggiungere l'obiettivo creando una nuova istanza.

  • Puoi clonare l'istanza che vuoi rinominare e impostare un nuovo nome per l'istanza clonata. Ciò ti consente di creare la nuova istanza senza dover importare i dati manualmente. Come quando crei una nuova istanza, l'istanza clonata ha un nuovo indirizzo IP.
  • Puoi esportare i dati della tua istanza in un Cloud Storage bucket, creare una nuova istanza con il nuovo nome import i dati nella nuova istanza.

In entrambi i casi, puoi eliminare la vecchia istanza dopo che l'operazione è stata fatto. Ti consigliamo di utilizzare la procedura di clonazione, in quanto non influisce sul rendimento e non richiede di rifare le impostazioni di configurazione dell'istanza, come flag, tipo di macchina, dimensioni dello spazio di archiviazione e memoria.

Errore durante l'eliminazione di un'istanza. Se la protezione da eliminazione è abilitata per un'istanza, conferma i tuoi piani per eliminarla. Poi, disabilita la protezione da eliminazione prima di eliminare l'istanza.

Private Service Connect

Problema Risoluzione dei problemi
Il collegamento al servizio dell'istanza non accetta l'endpoint Private Service Connect.
  1. Controlla lo stato dell'endpoint.

    gcloud

    Per controllare lo stato, utilizza il comando
    gcloud compute forwarding-rules describe.

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

    Effettua le seguenti sostituzioni:

    • ENDPOINT_NAME: il nome dell'endpoint
    • PROJECT_ID: l'ID o il numero di progetto del progetto Google Cloud che contiene l'endpoint
    • REGION_NAME: il nome della regione per l'endpoint

    REST

    Prima di utilizzare i dati della richiesta, effettua le seguenti sostituzioni:

    • PROJECT_ID: l'ID o il numero di progetto del progetto Google Cloud che contiene l'endpoint Private Service Connect
    • REGION_NAME: il nome della regione
    • ENDPOINT_NAME: il nome dell'endpoint

    Metodo HTTP e URL:

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

    Per inviare la richiesta, espandi una di queste opzioni:

    Dovresti ricevere una risposta JSON simile alla seguente:

    {
      "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. Verifica che lo stato dell'endpoint sia ACCEPTED. Se lo stato è PENDING, l'istanza non consente il progetto Google Cloud contenente l'endpoint. Assicurati che il progetto di rete in cui viene creato l'endpoint sia consentito. Per saperne di più, consulta Modificare un'istanza con Private Service Connect abilitato.

Replica

Problema Risoluzione dei problemi
La replica di lettura non è stata avviata al momento della creazione. Probabilmente è presente un errore più specifico nei file di log. Esamina i log in Cloud Logging per trovare l'errore effettivo.
Impossibile creare la replica di lettura: errore invalidFlagValue. Uno dei flag nella richiesta non è valido. Potrebbe essere una segnalazione fornito esplicitamente o uno impostato su un valore predefinito.

Innanzitutto, verifica che il valore del flag max_connections sia maggiore o uguale al valore dell'istanza principale.

Se il flag max_connections è impostato correttamente, esamina i log in Cloud Logging per trovare l'errore effettivo.

Impossibile creare la replica di lettura: errore sconosciuto. Probabilmente contiene un errore più specifico nei file di log. Esamina i log in Cloud Logging per trovare l'errore effettivo.

Se l'errore è: set Service Networking service account as servicenetworking.serviceAgent role on consumer project, disabilita e riattiva Service Networking API. Questa azione crea l'account di servizio necessario per continuare la procedura.

Il disco è pieno. La dimensione del disco dell'istanza principale può diventare piena durante la creazione della replica. Modifica l'istanza principale per eseguirne l'upgrade a una dimensione del disco maggiore.
Lo spazio su disco aumenta in modo significativo. Uno slot non utilizzato attivamente per monitorare i dati fa sì che PostgreSQL mantenere i segmenti WAL a tempo indeterminato, causando l'aumento indefinita dello spazio su disco. Se utilizzi le funzionalità di decodifica e replica logica in Cloud SQL, gli slot di replica vengono creati e eliminati automaticamente. Gli slot di replica inutilizzati possono essere rilevati eseguendo una query sulla visualizzazione di sistema pg_replication_slots e applicando un filtro alla colonna active. Gli slot inutilizzati possono essere eliminati per rimuovere i segmenti WAL utilizzando il comando pg_drop_replication_slot.
L'istanza replica utilizza troppa memoria. La replica utilizza la memoria temporanea per memorizzare nella cache la lettura richiesta più spesso operazioni, il che può portarlo a utilizzare più memoria rispetto all'istanza principale.

Riavvia l'istanza replica per recuperare lo spazio di memoria temporaneo.

Replica interrotta. È stato raggiunto il limite massimo di spazio di archiviazione e l'archiviazione automatica L'aumento non è abilitato.

Modifica l'istanza per abilitare automatic storage increase.

Il ritardo nella replica è costantemente elevato. Il carico di scrittura è troppo elevato per la replica. Ritardo della replica si verifica quando il thread SQL su una replica non riesce a stare al passo Thread IO. Alcuni tipi di query o carichi di lavoro possono causare un ritardo elevato della replica temporaneo o permanente per un determinato schema. Alcune delle cause comuni del ritardo nella replica sono:
  • Query lente sulla replica. Trovale e correggile.
  • Tutte le tabelle devono avere una chiave univoca/principale. Ogni aggiornamento su senza una chiave univoca/primaria causa scansioni complete della tabella replica.
  • Query come DELETE ... WHERE field < 50000000 causano con la replica basata su riga, poiché un numero enorme gli aggiornamenti si accumulano sulla replica.

Ecco alcune possibili soluzioni:

  • Modifica l'istanza per aumentare le dimensioni della replica.
  • Riduci il carico sul database.
  • Invia traffico di lettura alla replica di lettura.
  • Indicizza le tabelle.
  • Identifica e correggi le query di scrittura lente.
  • Ricrea la replica.
Errori durante la ricreazione degli indici in PostgreSQL 9.6. PostgreSQL ti informa che devi ricreare specifico indice. Questa operazione può essere eseguita solo nell'istanza principale. Se crei una nuova istanza di replica, a breve riceverai di nuovo lo stesso errore. Gli indici hash non vengono propagati alle repliche nelle versioni di PostgreSQL precedenti alla 10.

Se devi utilizzare indici hash, esegui l'upgrade a PostgreSQL 10 o versioni successive. Altrimenti, Se vuoi usare anche le repliche, non usare gli indici hash in PostgreSQL 9.6.

La query sull'istanza principale è sempre in esecuzione. Dopo aver creato una replica, la query SELECT * from pg_stat_activity where state = 'active' and pid = XXXX and username = 'cloudsqlreplica' dovrebbe essere eseguita continuamente nell'istanza principale.
La creazione della replica non riesce a causa di un timeout. Le transazioni non impegnate a lunga esecuzione sull'istanza principale possono causare in caso di errore durante la creazione della replica di lettura.

Ricrea la replica dopo aver interrotto tutte le query in esecuzione.

Se l'istanza principale e la replica hanno dimensioni vCPU diverse, potrebbero verificarsi problemi di prestazioni delle query perché l'ottimizzatore delle query prende in considerazione le dimensioni vCPU.

Per risolvere il problema, completa i seguenti passaggi:

  1. Attiva il flag log_duration e imposta il parametro log_statement su ddl. In questo modo ottieni sia le query sia il tempo di esecuzione sul database. Tuttavia, a seconda del carico di lavoro, potrebbero verificarsi problemi di prestazioni.
  2. Sia nell'istanza principale che nella replica di lettura, esegui explain analyze per le query.
  3. Confronta il piano di query e verifica la presenza di differenze.

Se si tratta di una query specifica, modificala. Ad esempio, puoi modificare l'ordine delle unioni per verificare se il rendimento migliora.