Risoluzione dei problemi di Cloud SQL

Questa pagina include suggerimenti per la risoluzione dei problemi di Cloud SQL per i motori di database supportati. Alcuni di questi suggerimenti si applicano solo a un database specifico motori di ricerca, mentre altri sono comuni a tutti.

Per suggerimenti sulla risoluzione dei problemi relativi a specifici motori del database, consulta singole pagine:

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

Gli argomenti di questa pagina includono:

Backup e ripristino

Problema Risoluzione dei problemi
Non puoi visualizzare lo stato dell'operazione corrente. La console Google Cloud segnala l'esito positivo o negativo solo quando l'operazione al termine dell'operazione. Non è progettato 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 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 filtrarli in base al testo per trovare l'utente. Potresti dover utilizzare i log di controllo informazioni private. I file di log pertinenti includono:

  • Se gli audit log di Cloud sono attivati e disponi delle autorizzazioni necessarie per visualizzarli, cloudaudit.googleapis.com/activity potrebbe essere disponibile.
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 ulteriori informazioni sul recupero di un'istanza eliminata, consulta la sezione 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 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 di 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 riesce a ricreare 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 che puoi mantenere automatici i backup da sette a 30 giorni o più. Puoi e configurare il numero di backup automatici da conservare. I backup automatici vengono eliminati regolarmente in base al valore di conservazione configurato. Purtroppo, ciò significa che i backup attualmente visibili sono gli unici backup automatici da cui puoi eseguire il ripristino.

Per conservare i backup a tempo indeterminato, puoi: creazione un backup on demand, in quanto non vengono eliminati come backup automatici. I backup on demand rimangono indefinitamente. ovvero rimangono visibili finché non vengono eliminate o finché non viene eliminata l'istanza a cui appartengono. Poiché questo tipo di backup non viene eliminato automaticamente, può e configurare la 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 perché passa ripetutamente tra gli stati di errore e di ripristino del backup. Tenta di connettersi e di utilizzare il database dopo il ripristino non è riuscito.
  • 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. Usa il pool di connessioni e altro best practice per per la connettività.

Tentativi da effettuare

  1. Verifica che il database sia configurato per autovacuum.
  2. Controlla se nel codice personalizzato è configurata una logica di ripetizione della connessione.
  3. Abbassa il traffico finché il database non si recupera, quindi gira lentamente di backup del traffico.
Ti accorgi che mancano dei dati quando esegui 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 in un'istanza HA.
  • Le tabelle non registrate non sopravvivono agli arresti anomali postgres.
  • Le tabelle non registrate non vengono replicate in repliche di lettura.
  • I dati delle tabelle non registrate vengono cancellati automaticamente durante il ripristino del backup.

La soluzione è evitare di utilizzare tabelle non registrate se vuoi ripristinarle tramite un backup. Se stai eseguendo il ripristino da un database che ha già ha tabelle non registrate, puoi eseguire il dump del database in un file e ricaricare dopo aver modificato il file di cui è stato eseguito il dump in ALTER TABLE per SET LOGGED su queste tabelle.

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 è configurato per gli indirizzi IP pubblici nella sezione Connettività della console Google Cloud e la clonazione non è consentita a causa considerazioni sulla sicurezza.

Rimuovi tutte le voci Authorized Networks da Cloud SQL se puoi. In caso contrario, 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 indirizzo IP privato, ma non hai specificato l'intervallo IP allocato che vuoi utilizzare e l'istanza di origine non è stata creata con l'intervallo specificato. Di conseguenza, 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 TCP keep-alive (il client o il server non risponde, probabilmente sovraccaricato)
  • La durata della connessione del motore del database è stata superata e il server termina la connessione.

Le applicazioni devono tollerare gli errori di rete e seguire le best practice, come il pooling delle connessioni e i tentativi di nuovo accesso. 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 la ripetizione del tentativo di connessione, consigliamo i seguenti metodi:

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

La combinazione di questi metodi consente di ridurre la limitazione.
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

Creazione delle istanze

Problema Risoluzione dei problemi
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, un servizio viene creato just-in-time utilizzando l'API Service Networking. Se hai attivato di recente l'API Service Networking, l'account di servizio potrebbe non essere creato e la creazione dell'istanza potrebbe non riuscire. 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. È consentita una sola operazione 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 ha funzionato, ma l'esportazione in 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.

Utilizza le esportazioni in formato CSV per esportare solo ciò che ti serve.
L'esportazione sta richiedendo troppo tempo. Cloud SQL non supporta le operazioni sincrone simultanee.

Utilizza esportazione offloading. 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 esportazioni di dimensioni ragionevoli, la latenza non è significativa. Tuttavia, se l'esportazione è abbastanza piccola, potresti notare un aumento della latenza.
Errore di creazione estensione. Il file dump contiene riferimenti a un'estensione non supportata.

Modifica il file dump per rimuovere i riferimenti.
Errore durante l'utilizzo di pg_dumpall. L'utilizzo dell'utilità pg_dumpall con il flag --global richiede il ruolo superuser, ma questo ruolo non è supportato in Cloud SQL. 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 qualsiasi elemento e viene visualizzato 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 pg_dump.
Vuoi che le esportazioni siano automatizzate. Cloud SQL non fornisce 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 le funzioni Cloud Run, come spiegato in questo articolo sull' automazione dei backup.

Principale esterno

Problema Risoluzione dei problemi
Lost connection to MySQL server during query when dumping table. L'origine potrebbe non essere più disponibile oppure il dump conteneva pacchetti troppo grande.

Assicurati che il controller principale esterno sia disponibile per la connessione. Puoi anche modificare i valori dell'attributo net_read_timeout e net_write_timeout sull'istanza di origine per arrestare l'errore. Per ulteriori informazioni sui valori consentiti per questi flag, consulta Configurare i flag di database.

Per scoprire di più sull'utilizzo dei flag mysqldump per gli account gestiti, importare migrazione, consulta Flag di sincronizzazione iniziale consentiti e predefiniti
La migrazione iniziale dei dati è riuscita, ma non viene replicato alcun dato. Un possibile motivo di fondo potrebbe essere che il database di origine abbia definito indicatori di replica che impediscono la replica di alcune o di tutte le modifiche al database.

Assicurati che i flag di replica come binlog-do-db, binlog-ignore-db, replicate-do-db o replicate-ignore-db non sono impostate in modo in conflitto.

Esegui il comando show master status sull'istanza principale vedere le impostazioni correnti.
La migrazione iniziale dei dati è riuscita, ma la replica dei dati si arresta dopo un po' di tempo. Tentativi da effettuare

  • Controlla le metriche di replica per l'istanza replica nella sezione Monitoraggio cloud della console Google Cloud.
  • Gli errori del thread IO MySQL o del thread SQL possono essere disponibile in Cloud Logging, mysql.err log file.
  • L'errore viene visualizzato anche durante la connessione all'istanza di replica. Esegui il comando SHOW SLAVE STATUS e controlla se nell'output sono presenti i seguenti campi:
    • Slave_IO_Running
    • Slave_SQL_Running
    • Last_IO_Error
    • Last_SQL_Error
mysqld check failed: data disk is full. Il disco dati dell'istanza di replica è pieno.

Aumenta la dimensione del disco dell'istanza replica. Puoi aumentare manualmente le dimensioni del disco o attivare l'aumento automatico dello spazio di archiviazione.

Replica esterna

Problema Risoluzione dei problemi
Messaggio di errore: The slave is connecting ... master has purged binary logs containing GTIDs that the slave requires. L'istanza Cloud SQL principale ha backup automatici e log e il recupero point-in-time è abilitato, quindi dovrebbe avere un numero sufficiente di log affinché la replica possa recuperare. Tuttavia, in questo caso, anche se log binari, la replica non sa da quale riga iniziare a leggere.

Crea un nuovo file di dump utilizzando le impostazioni di flag corrette e configura la replica esterna utilizzando questo file

  1. Connettiti al client mysql tramite un'istanza Compute Engine.
  2. Esegui mysqldump e utilizza i flag --master-data=1 e --flush-privileges.

    Importante: non includere il --set-gtid-purged=OFF flag.

    Scopri di più.

  3. Assicurati che il file di dump appena creato contenga SET @@GLOBAL.GTID_PURGED='...' riga.
  4. Carica il file dump in un bucket Cloud Storage e configura la replica utilizzando il file dump.

Bandiere

Problema Risoluzione dei problemi

Alta disponibilità

Problema Risoluzione dei problemi
Non puoi 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 dell'istanza della macchina è troppo piccola per il carico.

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
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 in corso.
L'operazione di importazione sta richiedendo troppo tempo. Troppe connessioni attive possono interferire con le operazioni di importazione.

Chiudi le operazioni non utilizzate. Controlla l'utilizzo di CPU e memoria del tuo Cloud SQL per verificare che sono disponibili numerose risorse. Il modo migliore per garantire le risorse massime 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 andare a buon fine se 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 sono proprietari di 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 il file oggetti con la proprietà o le autorizzazioni originali.

Crea gli utenti del database prima dell'importazione.
Un'operazione di importazione non riesce con un errore che indica che una tabella non esiste. Le tabelle possono avere dipendenze di chiavi esterne su altre tabelle e, a seconda dell'ordine delle operazioni, una o più tabelle potrebbero non esistere ancora durante l'operazione di importazione.

Tentativi da effettuare

Aggiungi la seguente riga all'inizio del file di dump:

SET FOREIGN_KEY_CHECKS=0;

Inoltre, aggiungi questa riga alla fine del file di dump:

SET FOREIGN_KEY_CHECKS=1;

Queste impostazioni disattivano i controlli sull'integrità dei dati durante l'importazione sia in corso e riattivale dopo aver caricato i dati. Questo non influisce sull'integrità dei dati contenuti nel database, perché questi erano è già stata convalidata durante la creazione del file di dump.

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 Esegui l'upgrade della versione principale del database in loco.
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 dedicati. 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 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 ulteriori informazioni sull'aggiunta di queste autorizzazioni all'account di servizio, consulta Attivare 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. L'endpoint Vertex AI non è formattato correttamente. 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.

Server collegati

Messaggio di errore Risoluzione dei problemi
Msg 7411, Level 16, State 1, Line 25

Server 'LINKED_SERVER_NAME' is not configured for DATA ACCESS. 		L'opzione DataAccess è disattivata. Esegui l' questo comando per abilitare l'accesso ai dati:
EXEC sp_serveroption
    @server='LINKED_SERVER_NAME',
    @optname='data access',
    @optvalue='TRUE'

Sostituisci LINKED_SERVER_NAME con il nome del server collegato.

Access to the remote server is denied because no login-mapping exists. (Microsoft SQL Server, Error: 7416) Se si verifica questo problema durante l'impostazione di una connessione criptata, devi provare un altro modo per fornire l'ID utente quando accedi al server collegato. Per farlo, esegui il seguente comando: 
EXEC master.dbo.sp_addlinkedserver
   @server = N'LINKED_SERVER_NAME',
   @srvproduct= N'',
   @provider= N'SQLNCLI',
   @datasrc= N'TARGET_SERVER_ID',
   @provstr= N'Encrypt=yes;TrustServerCertificate=yes;User ID=USER_ID'

Sostituisci quanto segue:

  • LINKED_SERVER_NAME con il nome del server collegato.
  • TARGET_SERVER_ID con il nome del target o l'indirizzo IP e il numero di porta del server di destinazione.
  • USER_ID con l'utente che accede.

Logging

Problema Risoluzione dei problemi
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.
Alcuni log vengono filtrati dal log error.log di un'istanza Cloud SQL per SQL Server. I log filtrati includono Log di AD senza timestamp e includono: Login failed for user 'x'. Reason: Token-based server access validation failed with an infrastructure error. Login lacks connect endpoint permission. [CLIENT: 127.0.0.1]. Questi log sono filtrati perché possono causare confusione.
La registrazione utilizza molto spazio su disco. Esistono tre tipi di file di log che utilizzano spazio su disco: log di ripetizione, log generali e log binari.

Connettiti al database ed esegui questi comandi per i dettagli su ciascun tipo:

SHOW VARIABLES LIKE 'innodb_log_file%';

SELECT ROUND(SUM(LENGTH(argument)/POW(1024,2),2)
AS GB from mysql.general_log;

SHOW BINARY LOGS;
I file di log sono difficili da leggere. Preferisci visualizzare i log come file JSON o di testo. Puoi utilizzare il gcloud logging read comando 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 vengono trovati nei log di 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
Prestazioni lente dopo il riavvio di MySQL. Cloud SQL consente la memorizzazione nella cache dei dati nel pool di buffer InnoDB. Tuttavia, dopo un riavvio, questa cache è sempre vuota e tutte le letture richiedono un round trip al backend per recuperare i dati. Di conseguenza, le query possono essere più lente del previsto fino a quando la cache non viene riempita.
Ripristino lento in caso di arresto anomalo. Potrebbe essersi accumulato un volume elevato di general_log. Puoi ridurre i tempi di ripristino in seguito a un arresto anomalo impedendo un general_log dall'accumulo. Se general_log è attivo, tronca la tabella e attiva general_log solo per brevi periodi di tempo.

Puoi scoprire le dimensioni dei log generali connettendoti al ed eseguendo questa query:

SELECT ROUND(SUM(LENGTH(argument)/POW(1024,2)),2) from mysql.general_log;
Vuoi scoprire cosa sta utilizzando lo spazio di archiviazione. Ad esempio, noti che il tuo database utilizza solo 3 GB, ma lo spazio di archiviazione indica che vengono utilizzati 14 GB. La maggior parte dello spazio non utilizzato dalle tabelle è utilizzato dai log binari e/o dai file temporanei.

Tentativi da effettuare

  • Puoi verificare lo spazio di archiviazione occupato dai log binari utilizzando: nell'interfaccia a riga di comando di MySQL: SHOW BINARY LOGS;
  • Anche le tabelle temporanee possono occupare una quantità significativa di di archiviazione. Per controllare l'utilizzo temporaneo dello spazio, usa seguente comando: SELECT * FROM INFORMATION_SCHEMA.FILES WHERE TABLESPACE_NAME='innodb_temporary'\G.
  • Il seguente comando consente di controllare le dimensioni del log di ripristino: SHOW VARIABLES LIKE 'innodb_log_file%';
  • Puoi controllare la dimensione di general_log, se è con l'aiuto di questo comando: SELECT ROUND(SUM(LENGTH(argument)/POW(1024,2)),2) AS GB from mysql.general_log;
  • Se necessario, puoi troncare le tabelle dei log utilizzando l'API. Per ulteriori informazioni, consulta la pagina di riferimento di instances.truncateLog.
  • Scopri di più su come impostare e configurare i log delle query lente.
Le query sono bloccate. È possibile che le query blocchino il database MySQL, causando il blocco/il timeout di tutte le query successive.

Connettiti al database ed esegui questa query:

SHOW PROCESSLIST.

La prima voce dell'elenco potrebbe essere quella che contiene il blocco, che gli elementi successivi sono in attesa.

Può essere utile anche la query SHOW INNODB STATUS.
Non puoi eliminare manualmente i log binari. I log binari non possono essere eliminati manualmente. I log binari vengono eliminati automaticamente con il backup automatico associato, in genere dopo circa sette giorni.
Vuoi trovare informazioni sui file temporanei. Per l'archiviazione temporanea viene utilizzato un file denominato ibtmp1 e i dati di Google Cloud. Questo file viene reimpostato al riavvio del database. Per trovare informazioni su l'utilizzo temporaneo dei file, la connessione al database esegui questa query:

SELECT * FROM INFORMATION_SCHEMA.FILES WHERE TABLESPACE_NAME='innodb_temporary'\G
Vuoi scoprire le dimensioni delle tabelle. Queste informazioni sono disponibili nel database.

Connettiti al database ed esegui la seguente query:

SELECT TABLE_SCHEMA, TABLE_NAME, sum(DATA_LENGTH+INDEX_LENGTH)/pow(1024,2) FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA NOT IN ('PERFORMANCE_SCHEMA','INFORMATION_SCHEMA','SYS','MYSQL') GROUP BY TABLE_SCHEMA, TABLE_NAME;
mysqld ha ricevuto un segnale 11. Prova a eseguire il refactoring delle query in modo che non creino troppe connessioni. Se il problema persiste, contatta l'assistenza clienti. L'indicatore 11 di solito indica un problema del software MySQL.

InnoDB: page_cleaner: 1000ms intended loop took 5215ms. The settings might not be optimal. Lo strumento per la pulizia delle pagine non è in grado di tenere il passo con la frequenza di modifica dell'istanza. Una volta al secondo, il servizio di pulizia pagine scansiona il pool di buffer per individuare le pagine "sporche" eseguire il flush del pool di buffer sul disco. L'avviso che vedi indica che ci sono molte pagine sporche da svuotare e che l'operazione richiede più di un secondo per svuotare un batch sul disco.

Esegui lo sharding dell'istanza se possibile. È preferibile utilizzare molte istanze Cloud SQL di piccole dimensioni anziché un'unica istanza di grandi dimensioni.
Vuoi sapere 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 questa query (con il tuo FIELD_NAME):

SELECT name, setting, unit FROM pg_settings WHERE name = 'FIELD_NAME'.
Vuoi trovare il valore corrente di un'impostazione del 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 processo 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 dovute a problemi di wraparound delle transazioni, puoi rivedere questi suggerimenti per il self-service per gestire il wraparound di 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. 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.
È in corso l'eliminazione automatica dei dati. È molto probabile che uno script sia 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.
L'istanza non può essere eliminata. 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 avere uno stato di indicatore INSTANCE_RISKY_FLAG_CONFIG.

Ecco alcune possibili spiegazioni:

  • È in corso un'altra operazione. Le operazioni Cloud SQL non vengono eseguite 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 le query e il 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 archiviato in spazi delle tabelle file per tabella nella directory dei file temporanei. Tuttavia, il rovescio della medaglia è rappresentato dai costi in termini di prestazioni associati alla creazione e alla rimozione di un tablespace file per tabella per ogni tabella temporanea.
Errore irreversibile durante l'upgrade. I log possono rivelare di più, ma in ogni caso assistenza clienti potrebbe essere necessaria per forzare la 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 l'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 non in Cloud SQL.
Arresto lento al riavvio. Quando un'istanza viene arrestata, eventuali connessioni in sospeso che non terminano entro 60 secondi rendono l'arresto non corretto.

Avendo connessioni che durano meno di 60 secondi, è possibile evitare la maggior parte degli arresti anomali, incluse le connessioni dal prompt dei comandi del database. Se mantieni queste connessioni aperte per ore o giorni, gli arresti anomali possono non essere corretti.
Impossibile eliminare un utente. L'utente ha probabilmente oggetti nel database che dipendono da questo. Devi eliminare questi oggetti o riassegnareli a un altro utente.

Scopri quali oggetti dipendono dall'utente, poi rilasciali o riassegnali per questi oggetti a un altro utente.
Alcune query sono lente. Le query possono essere lente per molti motivi, principalmente a causa di database specifici aspetti. Uno dei motivi che può influire su Cloud SQL è la latenza di rete, quando la risorsa di origine (autore o lettore) e la destinazione (Cloud SQL) si trovano in regioni diverse.

Consulta consigli generali per le prestazioni.

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

  • Controlla le posizioni dello scrittore e del database. L'invio di dati su lunghe distanze 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, ti consigliamo di posizionare le risorse di origine e 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 valori non vengono sempre riportati 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 di un'istanza, inclusi i backup, andranno persi definitivamente quando l'istanza viene eliminata.

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 impedire 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. In questo modo, puoi creare la nuova istanza senza dover importare manualmente i dati. 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 al termine dell'operazione. 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 del 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 contenente l'endpoint
    • REGION_NAME: il nome della regione per l'endpoint

    REST

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

    • PROJECT_ID: l'ID o il numero di progetto del progetto Google Cloud contenente 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 che contiene l'endpoint. Assicurati che il progetto di rete in cui è stato creato l'endpoint sia consentito. Per ulteriori informazioni, 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 trattarsi di un flag fornito esplicitamente o di un flag impostato su un valore predefinito.

Innanzitutto, controlla 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 è presente 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, disattiva e riattiva Service Networking API. Questa azione crea l'account di servizio necessario per continuare la procedura.
Lo spazio sul disco è esaurito. Le dimensioni del disco dell'istanza principale possono esaurirsi durante la creazione della replica. Modifica l'istanza principale per eseguirne l'upgrade a una dimensione del disco maggiore.
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 di replica per recuperare lo spazio di memoria temporaneo.
La replica è stata interrotta. È stato raggiunto il limite di spazio di archiviazione massimo e l'aumento automatico dello spazio di archiviazione non è abilitato.

Modifica l'istanza per abilitare automatic storage increase.
Il ritardo nella replica è costantemente elevato. Il carico di scrittura è troppo elevato per essere gestito dalla replica. Il ritardo nella replica si verifica quando il thread SQL su una replica non è in grado di stare al passo con il thread I/O. Alcuni tipi di query o carichi di lavoro possono causare un ritardo elevato della replica temporaneo o permanente per un determinato schema. Alcuni dei tipici Le cause del ritardo di replica sono:
  • Query lente sulla replica. Trovale e correggile.
  • Tutte le tabelle devono avere una chiave univoca/primaria. Ogni aggiornamento su senza una chiave univoca/primaria causa scansioni complete della tabella replica.
  • Query come DELETE ... WHERE field < 50000000 causano un ritardo nella replica con la replica basata su righe, poiché un numero enorme di aggiornamenti si accumula nella 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.
La creazione della replica non riesce con il 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.