Risoluzione dei problemi

Controlla se la tua domanda o il tuo problema è già stato trattato in una delle pagine seguenti:

Gli argomenti trattati in questa pagina includono:

Backup e ripristino

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

  • cloudsql.googlapis.com/mysql-general.log
  • cloudsql.googleapis.com/mysql.err
  • Se Cloud Audit Logs è abilitato e disponi delle autorizzazioni necessarie per visualizzarli, potrebbe essere disponibile anche cloudaudit.googleapis.com/activity.
Una volta eliminata un'istanza, non puoi eseguirne il backup.

Se elimini un'istanza senza eseguire un backup finale dei dati, non è possibile alcun recupero dei dati. Tuttavia, se ripristini l'istanza, Cloud SQL ripristina anche i backup. Per ulteriori informazioni sul recupero di un'istanza eliminata, consulta Backup di recupero.

Se hai eseguito un'operazione di esportazione, crea una nuova istanza e poi 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 da molte ore e non può essere annullato. I backup possono richiedere molto tempo, a seconda delle dimensioni del database.

Se hai davvero bisogno di annullare l'operazione, puoi chiedere all' assistenza clienti di force restart l'istanza.
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 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 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 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 backup automatici 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 vengono conservati per un periodo di tempo indefinito. ovvero rimangono finché non vengono eliminati o finché 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 è andato a buon fine 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 sui log.

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 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 l'assistenzaGoogle Cloud .

Clona

Problema Risoluzione dei problemi
La clonazione non riesce a causa dell'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 a causa di considerazioni di sicurezza.

Se possibile, rimuovi tutte le voci Authorized Networks dall'istanza Cloud SQL. 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 Clonazione di un'istanza con un IP privato.

Connetti

Problema Risoluzione dei problemi
Aborted connection. Il problema potrebbe essere:
  • Instabilità Networking.
  • Nessuna risposta ai comandi TCP keep-alive (il client o il server non risponde, probabilmente è sovraccarico)
  • Il lifetime della connessione motore del database è stato superato 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 nuovi tentativi. La maggior parte dei pool di connessioni rileva questi errori, se possibile. In caso contrario, l'applicazione deve riprovare o non riuscire in modo controllato.

Per il nuovo tentativo di connessione, ti consigliamo i seguenti metodi:

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

La combinazione di questi metodi contribuisce a ridurre la limitazione.
Certificate verify failed.

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

Rigenera i certificati ricreandoli.

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. Possono verificarsi diversi scenari possibili:

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

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

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

Se stai allocando un nuovo intervallo, assicurati che l'allocazione non si sovrapponga ad allocazioni esistenti.

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, fai attenzione ad aumentare solo l'intervallo di allocazione e non a diminuirlo. Ad esempio, se l'allocazione originale era 10.0.10.0/24, la nuova allocazione deve essere almeno 10.0.10.0/23.

In generale, se si parte da un'allocazione /24, diminuire la maschera di 1 per ogni condizione (gruppo di tipi di istanza aggiuntivo, regione aggiuntiva) è una buona regola pratica. Ad esempio, se provi a creare entrambi i gruppi di tipi di istanza nella 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: HTTPError 400: Invalid request: Incorrect Service Networking config for instance: PROJECT_ID:INSTANCE_NAME:SERVICE_NETWORKING_NOT_ENABLED.

Abilita l'API Service Networking utilizzando il comando seguente e prova a creare di nuovo l'istanza Cloud SQL.

gcloud services enable servicenetworking.googleapis.com \
--project=PROJECT_ID
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 service account just-in-time utilizzando l'API Service Networking. Se hai abilitato di recente l'API Service Networking, il account di servizio potrebbe non essere creato e la creazione dell'istanza non riesce. In questo caso, devi attendere che il account di servizio si propaghi in tutto il sistema o aggiungerlo manualmente con le autorizzazioni richieste.
Messaggio di errore: More than 3 subject alternative names are not allowed. Stai tentando di utilizzare un nome comune del soggetto personalizzato per aggiungere più di tre nomi DNS al certificato del server di un'istanza Cloud SQL. Non puoi aggiungere più di tre nomi DNS all'istanza.
Messaggio di errore: Subject alternative names %s is too long. The maximum length is 253 characters. Assicurati che i nomi DNS che vuoi aggiungere al certificato del server di un'istanza Cloud SQL non superino i 253 caratteri.
Messaggio di errore: Subject alternative name %s is invalid.

Verifica che i nomi DNS che vuoi aggiungere al certificato del server di un'istanza Cloud SQL soddisfino i seguenti criteri:

  • Non contengono caratteri jolly.
  • Non hanno punti finali.
  • Soddisfano le specifiche RFC 1034.

Esporta

Problema Risoluzione dei problemi
HTTP Error 409: Operation failed because another operation was already in progress. Esiste già un'operazione in attesa per la tua istanza. È consentita una sola operazione alla volta. Prova a eseguire la richiesta dopo il completamento 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 il account di servizio dell'istanza Cloud SQL (che esegue l'esportazione) disponga del ruolo Storage Object Creator (roles/storage.objectCreator) per consentire l'esportazione nel bucket. Vedi Ruoli IAM per Cloud Storage.
L'esportazione CSV è andata a buon fine, 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 essere completato. Il formato CSV ti consente di definire quali elementi del database includere nell'esportazione.

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

Utilizza il trasferimento dell'esportazione. A livello generale, nel trasferimento dell'esportazione, anziché eseguire un'esportazione sull'istanza di origine, Cloud SQL avvia un'istanza di trasferimento per eseguire l'esportazione. L'offload dell'esportazione presenta diversi vantaggi, tra cui un aumento del rendimento dell'istanza di origine e lo sblocco delle operazioni amministrative durante l'esecuzione dell'esportazione. Con il trasferimento del carico di esportazione, la latenza totale può aumentare del tempo necessario per avviare l'istanza di offload. In genere, per le esportazioni di dimensioni ragionevoli, la latenza non è significativa. Tuttavia, se l'esportazione è sufficientemente piccola, potresti notare l'aumento della latenza.
Vuoi che le esportazioni siano automatizzate. Cloud SQL non fornisce un modo per automatizzare le esportazioni.

Puoi creare il tuo sistema di esportazione automatizzato utilizzando prodotti come Cloud Scheduler, Pub/Sub e Cloud Run Functions, in modo simile a questo articolo sull' automazione dei backup. Google Cloud

Principale esterno

Problema Risoluzione dei problemi
Lost connection to MySQL server during query when dumping table. La fonte potrebbe non essere più disponibile o il dump conteneva pacchetti troppo grandi.

Assicurati che la primaria esterna sia disponibile per la connessione. Puoi anche modificare i valori dei flag net_read_timeout e net_write_timeout nell'istanza di origine per interrompere l'errore. Per ulteriori informazioni sui valori consentiti per questi flag, consulta la pagina Configurare i flag di database.

Per scoprire di più sull'utilizzo dei flag mysqldump per la migrazione dell'importazione gestita, vedi Flag di sincronizzazione iniziale consentiti e predefiniti
La migrazione iniziale dei dati è stata completata, ma non vengono replicati dati. Una possibile causa principale potrebbe essere che il database di origine ha definito flag di replica che comportano la mancata 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 siano impostati in modo conflittuale.

Esegui il comando show master status sull'istanza primaria per visualizzare le impostazioni correnti.
La migrazione iniziale dei dati è stata completata, ma la replica dei dati smette di funzionare dopo un po' di tempo. Tentativi da effettuare

  • Controlla le metriche di replica per l'istanza di replica nella sezione Cloud Monitoring della console Google Cloud .
  • Gli errori del thread I/O o SQL di MySQL sono disponibili in Cloud Logging nei file mysql.err log.
  • L'errore può essere rilevato anche durante la connessione all'istanza di replica. Esegui il comando SHOW SLAVE STATUS e controlla i seguenti campi nell'output:
    • 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 le dimensioni del disco dell'istanza di 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 dispone di backup automatici e log binari e il recupero point-in-time è abilitato, quindi dovrebbe avere log sufficienti per consentire alla replica di recuperare. Tuttavia, in questo caso, anche se i log binari esistono, la replica non sa da quale riga iniziare a leggere.

Crea un nuovo file di dump utilizzando le impostazioni dei 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 la riga SET @@GLOBAL.GTID_PURGED='...'.
  4. Carica il file di dump in un bucket Cloud Storage e configura la replica utilizzando il file di dump.

Bandiere

Problema Risoluzione dei problemi
Dopo aver attivato un flag, l'istanza esegue un loop tra panico e arresto anomalo. Contatta l' assistenza clienti per richiedere la rimozione del flag seguita da un hard drain. In questo modo, l'istanza viene riavviata su un host diverso con una nuova configurazione senza il flag o l'impostazione indesiderati.
Visualizzi il messaggio di errore Bad syntax for dict arg quando provi a impostare un flag. I valori dei parametri complessi, come gli elenchi separati da virgole, richiedono un trattamento speciale se utilizzati con i comandi gcloud.

Alta disponibilità

Problema Risoluzione dei problemi
Non riesci a trovare le metriche per un failover manuale. Nelle metriche vengono conteggiati solo i failover automatici.
Le risorse dell'istanza Cloud SQL (CPU e RAM) sono vicine al 100% di utilizzo, il che causa l'interruzione 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 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 la tua istanza. È consentita una sola operazione alla volta. Prova a eseguire la richiesta dopo il completamento dell'operazione attuale.
L'operazione di importazione sta richiedendo troppo tempo. Un numero eccessivo di connessioni attive può interferire con le operazioni di importazione.

Chiudi le operazioni non utilizzate. Controlla l'utilizzo di CPU e memoria della tua istanza Cloud SQL per assicurarti che ci siano molte risorse disponibili. 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 tutte le attività che potrebbero consumare risorse.
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 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 gli oggetti con la proprietà o le autorizzazioni originali.

Crea gli utenti del database prima dell'importazione.
Un'operazione di importazione non riesce e viene visualizzato un errore che indica che una tabella non esiste. Le tabelle possono avere dipendenze di chiave esterna 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 di integrità dei dati durante l'importazione e li riattivano dopo il caricamento dei dati. Ciò non influisce sull'integrità dei dati nel database, perché i dati sono già stati convalidati durante la creazione del file di dump.

Logging

Problema Risoluzione dei problemi
Audit log non trovati. I log di accesso ai dati vengono scritti solo se l'operazione è una chiamata API autenticata guidata dall'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.
Le informazioni sulle operazioni non sono presenti nei log. Vuoi trovare maggiori informazioni su un'operazione.

Ad esempio, un utente è stato eliminato, ma non riesci a scoprire chi lo ha fatto. I log mostrano l'operazione iniziata, ma non forniscono ulteriori informazioni. Devi attivare la registrazione degli audit per registrare informazioni dettagliate e di identificazione personale (PII) come queste.
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 visualizzare i dettagli di ogni 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 in formato JSON o testo.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 come file di 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

Gestisci le 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 ottenere i dati. Di conseguenza, le query possono essere più lente del previsto finché la cache non viene riempita.
Ripristino lento in caso di arresto anomalo. Potrebbe essersi accumulato un grande general_log. Puoi ridurre il tempo di ripristino in caso di arresto anomalo impedendo l'accumulo di un grande general_log. Se hai attivato general_log, tronca la tabella e attiva general_log solo per brevi periodi di tempo.

Per scoprire le dimensioni dei log generali, connettiti al database ed esegui questa query:

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

Tentativi da effettuare

  • Puoi controllare lo spazio di archiviazione occupato dai log binari utilizzando il seguente comando nell'interfaccia a riga di comando MySQL: SHOW BINARY LOGS;
  • Anche le tabelle temporanee potrebbero occupare una quantità significativa di spazio di archiviazione. Per controllare l'utilizzo dello spazio temporaneo, utilizza il comando seguente: 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 le dimensioni di general_log, se è abilitato, 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 instances.truncateLog.
  • Scopri di più sulla configurazione e sulla configurazione dei log delle query lente.
Le query sono bloccate. È possibile che le query blocchino il database MySQL causando il blocco/timeout di tutte le query successive.

Connettiti al database ed esegui questa query:

SHOW PROCESSLIST.

Il primo elemento dell'elenco potrebbe essere quello che contiene il blocco, che gli elementi successivi stanno aspettando.

Anche la query SHOW INNODB STATUS può essere utile.
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, il che in genere avviene dopo circa sette giorni.
Vuoi trovare informazioni sui file temporanei. Un file denominato ibtmp1 viene utilizzato per archiviare dati temporanei. Questo file viene reimpostato al riavvio del database. Per trovare informazioni sull'utilizzo dei file temporanei, connettiti al database ed esegui la seguente 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 il supporto clienti. Il segnale 11 di solito rappresenta un problema del software MySQL.

InnoDB: page_cleaner: 1000ms intended loop took 5215ms. The settings might not be optimal. Il pulitore di pagine non riesce a tenere il passo con la velocità di modifica dell'istanza. Una volta al secondo, il pulitore di pagine esegue la scansione del pool di buffer alla ricerca di pagine sporche da scaricare dal pool di buffer sul disco. L'avviso che vedi indica che ci sono molte pagine sporche da svuotare e che ci vuole più di un secondo per svuotare un batch di pagine sul disco.

Esegui lo sharding dell'istanza se possibile. L'utilizzo di molte istanze Cloud SQL più piccole è meglio di una grande istanza.
L'archiviazione temporanea ha aumentato l'archiviazione automatica. L'archiviazione automatica è attivata.

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 non autorizzato da una dashboard o da un altro processo automatizzato.
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 o l'istanza potrebbe avere lo stato del flag INSTANCE_RISKY_FLAG_CONFIG.

Alcune possibili spiegazioni includono:

  • È in corso un'altra operazione. Le operazioni Cloud SQL non vengono eseguite contemporaneamente. Attendi il completamento dell'altra operazione.
  • L'avviso INSTANCE_RISKY_FLAG_CONFIG viene attivato ogni volta che viene utilizzato almeno un flag beta. Rimuovi le impostazioni dei flag rischiosi e riavvia l'istanza
L'istanza è bloccata a causa delle grandi dimensioni dei 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 metodo diverso dal riavvio del servizio.

Un'opzione di mitigazione è creare la tabella temporanea con ROW_FORMAT=COMPRESSED, in modo che venga archiviata negli spazi delle tabelle file per tabella nella directory dei file temporanei. Tuttavia, lo svantaggio è rappresentato dai costi di prestazioni associati alla creazione e alla rimozione di uno spazio delle tabelle file-per-table per ogni tabella temporanea.
Errore irreversibile durante l'upgrade. I log potrebbero rivelare ulteriori informazioni, ma in ogni caso potrebbe essere necessario l'assistenza clienti per forzare la ricreazione dell'istanza.
L'istanza è bloccata al riavvio dopo l'esaurimento dello spazio su disco. La funzionalità di aumento automatico dello spazio di archiviazione non è abilitata.

Se lo spazio di archiviazione dell'istanza si esaurisce e la funzionalità di aumento automatico dello spazio di archiviazione non è abilitata, l'istanza va offline. Per evitare questo problema, puoi modificare l'istanza per abilitare l'aumento automatico dello spazio di archiviazione.
La tua istanza principale on-premise è bloccata. Google Cloud non può aiutarti con le istanze che non si trovano in Cloud SQL.
Arresto lento al riavvio. Quando un'istanza si arresta, tutte le connessioni in sospeso che non terminano entro 60 secondi rendono l'arresto non pulito.

Se le connessioni durano meno di 60 secondi, è possibile evitare la maggior parte degli arresti anomali, incluse le connessioni dal prompt dei comandi del database. Se mantieni aperte queste connessioni per ore o giorni, gli spegnimenti possono essere non puliti.
Un utente non può essere eliminato. Probabilmente l'utente ha oggetti nel database che dipendono da questo ruolo. Devi eliminare questi oggetti o riassegnarli a un altro utente.

Scopri quali oggetti dipendono dall'utente, quindi eliminali o riassegnali a un altro utente.

Questo articolo spiega come trovare gli oggetti di proprietà dell'utente.
Determinate query vengono eseguite lentamente. 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 (scrittore 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 del database, valuta le seguenti azioni:

  • Se abiliti il flag long_query_time, puoi controllare i log per le query lente. Vai alla pagina Esplora log del tuo progetto ed esegui una query come questa: 
    resource.type="cloudsql_database"
resource.labels.database_id="INSTANCE-ID"
log_name="projects/PROJECT-ID/logs/cloudsql.googleapis.com%2Fmysql-slow.log"

    Puoi scaricare i log in formato JSON o TEXT per l'elaborazione locale.

  • Controlla le posizioni del writer e del database. L'invio di dati a lunga distanza introduce latenza.
  • Controlla la posizione del lettore e del database. La latenza influisce sulle prestazioni di lettura ancora più di quelle di scrittura.

Per ridurre la latenza, ti consigliamo di individuare le risorse di origine e di destinazione nella stessa regione.
Viene indicato che la memoria è piena, ma i grafici di monitoraggio non lo mostrano. Un'istanza può non riuscire e segnalare Out of memory, ma i grafici della console Google Cloud o di Cloud Monitoring sembrano mostrare che è ancora disponibile memoria.

Oltre al carico di lavoro, esistono altri fattori che possono influire sull'utilizzo della memoria, ad esempio il numero di connessioni attive e i processi di overhead interni. Questi valori non sempre vengono visualizzati nei grafici di monitoraggio.

Assicurati che l'istanza abbia un overhead sufficiente per tenere conto del carico di lavoro più un overhead aggiuntivo.
Recupero di un'istanza eliminata. Tutti i dati di 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 Cloud SQL Admin include l'autorizzazione per eliminare l'istanza. Per evitare eliminazioni accidentali, assegna 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. Proprio come quando crei una nuova istanza, l'istanza clonata ha un nuovo indirizzo IP.
  • Puoi esportare i dati dall'istanza in un bucket Cloud Storage, creare una nuova istanza con il nuovo nome che preferisci e poi importare i dati nella nuova istanza.

In entrambi i casi, puoi eliminare la vecchia istanza al termine dell'operazione. Ti consigliamo di scegliere la clonazione, in quanto non influisce sulle prestazioni e non richiede di ripetere 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 l'intenzione di eliminarla. Poi disattiva 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 che contiene 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 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 che contiene l'endpoint. Assicurati che il progetto di rete in cui viene creato l'endpoint sia consentito. Per ulteriori informazioni, consulta Modificare un'istanza con Private Service Connect abilitato.
ERROR: (gcloud.compute.forwarding-rules.create) Could not fetch resource: The resource 'projects/PROJECT_ID/regions/REGION/subnetworks/SUBNET_NAME' was not found Questo messaggio di errore può verificarsi quando si riserva un indirizzo IP interno statico per l'endpoint Private Service Connect. Assicurati che la subnet specificata esista nel progetto specificato dall'URI. Se vuoi creare un endpoint in un progetto di servizio, ma utilizzare una subnet da una rete VPC condiviso, devi specificare la subnet tramite il relativo URI e utilizzare l'ID progetto del progetto host nell'URI. Per saperne di più, consulta Creare l'endpoint manualmente.
ERROR: (gcloud.compute.forwarding-rules.create) Could not fetch resource: - The resource 'projects/PROJECT_ID/global/networks/NETWORK_NAME' was not found Questo messaggio di errore può verificarsi quando crei manualmente un endpoint Private Service Connect. Assicurati che la rete specificata esista nel progetto specificato dall'URI. Se vuoi creare un endpoint in un progetto di servizio, ma utilizzare una rete VPC condiviso, devi specificare la rete tramite il relativo URI e utilizzare l'ID progetto del progetto host nell'URI. Per saperne di più, consulta Creare l'endpoint manualmente.

Replica

Problema Risoluzione dei problemi
La replica di lettura non ha iniziato la replica al momento della creazione. Probabilmente nei file di log è presente un errore più specifico. Ispeziona 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 che hai fornito esplicitamente o di 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 nei file di log è presente un errore più specifico. Ispeziona 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 il account di servizio necessario per continuare la procedura.
Lo spazio sul disco è esaurito. La dimensione del disco dell'istanza principale può esaurirsi durante la creazione della replica. Modifica l'istanza principale per eseguire l'upgrade a una dimensione del disco maggiore.
L'istanza di replica utilizza troppa memoria. La replica utilizza la memoria temporanea per memorizzare nella cache le operazioni di lettura richieste di frequente, il che può portare a un utilizzo di memoria superiore rispetto all'istanza principale.

Riavvia l'istanza di replica per recuperare lo spazio di memoria temporaneo.
La replica è stata 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 automatic storage increase.
Il ritardo di replica è costantemente elevato. Il carico di scrittura è troppo elevato per la replica. Il ritardo di replica si verifica quando il thread SQL su una replica non riesce a tenere il passo con il thread I/O. 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 tipiche del ritardo della replica sono:
  • Query lente sulla replica. Trova e correggi gli errori.
  • Tutte le tabelle devono avere una chiave univoca/primaria. Ogni aggiornamento di una tabella senza una chiave univoca/primaria causa scansioni complete della tabella sulla replica.
  • Query come DELETE ... WHERE field < 50000000 causano un ritardo della replica con la replica basata su righe, poiché un numero elevato di aggiornamenti si accumula nella replica.

Alcune possibili soluzioni includono:
Il ritardo della replica aumenta improvvisamente. Ciò è dovuto a una o più transazioni a lunga esecuzione. Quando una transazione (singola istruzione o più istruzioni) viene eseguita nell'istanza di origine, l'ora di inizio della transazione viene registrata nel log binario. Quando la replica riceve questo evento binlog, confronta il timestamp con il timestamp corrente per calcolare il ritardo di replica. Pertanto, una transazione a lunga esecuzione sull'origine comporterebbe un ritardo di replica immediato e di grandi dimensioni sulla replica. Se la quantità di modifiche alle righe nella transazione è elevata, anche la replica impiegherà molto tempo per eseguirla. Durante il periodo di tempo, il ritardo della replica aumenta. Una volta completata questa transazione, il periodo di recupero dipenderà dal carico di lavoro di scrittura sull'origine e dalla velocità di elaborazione della replica.

Per evitare una transazione lunga, alcune possibili soluzioni includono:

  • Suddividi la transazione in più transazioni di piccole dimensioni
  • Dividi una singola query di scrittura di grandi dimensioni in batch più piccoli
  • Prova a separare le query SELECT lunghe da una transazione mista con DML
La modifica dei flag di replica parallela genera un errore. È stato impostato un valore errato per uno o più di questi flag.

Nell'istanza principale che mostra il messaggio di errore, imposta i flag di replica parallela:

  1. Modifica i flag binlog_transaction_dependency_tracking e transaction_write_set_extraction:
    • binlog_transaction_dependency_tracking=COMMIT_ORDER
    • transaction_write_set_extraction=OFF
  2. Aggiungi il flag slave_pending_jobs_size_max:

    slave_pending_jobs_size_max=33554432

  3. Modifica il flag transaction_write_set_extraction:

    transaction_write_set_extraction=XXHASH64

  4. Modifica il flag binlog_transaction_dependency_tracking:

    binlog_transaction_dependency_tracking=WRITESET
La creazione della replica non riesce a causa del timeout. Le transazioni non sottoposte a commit a esecuzione prolungata sull'istanza principale possono causare la mancata creazione della replica di lettura.

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