Risolvere i problemi

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

Gli argomenti di questa pagina includono:

Backup e ripristino

Problema Risoluzione dei problemi
Non puoi visualizzare lo stato dell'operazione attuale. La console Google Cloud segnala solo l'esito positivo o negativo solo al termine dell'operazione. Non è progettato per mostrare avvisi o altri aggiornamenti.

Esegui il comando 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 filtra in base al testo per trovare l'utente. Per informazioni private, potrebbe essere necessario utilizzare gli audit log. I file di log pertinenti includono:

  • cloudsql.googlapis.com/mysql-general.log
  • cloudsql.googleapis.com/mysql.err
  • Se gli audit log di Cloud sono abilitati e disponi delle autorizzazioni necessarie per visualizzarli, potrebbe essere disponibile anche cloudaudit.googleapis.com/activity.
Dopo aver eliminato un'istanza, non puoi eseguire un backup.

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

Se hai eseguito un'operazione di esportazione, crea una nuova istanza, quindi esegui un'operazione di importazione per ricreare il database. Le esportazioni vengono scritte in Cloud Storage e le importazioni vengono lette da lì.
Un backup automatico è bloccato per molte ore e non può essere annullato. I backup possono richiedere molto tempo, a seconda delle dimensioni del database.

Se devi davvero annullare l'operazione, puoi contattare l' assistenza clienti per 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 degli oggetti o a cui sono state concesse autorizzazioni per gli oggetti nel database di cui è stato eseguito il dump devono esistere nel database di destinazione. In caso contrario, l'operazione di ripristino non riuscirà a ricreare gli oggetti con la proprietà o le autorizzazioni originali.

Crea gli utenti del database prima di ripristinare il dump SQL.
Vuoi aumentare il numero di giorni in cui puoi conservare i backup automatici da 7 a 30 giorni o più. Puoi configurare il numero di backup automatici da conservare, da 1 a 365. I backup automatici vengono eliminati regolarmente in base al valore di conservazione configurato. Purtroppo, ciò significa che i backup attualmente visibili sono gli unici da cui puoi eseguire il ripristino automatici.

Per conservare i backup a tempo indeterminato, puoi creare un backup on demand, poiché non viene eliminato con la stessa modalità dei backup automatici. I backup on demand rimangono a tempo indeterminato. Vale a dire che rimangono fino a quando non vengono eliminati o fino all'eliminazione dell'istanza a cui appartengono. Poiché questo tipo di backup non viene eliminato automaticamente, ciò può influire sulla fatturazione.
Un backup automatico non è riuscito e non hai ricevuto una notifica via email. Per fare in modo che Cloud SQL ti invii una notifica sullo stato del backup, configura un avviso basato su log.

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'assistenza Google Cloud.

Clona

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

Se puoi, rimuovi tutte le voci Authorized Networks dall'istanza Cloud SQL. Altrimenti, crea una replica senza voci Authorized Networks.
Messaggio di errore: Failed to create subnetwork. Couldn't find free blocks in allocated IP ranges. Please allocate new ranges for this service provider. Help Token: [help-token-id].

Stai tentando di utilizzare la console Google Cloud per clonare un'istanza con un indirizzo IP privato, ma non hai specificato l'intervallo IP allocato che vuoi utilizzare e l'istanza di origine non viene creata con l'intervallo specificato. Di conseguenza, l'istanza clonata viene creata in un intervallo casuale.

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

Connetti

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

Per riprovare la connessione, consigliamo i seguenti metodi:

  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 non è corretto.

Rigenera i certificati ricreandoli.

Creare istanze

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

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

Per risolvere il problema, puoi espandere l'intervallo IP allocato esistente o allocare un intervallo IP aggiuntivo alla connessione privata al servizio. Per maggiori informazioni, consulta Assegnare un intervallo di indirizzi IP.

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

Se assegni un nuovo intervallo, assicurati che l'allocazione non si sovrapponga ad alcuna allocazione esistente.

Dopo aver creato un nuovo intervallo IP, aggiorna il peering vpc con il seguente comando:


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

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

In generale, se parte da un'allocazione /24, una buona regola generale è diminuire la dimensione /mask di 1 per ogni condizione (gruppo di tipi di istanza aggiuntivo, regione aggiuntiva). Ad esempio, se si cerca di creare entrambi i gruppi di tipi di istanza sulla stessa allocazione, è sufficiente passare da /24 a /23.

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


gcloud services vpc-peerings update \
--service=servicenetworking.googleapis.com \
--ranges=RESERVED_RANGE_NAME \
--network=VPC_NETWORK \
--project=PROJECT_ID
Messaggio di errore: Failed to create subnetwork. Router status is temporarily unavailable. Please try again later. Help Token: [token-ID]. Prova a creare di nuovo l'istanza Cloud SQL.

Esporta

Problema Risoluzione dei problemi
HTTP Error 409: Operation failed because another operation was already in progress. Esiste già un'operazione in attesa per l'istanza. È consentita una sola operazione alla volta. Prova a eseguire la richiesta al termine dell'operazione attuale.
HTTP Error 403: The service account does not have the required permissions for the bucket. Assicurati che il bucket esista e che l'account di servizio per l'istanza Cloud SQL (che esegue l'esportazione) abbia il ruolo Storage Object Creator (roles/storage.objectCreator) per consentire l'esportazione nel bucket. Vedi Ruoli IAM per Cloud Storage.
L'esportazione del file CSV è riuscita, ma l'esportazione SQL non è riuscita. I formati CSV e SQL vengono esportati in modo diverso. Il formato SQL esporta l'intero database e probabilmente richiede più tempo. Il formato CSV consente di definire quali elementi del database includere nell'esportazione.

Usa le esportazioni CSV per esportare solo ciò di cui hai bisogno.
L'esportazione sta richiedendo troppo tempo. Cloud SQL non supporta le operazioni sincrone in parallelo.

Utilizza la riduzione del carico delle esportazioni. A livello generale, con la riduzione del carico delle esportazioni, invece di inviare un'esportazione sull'istanza di origine, Cloud SQL avvia un'istanza di trasferimento del carico per eseguire l'esportazione. L'offload dell'esportazione presenta diversi vantaggi, tra cui un aumento delle prestazioni sull'istanza di origine e lo sblocco delle operazioni amministrative durante l'esecuzione dell'esportazione. Con la riduzione del carico delle esportazioni, la latenza totale può aumentare del tempo necessario per attivare l'istanza di offload. In genere, per esportazioni di dimensioni ragionevoli, la latenza non è significativa. Tuttavia, se l'esportazione è abbastanza ridotta, potresti notare un aumento della latenza.
Le esportazioni devono essere automatizzate. Cloud SQL non offre un modo per automatizzare le esportazioni.

Puoi creare il tuo sistema di esportazione automatica utilizzando i prodotti Google Cloud come Cloud Scheduler, Pub/Sub e Cloud Functions, simili a questo articolo sull' automazione dei backup.

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 grandi.

Assicurati che la rete principale esterna sia disponibile per la connessione. Puoi anche modificare i valori dei flag net_read_timeout e net_write_timeout sull'istanza di origine per arrestare l'errore. Per maggiori informazioni sui valori consentiti per questi flag, consulta Configurare i flag di database.

Per scoprire di più sull'utilizzo dei flag mysqldump per la migrazione dell'importazione gestita, consulta Flag di sincronizzazione iniziale consentiti e predefiniti
La migrazione iniziale dei dati è riuscita, ma nessun dato è stato replicato. Una delle possibili cause principali potrebbe essere che il database di origine abbia definito flag di replica, il che impedisce la replica di alcune o 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 in conflitto.

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

  • Controlla le metriche di replica dell'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 verifica la presenza dei 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 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 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 di log binari; inoltre, il recupero point-in-time è abilitato, quindi dovrebbe avere log sufficienti per consentire alla replica di recuperare. Tuttavia, in questo caso, anche se esistono i log binari, la replica non sa da quale riga iniziare la lettura.

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

  1. Connettiti al tuo 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 Risoluzione dei problemi
Dopo aver abilitato 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. Questa operazione forza il riavvio dell'istanza su un host diverso con una nuova configurazione senza l'impostazione o il flag indesiderato.
Visualizzi il messaggio di errore Bad syntax for dict arg quando cerchi di impostare un flag. I valori di 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 puoi trovare le metriche per un failover manuale. Nelle metriche vengono inseriti solo i failover automatici.
Le risorse dell'istanza Cloud SQL (CPU e RAM) hanno quasi raggiunto il 100% di utilizzo, causando l'arresto dell'istanza ad alta disponibilità. Le dimensioni della macchina dell'istanza sono troppo piccole per il carico.

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

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

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

Un riavvio:

  • Chiude tutte le connessioni.
  • Consente di terminare tutte le attività che potrebbero richiedere 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 possiedono oggetti o a cui sono state concesse autorizzazioni per gli oggetti nel database di cui è stato eseguito il dump devono esistere nel database di destinazione. In caso contrario, l'operazione di importazione non riesce a ricreare gli oggetti con la proprietà o le autorizzazioni originali.

Crea gli utenti del database prima dell'importazione.
Un'operazione di importazione non riesce e viene restituito un errore che indica che non esiste una tabella. 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 mentre è in corso l'operazione di importazione e li riattivano dopo il caricamento dei dati. Ciò non influisce sull'integrità dei dati nel database, perché i dati erano 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 dall'utente che crea, modifica o legge i dati creati dall'utente oppure se l'operazione accede a file di configurazione o metadati delle risorse.
Impossibile trovare informazioni sulle operazioni nei log. Vuoi scoprire di più su un'operazione.

Ad esempio, un utente è stato eliminato ma non puoi scoprire chi l'ha eseguito. I log mostrano l'operazione avviata, ma non forniscono ulteriori informazioni. Devi abilitare l'audit logging affinché vengano registrate informazioni che consentono l'identificazione personale (PII) dettagliate e come queste.
Il logging utilizza una grande quantità di spazio su disco. Esistono tre tipi di file di log che utilizzano spazio su disco: log di ripetizione, log generici e log binari.

Connettiti al database ed esegui questi comandi per conoscere 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 text.Puoi utilizzare il comando gcloud logging read insieme ai comandi di post-elaborazione di Linux per scaricare i log.

Per scaricare i log in formato JSON:


gcloud logging read \
"resource.type=cloudsql_database \
AND logName=projects/PROJECT_ID \
/logs/cloudsql.googleapis.com%2FLOG_NAME" \
--format json \
--project=PROJECT_ID \
--freshness="1d" \
> downloaded-log.json

Per scaricare i log in formato TESTO:


gcloud logging read \
"resource.type=cloudsql_database \
AND logName=projects/PROJECT_ID \
/logs/cloudsql.googleapis.com%2FLOG_NAME" \
--format json \
--project=PROJECT_ID \
--freshness="1d"| jq -rnc --stream 'fromstream(1|truncate_stream(inputs)) \
| .textPayload' \
--order=asc
> downloaded-log.txt

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 ottenere i dati. Di conseguenza, le query possono essere più lente del previsto fino a quando la cache non viene riempita.
Ripristino lento in seguito a un arresto anomalo. Potrebbe essersi accumulata un'enorme quantità di general_log. Puoi ridurre i tempi di ripristino degli arresti anomali impedendo l'accumulo di un valore general_log di grandi dimensioni. Se general_log è attivo, tronca la tabella e abilita general_log solo per brevi periodi di tempo.

Per conoscere 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 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 viene utilizzata 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;
  • Anche le tabelle temporanee potrebbero occupare una quantità significativa di spazio di archiviazione. Per verificare l'utilizzo temporaneo dello spazio, utilizza il seguente comando: 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 controllare 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 maggiori informazioni, consulta la pagina di riferimento diinstances.truncateLog.
  • Scopri di più sull'impostazione e sulla configurazione dei log di query lente.
Le query sono bloccate. Le query possono bloccare il database MySQL e causare 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 con il lucchetto, a cui sono ancora in attesa gli elementi successivi.

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 avviene dopo circa sette giorni.
Vuoi trovare informazioni sui file temporanei. Un file denominato ibtmp1 viene utilizzato per archiviare i dati temporanei. 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 saperne di più sulle dimensioni delle tabelle. Queste informazioni sono disponibili nel database.

Connettiti al database ed esegui la query seguente:

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

InnoDB: page_cleaner: 1000ms intended loop took 5215ms. The settings might not be optimal. La pulizia delle pagine non riesce a tenere il passo con la frequenza di modifica dell'istanza. Una volta al secondo, lo strumento di pulizia delle pagine esegue la scansione del pool di buffer per individuare eventuali pagine sporche ed eseguire lo svuotamento dal pool del buffer al disco. L'avviso visualizzato indica che il processo di svuotamento di molte pagine sporche richiede più di un secondo.

Esegui lo sharding dell'istanza, se possibile. L'utilizzo di molte istanze Cloud SQL più piccole è meglio di un'istanza di grandi dimensioni.
Spazio di archiviazione temporaneo aumentato spazio di archiviazione automatico. L'archiviazione automatica è abilitata.

Il riavvio elimina i file temporanei, ma non riduce lo spazio di archiviazione. Solo l' assistenza clienti può reimpostare le dimensioni dell'istanza.
Eliminazione automatica dei dati in corso. Molto probabilmente uno script è in esecuzione da qualche parte nel tuo ambiente.

Esamina i log al momento dell'eliminazione e controlla se è presente uno script non valido in esecuzione da una dashboard o da un altro processo automatizzato.
Impossibile eliminare l'istanza. È possibile che venga visualizzato il messaggio di errore ERROR: (gcloud.sql.instances.delete) HTTP Error 409: The instance or operation is not in an appropriate state to handle the request o che l'istanza abbia uno stato di flag INSTANCE_RISKY_FLAG_CONFIG.

Ecco alcune possibili spiegazioni:

  • È in corso un'altra operazione. Le operazioni di 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 del flag di rischio e riavvia l'istanza
L'istanza è bloccata a causa di grandi dimensioni dei dati temporanei. Il sistema può creare molte tabelle temporanee contemporaneamente, a seconda delle query e del carico.

Sfortunatamente, non puoi ridurre il file ibtmp1 utilizzando un metodo diverso dal riavvio del servizio.

Un'opzione di mitigazione è la creazione della tabella temporanea con ROW_FORMAT=COMPRESSED, in modo che venga archiviata in spazi tabella file per tabella nella directory dei file temporanei. Tuttavia, lo svantaggio sono i costi delle prestazioni associati alla creazione e alla rimozione di uno spazio tabella file per tabella per ogni tabella temporanea.
Errore irreversibile durante l'upgrade. I log possono rivelare maggiori informazioni, ma in ogni caso potrebbe essere necessaria l'assistenza clienti per forzare la nuova creazione dell'istanza.
L'istanza è bloccata al riavvio dopo aver esaurito lo spazio su disco. La funzionalità di aumento automatico dello spazio di archiviazione non è abilitata.

Se l'istanza esaurisce lo spazio di archiviazione e la funzionalità di aumento automatico dello spazio di archiviazione non è abilitata, l'istanza passa alla modalità offline. Per evitare questo problema, puoi modificare l'istanza per abilitare l'aumento automatico dello spazio di archiviazione.
L'istanza principale on-premise è bloccata. Google Cloud non può aiutarti con le istanze che non sono in Cloud SQL.
Arresto lento al riavvio. Quando un'istanza viene arrestata, le eventuali connessioni in sospeso che non terminano entro 60 secondi rendono non pulita l'arresto.

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

Scopri quali oggetti dipendono dall'utente, quindi rilascia o riassegnali a un utente diverso.

Questo articolo illustra come trovare gli oggetti di proprietà dell'utente.
L'esecuzione di query specifiche è lenta. Le query possono essere lente per molti motivi, principalmente a causa di aspetti specifici del database. Un motivo che può coinvolgere Cloud SQL è la latenza di rete, quando la risorsa di origine (autore o lettore) e la risorsa di destinazione (Cloud SQL) si trovano in regioni diverse.

In particolare, consulta i suggerimenti generali per il rendimento.

In caso di operazioni di inserimento, aggiornamento o eliminazione dei database lenti, prendi in considerazione le seguenti azioni:

  • Se abiliti il flag long_query_time, puoi controllare se nei log sono presenti query lente. Vai alla pagina Esplora log del tuo progetto ed esegui una query come la 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 TEXT per l'elaborazione locale.

  • Controlla le posizioni dello scrittore 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 anche più di quelle di scrittura

Per ridurre la latenza, si consiglia di individuare le risorse di origine e di destinazione nella stessa regione.
È indicato che la memoria è insufficiente, ma i grafici di monitoraggio non la mostrano. Un'istanza può non riuscire e segnalare Out of memory, ma la console Google Cloud o i grafici di Cloud Monitoring mostrano che è ancora disponibile memoria.

Oltre al carico di lavoro, esistono altri fattori che possono influire sull'utilizzo della memoria, come il numero di connessioni attive e i processi interni di overhead. Questi aspetti non sempre sono visibili nei grafici di monitoraggio.

Assicurati che l'istanza abbia un overhead sufficiente per tenere conto del tuo carico di lavoro e un overhead aggiuntivo.
Recupero di un'istanza eliminata in corso... Tutti i dati su un'istanza, inclusi i backup, vengono persi definitivamente quando l'istanza viene eliminata.

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

Il ruolo Amministratore Cloud SQL include l'autorizzazione per eliminare l'istanza. Per impedire l'eliminazione accidentale, concedi questo ruolo solo in base alle esigenze.
Vuoi rinominare un'istanza Cloud SQL esistente. La ridenominazione di un'istanza esistente non è supportata.

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

  • Puoi clonare l'istanza da 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 viene creata una nuova istanza, quella clonata ha un nuovo indirizzo IP.
  • Puoi esportare i dati dalla tua istanza in un bucket Cloud Storage, creare una nuova istanza con il nuovo nome e poi importare i dati nella nuova istanza.

In entrambi i casi, puoi eliminare l'istanza precedente al termine dell'operazione. Ti consigliamo di scegliere la route di clonazione poiché non ha alcun impatto sulle prestazioni e non richiede di ripetere le impostazioni di configurazione dell'istanza, come flag, tipo di macchina, dimensioni di archiviazione e memoria.
Errore durante l'eliminazione di un'istanza. Se la protezione da eliminazione è abilitata per un'istanza, conferma l'eliminazione dell'istanza. Quindi disabilita la protezione da eliminazione prima di eliminare l'istanza.

Replica

Problema Risoluzione dei problemi
La replica di lettura non ha avviato la replica al momento della creazione. È probabile che i file di log contengano un errore più specifico. Ispeziona i log in Cloud Logging per trovare l'errore effettivo.
Impossibile creare la replica di lettura: errore non validoFlagValue. Uno dei flag nella richiesta non è valido. Potrebbe essere un flag che hai fornito esplicitamente o un flag impostato su un valore predefinito.

Innanzitutto, verifica che il valore del flag max_connections sia maggiore o uguale al valore del flag 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 i file di log contengano 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 l'account di servizio necessario per continuare il processo.
Lo spazio sul disco è esaurito. La dimensione del disco dell'istanza principale può diventare piena durante la creazione della replica. Modifica l'istanza principale per eseguirne l'upgrade a una dimensione del disco più grande.
L'istanza di replica utilizza troppa memoria. La replica utilizza la memoria temporanea per memorizzare nella cache le operazioni di lettura più richieste, il che può portare a utilizzare più memoria rispetto all'istanza principale.

Riavvia l'istanza di replica per recuperare lo spazio di memoria temporaneo.
Replica interrotta. È stato raggiunto il limite massimo di spazio di archiviazione e l'aumento automatico dello spazio di archiviazione non è abilitato.

Modifica l'istanza per abilitare 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 è in grado di stare al passo con il thread di IO. Alcuni tipi di query o carichi di lavoro possono causare un ritardo di replica elevato, temporaneo o permanente, per un determinato schema. Alcune delle cause più comuni del ritardo di replica sono:
  • Query lente sulla replica. Trovale e correggile.
  • Tutte le tabelle devono avere una chiave univoca/primaria. Ogni aggiornamento in una tabella di questo tipo senza una chiave univoca/principale causa scansioni complete della tabella sulla replica.
  • Le query come DELETE ... WHERE field < 50000000 causano un ritardo di replica con la replica basata su righe, poiché un numero enorme di aggiornamenti è accumulato sulla replica.

Ecco alcune possibili soluzioni:
Il ritardo della replica aumenta improvvisamente. Ciò è causato da transazioni a lunga esecuzione. Quando viene eseguito il commit di una transazione (una istruzione singola o più istruzioni) sull'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 attuale per calcolare il ritardo di replica. Di conseguenza, una transazione a lunga esecuzione sull'origine comporterebbe un ritardo di replica immediato e di grandi dimensioni sulla replica. Se il numero di modifiche alle righe nella transazione è elevato, l'esecuzione della replica impiegherà molto tempo. Nel frattempo, il ritardo di replica aumenta. Al termine della transazione della replica, 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 piccola entità
  • Suddividi 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. È stato impostato un valore errato per uno o più di questi flag.

Sull'istanza principale in cui è 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
La creazione della replica non riesce a causa del timeout. Le transazioni non impegnate a lunga esecuzione nell'istanza principale possono causare la mancata creazione della replica di lettura.

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