Risoluzione dei problemi

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

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

Gli argomenti di questa pagina includono:

Backup e ripristino

Problema Risolvere i problemi
Non puoi vedere lo stato dell'operazione corrente. Google Cloud Console segnala un esito positivo o negativo soltanto 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 scoprire chi ha eseguito 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. Per informazioni private, potrebbe essere necessario utilizzare gli audit log. 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, possono essere disponibili anche cloudaudit.googleapis.com/activity.
Non puoi eseguire un backup dopo aver eliminato un'istanza. Il periodo di tolleranza per l'eliminazione definitiva di un'istanza Cloud SQL è di quattro giorni, ad eccezione delle repliche di lettura, che vengono eliminate definitivamente. Durante questo periodo, l'assistenza clienti può ricreare l'istanza. Se l'istanza viene ricreata, vengono ricreati anche i relativi backup. Dopo l'eliminazione definitiva delle istanze, non è possibile recuperare i dati.

Se hai eseguito un'operazione di esportazione, puoi creare una nuova istanza e quindi eseguire un'operazione di importazione per ricreare il database. Le esportazioni vengono scritte in Cloud Storage e da lì vengono lette.

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 hai la necessità 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 dispongono di oggetti o di cui sono state concesse autorizzazioni per gli oggetti nel database dumped 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 in cui puoi conservare i backup automatici da 7 a 30 giorni o più. Vengono conservati solo sette backup. I backup vengono eliminati regolarmente a causa del costo e delle dimensioni della conservazione. Purtroppo, questo significa che quelli 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, poiché non vengono eliminati con le stesse modalità dei backup automatici. I backup on demand rimangono a tempo indeterminato. Ciò significa che rimangono fino all'eliminazione o fino all'eliminazione dell'istanza a cui appartengono. Dato che questo tipo di backup non viene eliminato automaticamente, può influire sulla fatturazione.

Backup automatico non riuscito. Non hai ricevuto una notifica via email. Le notifiche non sono supportate per gli errori di backup.

Quando un backup automatico non riesce, viene visualizzato un messaggio Operation error nella pagina Details dell'istanza Cloud SQL.

Puoi trovare lo stato di un backup tramite l'API REST o i comandi gcloud. Ad esempio, elenca prima i backup per un'istanza, quindi descrivi un backup specifico in base al relativo ID:


gcloud sql backups list \
--project=PROJECT_ID \
--instance=INSTANCE_ID
   

gcloud sql backups describe BACKUP-ID \
--instance=INSTANCE_ID
    

Clona

Problema Risolvere i problemi
Clonazione non riuscita con errore constraints/sql.restrictAuthorizedNetworks. L'operazione di clonazione è bloccata dalla configurazione Authorized Networks. Gli indirizzi Authorized Networks sono configurati per gli indirizzi IP pubblici nella sezione Connettività di Google Cloud Console e la clonazione non è consentita a causa di considerazioni sulla 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 di
. Per saperne di più, consulta Clonazione di un'istanza con un IP privato.

Connetti

Problema Risolvere i problemi
Aborted connection. Il problema potrebbe essere:
  • Instabilità di rete.
  • Nessuna risposta ai comandi keep-alive TCP (il client o il server non è adattabile, potrebbe essere sovraccarico)
  • 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 pool di connessioni e i nuovi tentativi. La maggior parte dei pool di connessioni rileva questi errori ove possibile. In caso contrario, l'applicazione deve riprovare o non riuscire correttamente.

Per riprovare a eseguire la connessione, ti consigliamo i seguenti metodi:

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

La combinazione di questi metodi aiuta a ridurre le limitazioni.

Creare istanze

Problema Risolvere i problemi
Ricevi il 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 del servizio privato è inferiore a /24.
  • Le dimensioni dell'intervallo IP allocato per la connessione del servizio privato sono troppo piccole 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ù aree geografiche. Consulta la sezione Dimensioni intervallo assegnate.

Per ognuno degli scenari precedenti, puoi espandere l'intervallo IP allocato esistente o allocare un intervallo IP aggiuntivo alla connessione del servizio privato.

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 a eventuali 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, assicurati di aumentare solo l'intervallo di allocazione e non di ridurlo. Ad esempio, se l'allocazione originale era 10.0.10.0/24, esegui la nuova allocazione almeno 10.0.10.0/23.

In generale, se a partire da un'allocazione /24, la riduzione di /mask di 1 per ogni condizione (gruppo di tipi di istanze aggiuntive, regione aggiuntiva) è una buona regola generale. Ad esempio, se tenti di creare entrambi i gruppi di tipi di istanza sulla stessa allocazione, è sufficiente passare da /24 a /23.

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


gcloud services vpc-peerings update \
--service=servicenetworking.googleapis.com \
--ranges=RESERVED_RANGE_NAME \
--network=VPC_NETWORK \
--project=PROJECT_ID
    

Esportazione

Problema Risolvere i problemi
HTTP Error 409: Operation failed because another operation was already in progress. È già presente un'operazione in attesa per l'istanza. È consentita una sola operazione alla volta. Prova a eseguire la richiesta dopo il completamento dell'operazione in corso.
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 sta eseguendo l'esportazione) abbia il ruolo Storage Object Creator (roles/storage.objectCreator) per consentire l'esportazione nel bucket. Consulta Ruoli IAM per Cloud Storage.
L'esportazione CSV ha funzionato, 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 è necessario più tempo per il completamento. Il formato CSV consente di definire gli elementi del database da 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 l'esportazione offload. A livello generale, nell'offload delle esportazioni, invece di eseguire un'esportazione sull'istanza di origine, Cloud SQL avvia un'istanza di offload per eseguire l'esportazione. L'offload delle esportazioni presenta numerosi vantaggi, tra cui l'aumento delle prestazioni nell'istanza di origine e lo sblocco delle operazioni amministrative mentre l'esportazione è in esecuzione. Con l'offload delle esportazioni, la latenza totale può aumentare del tempo necessario per visualizzare l'istanza di offload. In genere, per le esportazioni di dimensioni ragionevoli, la latenza non è significativa. Tuttavia, se le tue esportazioni sono sufficientemente piccole, potresti notare un aumento della latenza.

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

Puoi creare un tuo sistema di esportazione automatizzato utilizzando prodotti Google Cloud come Cloud Scheduler, Pub/Sub e Cloud Functions, in modo simile a questo articolo su come automatizzare i backup.

Primario esterno

Problema Risolvere i problemi
Lost connection to MySQL server during query when dumping table. L'origine potrebbe non essere disponibile o il dump conteneva pacchetti troppo grandi.

Assicurati che l'istanza principale esterna sia disponibile per la connessione oppure utilizza mysqldump con l'opzione max_allowed_packet.

Per saperne 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 eseguita correttamente, ma non viene replicato alcun dato. Una delle possibili cause principali potrebbe essere che il database di origine ha definito flag 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 siano impostati in modo conflitto.

Esegui il comando show master status sull'istanza principale per visualizzare le impostazioni attuali.

La migrazione iniziale dei dati è stata completata correttamente, ma la replica dei dati non funziona più dopo un certo periodo 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 IO di MySQL o del thread SQL 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_in esecuzione
    • Esecuzione_Slave_SQL
    • Ultimo_IO_Errore
    • Ultimo_errore_SQL
mysqld check failed: data disk is full. Il disco dati dell'istanza di replica è esaurito.

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

Replica esterna

Problema Risolvere i 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 un numero sufficiente di log per consentire alla replica di recuperare i dati. 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 di flag corrette e configura la replica esterna utilizzando quel file

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

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

    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.

Flag

Problema Risolvere i problemi
Dopo aver abilitato un flag, l'istanza si sposta in loop tra panico e arresto anomalo. Contatta l'assistenza clienti per richiedere la rimozione del flag seguito da un hard drain. Questo forza il riavvio dell'istanza su un host diverso con una nuova configurazione senza il flag o l'impostazione indesiderati.
Quando provi a impostare un flag viene visualizzato il messaggio di errore Bad syntax for dict arg. I valori dei parametri complessi, ad esempio gli elenchi separati da virgole, richiedono un trattamento speciale se utilizzato con i comandi gcloud.

Alta disponibilità

Problema Risolvere i problemi
Impossibile trovare le metriche per un failover manuale. Solo i failover automatici entrano nelle metriche.
Le risorse delle istanze Cloud SQL (CPU e RAM) sono quasi al 100% di utilizzo, causando la riduzione 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 macchina di dimensioni maggiori per ottenere più CPU e memoria.

Importa

Problema Risolvere i problemi
HTTP Error 409: Operation failed because another operation was already in progress. È già presente un'operazione in attesa per l'istanza. È consentita una sola operazione alla volta. Prova a eseguire la richiesta dopo il completamento dell'operazione in corso.
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 dell'istanza Cloud SQL per assicurarti che siano disponibili molte risorse. Il modo migliore per garantire il massimo delle risorse per l'importazione è riavviare l'istanza prima di iniziare l'operazione.

Un riavvio:

  • Chiude tutte le connessioni.
  • Termina tutte le attività che potrebbero consumare risorse.
Un'operazione di importazione può non riuscire quando uno o più utenti a cui si fa riferimento nel file di dump non esistono. Prima di importare un file di dump, tutti gli utenti del database che dispongono di oggetti o di cui sono state concesse le autorizzazioni su oggetti nel database devono essere presenti nel database di destinazione. In caso contrario, l'operazione di importazione non riesce a ricreare gli oggetti con le autorizzazioni o la proprietà originale.

Crea gli utenti del database prima di eseguire l'importazione.

Un'operazione di importazione non riesce con errore che non esiste una tabella. Le tabelle possono avere dipendenze chiave esterne su altre tabelle e, a seconda dell'ordine delle operazioni, una o più di queste 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 mentre è in corso l'operazione di importazione e li riattivano dopo il caricamento dei dati. Ciò non influisce sull'integrità dei dati nel database, poiché i dati sono già stati convalidati durante la creazione del file di dump.

Logging

Problema Risolvere i problemi
Audit log non trovati. I log di accesso ai dati vengono scritti solo se l'operazione è una chiamata API gestita dall'utente autenticata che crea, modifica o legge i dati creati dall'utente oppure se l'operazione accede ai file di configurazione o ai metadati delle risorse.
Impossibile trovare informazioni sulle operazioni nei log. Vuoi trovare ulteriori informazioni su un'operazione.

Ad esempio, se un utente è stato eliminato, ma non riesci a scoprire chi l'ha fatto. I log mostrano l'operazione avviata, ma non forniscono ulteriori informazioni. Devi attivare l'audit logging per registrare informazioni dettagliate e personali (PII) come queste.

Il logging utilizza molto spazio su disco. Esistono tre tipi di file di log che utilizzano lo spazio su disco: i log di ripetizione, i log generali e i 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 JSON o Testo.Puoi usare il comando gcloud logging read insieme ai comandi di post-elaborazione 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
   

Gestione delle istanze

Problema Risolvere i 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, la 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 fino a quando la cache non viene riempita.
Recupero lento degli arresti anomali. Potrebbe aver accumulato un importo significativo di general_log. Puoi ridurre i tempi di recupero dagli arresti anomali impedendo l'accumulo di un numero elevato di general_log. Se hai attivato general_log, tronca la tabella e attiva general_log solo per brevi periodi di tempo.

Per ottenere 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 occupa spazio di archiviazione. Ad esempio, noti che il tuo database utilizza solo tre GB, ma lo spazio di archiviazione indica che sono in uso 14 GB. La maggior parte dello spazio non utilizzato dalle tabelle è occupata da log binari e/o 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 di MySQL: SHOW BINARY LOGS;
  • Le tabelle temporanee potrebbero anche occupare una quantità significativa di spazio di archiviazione. Per controllare l'utilizzo temporaneo dello spazio, 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 ripetizione: SHOW VARIABLES LIKE 'innodb_log_file%';
  • Puoi verificare la dimensione di general_log, se è abilitata, 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 di log utilizzando l'API. Per ulteriori informazioni, consulta la pagina di riferimento instances.truncateLog.
  • Scopri di più sull'impostazione e sulla configurazione dei log delle query lente.
Le query sono bloccate. Le query possono bloccare il database MySQL, causando il blocco/timeout di tutte le query successive.

Connettiti al database ed esegui questa query:

SHOW PROCESSLIST.

Il primo elemento nell'elenco potrebbe essere quello che contiene la serratura, che sono i successivi elementi in attesa.

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, che in genere si verifica dopo circa sette giorni.
Vuoi trovare informazioni sui file temporanei. Per l'archiviazione di dati temporanei viene utilizzato un file denominato ibtmp1. Questo file viene reimpostato al riavvio del database. Per trovare informazioni sull'utilizzo temporaneo dei file, connettiti al database ed esegui la seguente query:

SELECT * FROM INFORMATION_SCHEMA.FILES WHERE TABLESPACE_NAME='innodb_temporary'\G

Vuoi avere informazioni sulle dimensioni delle tabelle. Queste informazioni sono disponibili nel database.

Collegati 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 indicatore 11. Prova a refactoring delle query in modo che non creino troppe connessioni. Se il problema persiste, contatta l'assistenza clienti. L'indicatore 11 rappresenta generalmente un problema del software MySQL.

InnoDB: page_cleaner: 1000ms intended loop took 5215ms. The settings might not be optimal. Lo strumento di pulizia delle pagine non riesce a stare al passo con la frequenza di modifica dell'istanza. Una volta al secondo, lo strumento di pulizia delle pagine scansiona il pool di buffer per rilevare eventuali pagine sporche da svuotare dal pool di buffer a disco. L'avviso visualizzato mostra molte pagine sporche da svuotare e il completamento dell'operazione richiede più di un secondo su disco.

Crea un'istanza dell'istanza, se possibile. L'utilizzo di molte istanze Cloud SQL più piccole è meglio di un'istanza di grandi dimensioni.

Lo spazio di archiviazione temporaneo ha aumentato lo 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.

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

Esamina i log relativi al momento dell'eliminazione e controlla se esiste uno script non autorizzato eseguito da una dashboard o un altro processo automatizzato.

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

Alcune possibili spiegazioni sono:

  • È 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 dimensioni temporanee dei dati. Il sistema può creare più tabelle temporanee contemporaneamente, a seconda delle query e del carico.

Purtroppo, non puoi ridurre il file ibtmp1 con qualsiasi metodo che non sia il riavvio del servizio.

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

Errore irreversibile durante l'upgrade. I log possono fornire ulteriori informazioni, ma in ogni caso potrebbe essere necessaria assistenza clienti per forzare la nuova creazione 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 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.

La tua istanza principale on-premise è bloccata. Google Cloud non può aiutare con 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 sporco.

Avendo connessioni che durano meno di 60 secondi, si può evitare la maggior parte delle arresti non puliti, incluse le connessioni dal prompt dei comandi del database. Se mantieni queste connessioni aperte per ore o giorni, le chiusure possono essere sporche.

Impossibile eliminare un utente. Probabilmente l'utente contiene oggetti nel database che dipendono da esso. Dovrai eliminare questi oggetti o riassegnarli a un altro utente.

Scopri quali oggetti dipendono dall'utente, quindi rilascia o riassegna gli oggetti a un altro utente.

Questo articolo illustra come trovare gli oggetti di proprietà dell'utente.
Le query specifiche sono lente. 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 (scrittura o lettore) e la risorsa di destinazione (Cloud SQL) si trovano in aree geografiche diverse.

Fai riferimento ai suggerimenti generali sulle prestazioni in particolare.

Per azioni di inserimento, aggiornamento o eliminazione lenti dei database, valutate le seguenti azioni:

  • Se abiliti il flag long_query_time, puoi controllare i log per individuare le query lente. Vai alla pagina Esplora log del progetto ed esegui una query simile alla seguente:
    
    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 TESTO per l'elaborazione locale.

  • Controlla le località dell'autore e del database; l'invio di dati a lunga distanza introduce la latenza.
  • Controlla la posizione del lettore e del database; la latenza influisce sulle prestazioni di lettura più che sulle prestazioni di scrittura.

Per ridurre la latenza, è consigliabile individuare sia le risorse di origine che di destinazione nella stessa regione.

La memoria esaurita è indicata, ma i grafici di monitoraggio non lo mostrano. Un'istanza può non riuscire e segnalare Out of memory, ma i grafici di Google Cloud Console o Cloud Monitoring sembrano mostrare ancora la memoria rimanente.

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 interni. Queste non sono sempre riportate nei grafici di monitoraggio.

Assicurati che l'istanza abbia un carico di lavoro sufficiente per tenere conto del tuo carico di lavoro, oltre a un carico di lavoro aggiuntivo.

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

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 quando 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. Questo consente di creare la nuova istanza senza dover importare i dati manualmente. 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 desiderato e quindi importare i dati nella nuova istanza.

In entrambi i casi, puoi eliminare l'istanza precedente al termine dell'operazione. Consigliamo di utilizzare il percorso di clonazione in quanto non ha alcun impatto sulle prestazioni e non richiede il ripristino di alcuna impostazione di configurazione delle istanze come flag, tipo di macchina, dimensioni dello spazio di archiviazione e memoria.

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

Replica

Problema Risolvere i problemi
La replica di lettura non ha iniziato a essere replicata al momento della creazione. È probabile che ci sia un errore più specifico nei file di log. Esamina i log in Cloud Logging per trovare l'errore effettivo.
Impossibile creare la replica di lettura: errore InvalidFlagValue. Uno dei flag nella richiesta non è valido. Potrebbe essere un flag specificato in modo esplicito o impostato su un valore predefinito.

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

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

Impossibile creare la replica di lettura - errore sconosciuto. È probabile che ci sia un errore più specifico nei file di log. Esamina i log in Cloud Logging per trovare l'errore effettivo.

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

Il disco è pieno. La dimensione del disco dell'istanza principale può essere piena durante la creazione della replica. Modifica l'istanza principale per eseguire l'upgrade a un disco più grande.
L'istanza di replica utilizza troppa memoria. La replica utilizza una memoria temporanea per memorizzare nella cache le operazioni di lettura richieste spesso, il che può portarlo 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 automatic storage increase.

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 riesce a tenere il passo con il thread IO. Alcuni tipi di query o carichi di lavoro possono causare un tempo di replica temporaneo o permanente per uno schema specifico. Alcune delle tipiche cause dei tempi di replica sono:
  • Query lente sulla replica. Trovali e correggili.
  • Tutte le tabelle devono avere una chiave univoca/principale. Ogni aggiornamento su una tabella di questo tipo senza una chiave univoca/principale determina la scansione completa della tabella sulla replica.
  • Query come DELETE ... WHERE field < 50000000 causano un ritardo della replica con la replica basata su riga poiché un numero enorme di aggiornamenti viene accumulato nella replica.

Alcune possibili soluzioni includono:

Il ritardo della replica aumenta improvvisamente. e ciò è dovuto a transazioni a lunga esecuzione. Quando una transazione (una singola istruzione o più istruzioni) esegue il commit 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 quello attuale per calcolare il tempo di replica. Pertanto, una transazione a lunga esecuzione sull'origine comporterebbe un ritardo immediato della replica di grandi dimensioni sulla replica. Se il numero di modifiche alle righe nella transazione è elevato, la replica impiegherà molto tempo per eseguirla. Durante questo periodo, il tempo di replica sta aumentando. Una volta che la replica termina questa transazione, il periodo di recupero dipenderà dal carico di lavoro di scrittura nell'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
  • Suddividere una singola query di scrittura di grandi dimensioni in batch più piccoli
  • Prova a separare le query SELECT lunghe da una transazione combinata con DML
La modifica dei flag di replica parallela genera un errore. Per uno o più di questi flag è impostato un valore errato.

Nell'istanza principale in cui viene visualizzato 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

Creazione della replica non riuscita con timeout. Le transazioni non eseguite a lunga esecuzione sull'istanza principale possono impedire la creazione corretta della replica di lettura.

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