Controlla se la tua domanda o il tuo problema è già stato risolto in una delle seguenti pagine:
- Domande frequenti
- Problemi noti
- Messaggi di errore
- Diagnostica i problemi
- Eseguire il debug dei problemi di connessione
Gli argomenti di questa pagina includono:
- Backup e ripristino
- Annullare importazione ed esportazione
- Clonaggio
- Connettività
- Creazione di istanze
- Flag
- Alta disponibilità
- Importazione ed esportazione
- Integrazione con Vertex AI
- Logging
- Gestione delle istanze
- Replica
Backup e ripristino
Problema | Risoluzione dei problemi |
---|---|
Non puoi visualizzare lo stato dell'operazione attuale. | La console Google Cloud segnala solo l'esito positivo o negativo solo al termine dell'operazione. Non è progettato per mostrare avvisi o altri aggiornamenti.
Esegui il
comando |
Vuoi sapere 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 filtra in base al testo per trovare l'utente. Per informazioni private, potrebbe essere necessario utilizzare gli audit log. I file di log pertinenti includono:
|
Dopo aver eliminato un'istanza, non puoi eseguire un backup. | Dopo l'eliminazione definitiva di un'istanza, non è possibile recuperare i dati. Tuttavia, se l'istanza viene ripristinata, verranno ripristinati anche i relativi backup. Per maggiori informazioni sul recupero di un'istanza eliminata, vedi Backup di recupero. Se hai eseguito un'operazione di esportazione, crea una nuova istanza, quindi esegui un'operazione di importazione per ricreare il database. Le esportazioni 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 contattare
l'
assistenza clienti per |
Un'operazione di ripristino può non riuscire quando uno o più utenti a cui viene fatto riferimento nel file di dump SQL non esistono. | Prima di ripristinare un dump SQL, tutti gli utenti del database che sono proprietari degli oggetti o a cui sono state concesse autorizzazioni per gli oggetti nel database di cui è stato eseguito il dump devono esistere nel database di destinazione. In caso contrario, l'operazione di ripristino non riuscirà 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 in cui puoi conservare i backup automatici da 7 a 30 giorni o più. | Puoi
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 che i backup attualmente visibili sono gli unici da cui puoi eseguire il ripristino automatici.
Per conservare i backup a tempo indeterminato, puoi creare un backup on demand, poiché non viene eliminato con la stessa modalità dei backup automatici. I backup on demand rimangono a tempo indeterminato. Vale a dire che rimangono fino a quando non vengono eliminati o fino all'eliminazione dell'istanza a cui appartengono. Poiché questo tipo di backup non viene eliminato automaticamente, ciò 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 non riesce ripetutamente a causa di un ciclo tra lo stato non riuscito e di ripristino del backup. I tentativi di connessione e utilizzo del database dopo il ripristino non sono riusciti. |
Tentativi da effettuare
|
Ti accorgi che mancano dei dati quando esegui un'operazione di backup/ripristino. | Le tabelle sono state create come non registrate. Ad esempio:
Queste tabelle non sono incluse in un ripristino da un backup:
La soluzione è evitare di utilizzare tabelle non registrate se vuoi ripristinarle tramite un backup. Se esegui il ripristino da un database in cui sono già presenti tabelle non registrate, puoi eseguire il dump del database in un file e ricaricare i dati dopo aver modificato il file di cui è stato eseguito il dump in |
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 riuscita o annullata. 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 |
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 l'assistenza Google Cloud. |
Clona
Problema | Risoluzione dei problemi |
---|---|
La clonazione non riesce con constraints/sql.restrictAuthorizedNetworks errore. |
L'operazione di clonazione è bloccata dalla configurazione Authorized Networks .
Gli indirizzi Authorized Networks sono configurati per gli indirizzi IP pubblici nella sezione Connettività della console Google Cloud e la clonazione non è consentita per via di Considerazioni sulla sicurezza.
Se puoi, rimuovi tutte le voci |
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 indirizzo IP privato, ma non hai specificato l'intervallo IP allocato che vuoi utilizzare e l'istanza di origine non viene creata con l'intervallo specificato. Di conseguenza, l'istanza clonata viene creata in un intervallo casuale. Utilizza |
Connetti
Problema | Risoluzione dei problemi |
---|---|
Aborted connection . |
Il problema potrebbe essere:
Le applicazioni devono tollerare gli errori di rete e seguire best practice come il pool di connessioni e i nuovi tentativi. La maggior parte dei pooler di connessioni rileva questi errori, ove possibile. In caso contrario, l'applicazione deve riprovare o non riuscire correttamente. Per riprovare la connessione, consigliamo i seguenti metodi:
La combinazione di questi metodi contribuisce a ridurre la limitazione. |
Certificate verify failed . |
I certificati client sono scaduti o il percorso non è corretto. Rigenera i certificati ricreandoli. |
FATAL: database 'user' does not exist . |
gcloud sql connect --user funziona solo con l'utente
postgres predefinito.
Connettiti con l'utente predefinito, quindi modifica gli utenti. |
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 a quello nei nomi alternativi del certificato del server. Se utilizzi Node.js con verify-full o equivalente, utilizza il nome DNS per il parametro servername.
Il nome DNS si trova nel certificato del server utilizzando openssl. Ad esempio,
|
Creare 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 presenti altri indirizzi disponibili nell'intervallo IP allocato. Possono esserci diversi scenari:
Per risolvere il problema, puoi espandere l'intervallo IP allocato esistente o allocare un intervallo IP aggiuntivo alla connessione privata al servizio. Per maggiori informazioni, consulta Assegnare un intervallo di indirizzi IP. Se hai utilizzato il flag Se assegni un nuovo intervallo, assicurati che l'allocazione non si sovrapponga ad alcuna allocazione esistente. Dopo aver creato un nuovo intervallo IP, aggiorna il peering vpc con il seguente comando: 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 di diminuirlo. Ad esempio, se l'allocazione originale era 10.0.10.0/24, imposta la nuova allocazione ad almeno 10.0.10.0/23. In generale, se parte da un'allocazione /24, una buona regola generale è diminuire la dimensione /mask di 1 per ogni condizione (gruppo di tipi di istanza aggiuntivo, regione aggiuntiva). Ad esempio, se si cerca di creare entrambi i gruppi di tipi di istanza sulla stessa allocazione, è sufficiente passare da /24 a /23. Dopo aver espanso 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 con un indirizzo IP privato, viene creato un account di servizio just-in-time utilizzando l'API Service Networking. Se hai abilitato l'API Service Networking solo di recente, l'account di servizio potrebbe non essere creato e la creazione dell'istanza non va a buon fine. In questo caso, devi attendere la propagazione dell'account di servizio nel sistema oppure 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. È consentita una sola operazione alla volta. Prova a eseguire la richiesta al termine dell'operazione attuale. |
HTTP Error 403: The service account does not have the required
permissions for the bucket. |
Assicurati che il bucket esista e che l'account di servizio per l'istanza Cloud SQL (che esegue l'esportazione) abbia il ruolo Storage Object Creator (roles/storage.objectCreator ) per consentire l'esportazione nel bucket. Vedi Ruoli IAM per Cloud Storage. |
L'esportazione del file 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. Il formato CSV consente di definire quali elementi del database includere nell'esportazione.
Usa le esportazioni CSV per esportare solo ciò di cui hai bisogno. |
L'esportazione sta richiedendo troppo tempo. | Cloud SQL non supporta le operazioni sincrone in parallelo.
Utilizza la riduzione del carico delle esportazioni. A livello generale, con la riduzione del carico delle esportazioni, invece di inviare un'esportazione sull'istanza di origine, Cloud SQL avvia un'istanza di trasferimento del carico per eseguire l'esportazione. L'offload dell'esportazione presenta diversi vantaggi, tra cui un aumento delle prestazioni sull'istanza di origine e lo sblocco delle operazioni amministrative durante l'esecuzione dell'esportazione. Con la riduzione del carico delle esportazioni, la latenza totale può aumentare del tempo necessario per attivare l'istanza di offload. In genere, per esportazioni di dimensioni ragionevoli, la latenza non è significativa. Tuttavia, se l'esportazione è abbastanza ridotta, potresti notare un aumento della latenza. |
Errore di creazione estensione. | Il file di dump contiene riferimenti a un'estensione non supportata. |
Errore durante l'utilizzo di pg_dumpall . |
L'utilizzo dell'utilità pg_dumpall con il flag --global richiede il ruolo super user, ma non è supportato in Cloud SQL per PostgreSQL. Per evitare che si verifichino
errori durante l'esecuzione di operazioni di esportazione che includono nomi utente, utilizza anche il
flag --no-role-passwords .
|
L'operazione di esportazione scade prima di esportare qualsiasi cosa e viene visualizzato il messaggio di errore Could not receive data from client: Connection reset
by peer. |
Se Cloud Storage non riceve dati entro un determinato periodo 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 |
Le esportazioni devono essere automatizzate. | Cloud SQL non offre un modo per automatizzare le esportazioni.
Puoi creare il tuo sistema di esportazione automatica utilizzando i prodotti Google Cloud come Cloud Scheduler, Pub/Sub e Cloud Functions, simili a questo articolo sull' automazione dei backup. |
Flag
Problema | Risoluzione dei problemi |
---|---|
Hai impostato il fuso orario per una sessione, ma scade quando ti disconnetti. |
Connettiti al database e imposta il fuso orario del database su quello che preferisci, per utente o per database. In Cloud SQL per PostgreSQL, puoi specificare quanto segue.
Queste impostazioni rimangono dopo la chiusura di una sessione, imitando una configurazione di 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 vedere la modifica del fuso orario, disconnettiti dall'istanza e riconnettiti. |
Alta disponibilità
Problema | Risoluzione dei problemi |
---|---|
Non puoi trovare le metriche per un failover manuale. | Nelle metriche vengono inseriti solo i failover automatici. |
Le risorse dell'istanza Cloud SQL (CPU e RAM) hanno quasi raggiunto il 100% di utilizzo, causando l'arresto dell'istanza ad alta disponibilità. | Le dimensioni della macchina dell'istanza sono troppo piccole per il carico.
Modifica l'istanza per eseguire l'upgrade a una dimensione della macchina più grande e ottenere più CPU e memoria. |
Importazione
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, fornisci i privilegi di schema pubblico all'utente cloudsqlsuperuser 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 a eseguire la richiesta al termine dell'operazione attuale. |
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 dell'istanza Cloud SQL per assicurarti che siano disponibili molte risorse. Il modo migliore per garantire il numero massimo di risorse per l'importazione è riavviare l'istanza prima di iniziare l'operazione. Un riavvio:
|
Un'operazione di importazione può non riuscire quando uno o più utenti a cui viene fatto riferimento nel file di dump non esistono. | Prima di importare un file di dump, tutti gli utenti del database che possiedono oggetti o a cui sono state concesse autorizzazioni per gli oggetti nel database di cui è stato eseguito il dump devono esistere nel 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 l'importazione dei dati, la dimensione di utilizzo del disco dati è molto più elevata. | Dopo l'importazione dei dati, potrebbe essersi verificato un utilizzo imprevisto del disco. Questo utilizzo potrebbe essere dovuto all'utilizzo del recupero point-in-time. Per risolvere il problema, dopo aver importato i dati, disabilita il recupero point-in-time se vuoi eliminare i log e recuperare lo spazio di archiviazione. Tieni presente che la riduzione dello spazio di archiviazione utilizzato non riduce la dimensione 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 caricato in Cloud Storage in un database Cloud SQL e il job di importazione è in esecuzione da circa quattro giorni. ROLE_NAME è un ruolo di database personalizzato definito nel database PostgreSQL di origine. L'utente Per risolvere il problema, completa la seguente procedura:
|
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 abilitare 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, vedi Eseguire l'upgrade della versione principale del database in uso. |
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 abilitare l'integrazione di Vertex AI in Cloud SQL. Esegui l'upgrade del tipo di macchina a 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 abilitare 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 del database cloudsql.enable_google_ml_integration è disattivato. Cloud SQL non può integrarsi 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 abilitare questa integrazione, utilizza il comando gcloud sql instances patch :gcloud sql instances patch INSTANCE_NAME 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 maggiori informazioni 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 di 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ù su come aggiungere 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 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 questo problema, sia l'istanza che l'endpoint devono trovarsi nella stessa regione. |
Messaggio di errore: The Vertex AI endpoint isn't formatted properly. |
L'endpoint Vertex AI non è formattato correttamente. Per ulteriori informazioni, consulta Utilizzare gli endpoint privati per le previsioni 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 per progetto. |
Logging
Problema | Risoluzione dei problemi |
---|---|
Logging utilizza molta CPU e memoria sulla tua istanza Cloud SQL. | Logging deve essere ottimizzato.
Il flag |
Audit log non trovati. | I log di accesso ai dati vengono scritti solo se l'operazione è una chiamata API autenticata dall'utente che crea, modifica o legge i dati creati dall'utente oppure se l'operazione accede a file di configurazione o metadati delle risorse. |
Impossibile trovare informazioni sulle operazioni nei log. | Vuoi scoprire di più su un'operazione.
Ad esempio, un utente è stato eliminato ma non puoi scoprire chi l'ha eseguito. I log mostrano l'operazione avviata, ma non forniscono ulteriori informazioni. Devi abilitare l'audit logging affinché vengano registrate informazioni che consentono l'identificazione personale (PII) dettagliate e come queste. |
I file di log sono difficili da leggere. | Preferisci visualizzare i log come json o text.Puoi utilizzare il comando
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 in formato TESTO: 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 stati trovati nei log PostgreSQL. | Devi abilitare i flag pgaudit.
|
Gestione delle istanze
Problema | Risoluzione dei problemi |
---|---|
Vuoi scoprire quali query sono attualmente in esecuzione. | Connettiti al database ed esegui la query seguente:
|
Vuoi scoprire quali unità vengono utilizzate per un campo specifico. | Connettiti al database ed esegui la seguente query
(utilizzando il tuo FIELD_NAME ):
|
Vuoi trovare il valore attuale di un'impostazione del database. | Connettiti al database ed esegui la seguente query (utilizzando il tuo SETTING_NAME ):
Esegui |
Vuoi interrompere un processo in background bloccato. | L'utente deve disporre del ruolo pg_signal_backend .
Esegui questi comandi:
|
L'istanza sta per raggiungere il 100% di consumo di ID transazione. | Il monitoraggio interno avvisa che l'istanza sta per raggiungere il 100% di consumo degli ID transazione. Vuoi evitare il wraparound 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 dovute a problemi di wraparound delle transazioni, puoi rivedere questi suggerimenti self-service per gestire il wraparound TXID. Per consigli generali sull'ottimizzazione, consulta Ottimizzazione, monitoraggio e risoluzione dei problemi delle operazioni vacuum in PostgreSQL. |
Spazio di archiviazione temporaneo aumentato spazio di archiviazione automatico. | L'archiviazione automatica è abilitata.
Il riavvio elimina i file temporanei, ma non riduce lo spazio di archiviazione. Solo l' assistenza clienti può reimpostare le dimensioni dell'istanza. |
Eliminazione automatica dei dati in corso. | Molto probabilmente uno script è in esecuzione da qualche parte nel tuo ambiente.
Esamina i log al momento dell'eliminazione e controlla se è presente uno script non valido in esecuzione da una dashboard o da un altro processo automatizzato. |
Impossibile eliminare l'istanza. | È possibile che venga visualizzato 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 o che l'istanza abbia uno stato di flag INSTANCE_RISKY_FLAG_CONFIG .
Ecco alcune possibili spiegazioni:
|
L'istanza è bloccata a causa di grandi dimensioni dei dati temporanei. | Il sistema può creare molte tabelle temporanee contemporaneamente, a seconda delle query e del carico.
Sfortunatamente, non puoi ridurre il file Un'opzione di mitigazione è la creazione della tabella temporanea con |
Errore irreversibile durante l'upgrade. | I log possono rivelare maggiori informazioni, ma in ogni caso potrebbe essere necessaria l'assistenza clienti per forzare la nuova creazione dell'istanza. |
L'istanza è bloccata al riavvio dopo aver esaurito lo spazio su disco. | La funzionalità di aumento automatico dello spazio di archiviazione non è abilitata.
Se l'istanza esaurisce lo spazio di archiviazione e la funzionalità di aumento automatico dello spazio di archiviazione non è abilitata, l'istanza passa alla modalità 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 che non sono in Cloud SQL. |
Arresto lento al riavvio. | Quando un'istanza viene arrestata, le eventuali connessioni in sospeso che non terminano entro 60 secondi rendono non pulita l'arresto.
Avendo connessioni che durano meno di 60 secondi, è possibile evitare la maggior parte degli arresti anomali sporchi, incluse le connessioni dal prompt dei comandi del database. Se mantieni queste connessioni aperte per ore o giorni, gli arresti possono essere sporchi. |
Impossibile eliminare un utente. | È probabile che l'utente disponga di oggetti nel database che dipendono da questo utente. Devi
rilasciare questi oggetti o riassegnarli a un altro utente.
Scopri quali oggetti dipendono dall'utente, quindi rilascia o riassegnali a un utente diverso. Questo thread su Stack Exchange illustra come trovare gli oggetti di proprietà dell'utente. |
L'esecuzione di query specifiche è lenta. | Le query possono essere lente per molti motivi, principalmente a causa di aspetti specifici del database. Un motivo che può coinvolgere Cloud SQL è la latenza di rete, quando la risorsa di origine (autore o lettore) e la risorsa di destinazione (Cloud SQL) si trovano in regioni diverse.
In particolare, consulta i suggerimenti generali per il rendimento. In caso di operazioni di inserimento, aggiornamento o eliminazione dei database lenti, prendi in considerazione le seguenti azioni:
Per ridurre la latenza, si consiglia di individuare le risorse di origine e di destinazione nella stessa regione. |
È indicato che la memoria è insufficiente, ma i grafici di monitoraggio non la mostrano. | Un'istanza può non riuscire e segnalare Out of memory , ma la console Google Cloud o i grafici di Cloud Monitoring mostrano che è ancora disponibile memoria.
Oltre al carico di lavoro, esistono altri fattori che possono influire sull'utilizzo della memoria, come il numero di connessioni attive e i processi interni di overhead. Questi aspetti non sempre sono visibili nei grafici di monitoraggio. Assicurati che l'istanza abbia un overhead sufficiente per tenere conto del tuo carico di lavoro e un overhead aggiuntivo. |
Recupero di un'istanza eliminata in corso... | Tutti i dati su un'istanza, inclusi i backup, vengono persi definitivamente quando l'istanza viene eliminata.
Per conservare i dati, esportali in Cloud Storage prima di eliminare un'istanza. Il ruolo Amministratore Cloud SQL include l'autorizzazione per eliminare l'istanza. Per impedire l'eliminazione accidentale, concedi questo ruolo solo in base alle esigenze. |
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.
In entrambi i casi, puoi eliminare l'istanza precedente al termine dell'operazione. Ti consigliamo di scegliere la route di clonazione poiché non ha alcun impatto sulle prestazioni e non richiede di ripetere le impostazioni di configurazione dell'istanza, come flag, tipo di macchina, dimensioni di archiviazione e memoria. |
Errore durante l'eliminazione di un'istanza. | Se la protezione da eliminazione è abilitata per un'istanza, conferma l'eliminazione dell'istanza. Quindi disabilita la protezione da eliminazione prima di eliminare l'istanza. |
Replica
Problema | Risoluzione dei problemi |
---|---|
La replica di lettura non ha avviato la replica al momento della creazione. | È probabile che i file di log contengano un errore più specifico. Ispeziona i log in Cloud Logging per trovare l'errore effettivo. |
Impossibile creare la replica di lettura: errore non validoFlagValue. | Uno dei flag nella richiesta non è valido. Potrebbe essere un flag che hai fornito esplicitamente o un flag impostato su un valore predefinito.
Innanzitutto, verifica che il valore del flag Se il flag |
Impossibile creare la replica di lettura: errore sconosciuto. | È probabile che i file di log contengano un errore più specifico.
Ispeziona i log in Cloud Logging per trovare l'errore effettivo.
Se l'errore è: |
Lo spazio sul disco è esaurito. | 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 più grande. |
Lo spazio su disco aumenta in modo significativo. | Uno slot che non viene utilizzato attivamente per monitorare i dati fa sì che PostgreSQL trattiene i segmenti WAL per un tempo indeterminato, causando un'aumento infinito dello spazio su disco. Se utilizzi le funzionalità di replica e decodifica logica in Cloud SQL, gli slot di replica vengono creati e eliminati automaticamente. Per rilevare gli slot di replica inutilizzati, puoi eseguire una query sulla visualizzazione di sistema di pg_replication_slots e applicare un filtro sulla colonna active . Gli slot inutilizzati possono essere eliminati per rimuovere i segmenti WAL utilizzando il comando pg_drop_replication_slot .
|
L'istanza di replica utilizza troppa memoria. | La replica utilizza la memoria temporanea per memorizzare nella cache le operazioni di lettura più richieste, il che può portare a utilizzare più memoria rispetto all'istanza principale.
Riavvia l'istanza di replica per recuperare lo spazio di memoria temporaneo. |
Replica interrotta. | È stato raggiunto il limite massimo di spazio di archiviazione e l'aumento automatico dello spazio di archiviazione non è abilitato.
Modifica l'istanza per abilitare |
Il ritardo della replica è costantemente elevato. | Il carico di scrittura è troppo elevato per essere gestito dalla replica. Il ritardo della replica si verifica quando il thread SQL su una replica non è in grado di stare al passo con il thread di IO. Alcuni tipi di query o carichi di lavoro possono causare un ritardo di replica elevato, temporaneo o permanente, per un determinato schema. Alcune delle cause più comuni del ritardo di replica sono:
Ecco alcune possibili soluzioni:
|
Errori durante la ricostruzione degli indici in PostgreSQL 9.6. | Ricevi un errore da PostgreSQL che ti informa che devi ricreare un determinato indice. Questa operazione può essere eseguita solo sull'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 PostgreSQL precedenti alla 10.
Se devi utilizzare gli indici hash, esegui l'upgrade a PostgreSQL 10 e versioni successive. Altrimenti, se vuoi utilizzare anche le repliche, non utilizzare 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 sull'istanza principale.
|
La creazione della replica non riesce a causa del timeout. | Le transazioni non impegnate a lunga esecuzione nell'istanza principale possono causare la mancata creazione della replica di lettura.
Ricrea la replica dopo aver arrestato tutte le query in esecuzione. |
Se l'istanza principale e la replica hanno dimensioni vCPU diverse, potrebbero verificarsi problemi di prestazioni delle query, poiché lo strumento di ottimizzazione delle query prende in considerazione le dimensioni delle vCPU. |
Per risolvere il problema, completa la seguente procedura:
Se si tratta di una query specifica, modifica la query. Ad esempio, puoi cambiare l'ordine dei join per vedere se ottieni un rendimento migliore. |