Risolvere i problemi

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

Gli argomenti di questa pagina includono:

Backup e ripristino

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

Esegui Comando gcloud sql operations list per elencare tutti 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.

Controlla i log e filtra in base al testo per trovare l'utente. Potresti dover utilizzare i log di controllo 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 visualizzarle, Potrebbe essere disponibile anche cloudaudit.googleapis.com/activity.
Una volta eliminata 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, vengono ripristinati anche i relativi backup. Per ulteriori informazioni sul recupero di un'istanza eliminata, consulta la sezione Backup di recupero.

Se hai eseguito un'operazione di esportazione, crea una nuova istanza ed eseguire un'operazione di importazione per ricreare il database. Le esportazioni sono 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 devi davvero annullare l'operazione, puoi chiedere assistenza clienti a force restart l'istanza.
Un'operazione di ripristino può non riuscire quando uno o più utenti a cui viene fatto riferimento nel Il file di dump SQL non esiste. Prima di ripristinare un dump SQL, tutti gli utenti del database che sono proprietari degli oggetti a cui sono state concesse le autorizzazioni per gli oggetti nel database di cui è stato eseguito il dump, 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 sette a 30 giorni o più. Puoi e 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 i backup attualmente visibili sono gli unici da cui puoi eseguire il ripristino.

Per conservare i backup a tempo indeterminato, puoi: creazione un backup on demand, in quanto non vengono eliminati come backup automatici. I backup on demand rimangono a tempo indeterminato. Vale a dire che rimangono valide finché non vengono eliminate o 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 è 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 riuscito o annullato. 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 Assistenza Google Cloud.

Clona

Problema Risoluzione dei problemi
La clonazione non è riuscita e viene restituito constraints/sql.restrictAuthorizedNetworks errore. 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 per motivi di sicurezza.

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

Stai tentando di utilizzare la console Google Cloud per clonare un'istanza con un IP privato ma non hai specificato l'intervallo IP allocato desiderato da 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 ulteriori informazioni, consulta Clonare un'istanza con un IP privato.

Connetti

Problema Risoluzione dei problemi
Aborted connection. Il problema potrebbe essere:
  • Instabilità della rete.
  • Nessuna risposta ai comandi keep-alive TCP (client o server non reattivo, probabilmente 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 nuovi tentativi. La maggior parte dei pooler di connessioni rileva ove possibile. In caso contrario, l'applicazione deve riprovare puoi fallire con eleganza.

Per riprovare la connessione, consigliamo i seguenti metodi:

  1. Exponential il backoff. Aumenta in modo esponenziale l'intervallo di tempo tra ogni nuovo tentativo.
  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 dei 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:

  • La dimensione dell'intervallo IP allocato per la connessione privata al servizio è minore di /24.
  • La dimensione dell'intervallo IP allocato per la connessione al 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 del servizio privato. Per ulteriori informazioni, 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 che si sovrappongono a eventuali allocazioni esistenti.

Dopo aver creato un nuovo intervallo IP, aggiorna il peering VPC con quanto segue :

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 su almeno 10.0.10.0/23.

In generale, se parti da un'allocazione /24, è buona norma decrementare la maschera di 1 per ogni condizione (gruppo di tipo di istanza aggiuntivo, regione aggiuntiva). Ad esempio, se stai tentando di creare entrambi i gruppi di tipo di istanza nella 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
Messaggio di errore: Failed to create subnetwork. Router status is temporarily unavailable. Please try again later. Help Token: [token-ID]. Prova a creare di nuovo l'istanza Cloud SQL.
Messaggio di errore: Failed to create subnetwork. Required 'compute.projects.get' permission for PROJECT_ID. Quando crei un'istanza utilizzando un indirizzo IP privato, un servizio viene creato just-in-time utilizzando l'API Service Networking. Se hai abilitato solo di recente l'API Service Networking, quindi l'account di servizio potrebbe non essere creato e la creazione dell'istanza non riesce. In questo caso, devi attendere che l'account di servizio venga propagato nel sistema o aggiungerlo manualmente con le autorizzazioni richieste.

Esporta

Problema Risoluzione dei problemi
HTTP Error 409: Operation failed because another operation was already in progress. Esiste già un'operazione in attesa per l'istanza. È consentita una sola operazione alla volta. Prova la richiesta dopo che l'operazione attuale è completato.
HTTP Error 403: The service account does not have the required permissions for the bucket. Assicurati che il bucket esista e 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 in formato 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 per il completamento. Il formato CSV consente di devi definire quali elementi del database includere nell'esportazione.

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

Utilizza esportazione offloading. A un livello generale, durante il trasferimento delle esportazioni, anziché eseguire un'esportazione sull'istanza di origine, Cloud SQL avvia un'istanza di offload per eseguire l'esportazione. Lo sgravio dell'esportazione offre diversi vantaggi, tra cui un aumento delle prestazioni dell'istanza di origine e lo sblocco delle operazioni amministrative durante l'esecuzione dell'esportazione. Con il ribaltamento dell'esportazione, la latenza totale può aumentare in base al tempo necessario per avviare l'istanza di ribaltamento. In genere, per le esportazioni di dimensioni ragionevoli, la latenza non è significativa. Tuttavia, se l'esportazione è sufficientemente ridotta, potresti notare un 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 automatica utilizzando i prodotti Google Cloud come Cloud Scheduler, Pub/Sub e le funzioni Cloud Run, come spiegato in questo articolo sull' automazione dei backup.

Principale esterna

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

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

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

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

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

  • Controlla le metriche di replica per l'istanza di replica in Cloud Monitoring della console Google Cloud.
  • Gli errori del thread IO di MySQL o del thread SQL possono essere ritrovati in Cloud Logging nei file mysql.err log.
  • L'errore può essere rilevato anche durante la connessione all'istanza replica. Esegui il comando SHOW SLAVE STATUS e controlla se è presente 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. Tu puoi aumentare manualmente la dimensione 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 ha backup automatici e log e il recupero point-in-time è abilitato, quindi dovrebbe avere un numero sufficiente di log affinché la replica possa recuperare. Tuttavia, in questo caso, anche se log binari, la replica non sa da quale riga iniziare a leggere.

Crea un nuovo file di dump utilizzando le impostazioni di flag corrette, quindi configura il una replica esterna utilizzando il file

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

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

    Impara altro ancora.

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

Bandiere

Problema Risoluzione dei problemi
Dopo aver attivato un flag, l'istanza passa da un panico all'altro e si arresta in modo anomalo. Contatta l' assistenza clienti per richiesta di rimozione seguita da un hard drain. In questo modo, l'istanza viene forzata a riavviare su un host diverso con una configurazione nuova senza il flag o l'impostazione indesiderati.
Viene visualizzato 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'impostazione speciale quando utilizzato con i comandi gcloud.

Alta disponibilità

Problema Risoluzione dei problemi
Non riesci a trovare le metriche per un failover manuale. Nelle metriche vengono inclusi solo i failover automatici.
Le risorse dell'istanza Cloud SQL (CPU e RAM) sono vicine al 100% di utilizzo, causando l'interruzione dell'istanza ad alta disponibilità. La dimensione dell'istanza della macchina è troppo piccola per il carico.

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

Importa

Problema Risoluzione dei problemi
HTTP Error 409: Operation failed because another operation was already in progress. Esiste già un'operazione in attesa per l'istanza. È consentita una sola operazione alla volta. Prova la richiesta dopo che l'operazione attuale è completato.
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 della tua istanza Cloud SQL per assicurarti che siano disponibili moltissime 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 andare a buon fine se uno o più utenti a cui viene fatto riferimento nel file di dump non esistono. Prima di importare un file di dump, tutti gli utenti del database che possiedono gli oggetti a cui sono state concesse le autorizzazioni per gli oggetti nel database di cui è stato eseguito il dump, database di destinazione. In caso contrario, l'operazione di importazione non riesce a ricreare il file oggetti con la proprietà o le autorizzazioni originali.

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

Tentativi da effettuare

Aggiungi la seguente riga all'inizio del file dump:

SET FOREIGN_KEY_CHECKS=0;

Inoltre, aggiungi questa riga alla fine del file dump:

SET FOREIGN_KEY_CHECKS=1;

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

Logging

Problema Risoluzione dei problemi
Log di controllo non trovati. I log di accesso ai dati vengono scritti solo se l'operazione è autenticata chiamata API basata sull'utente che crea, modifica o legge i dati creati dall'utente. o se l'operazione accede ai file di configurazione o ai metadati delle risorse.
Informazioni sulle operazioni non trovate nei log. Vuoi trovare ulteriori informazioni su un'operazione.

Ad esempio, se un utente è stato eliminato, ma non riesci a scoprire chi lo ha fatto. I log mostrano è stata avviata, ma non fornisci altre informazioni. Devi attiva log di controllo per l'identificazione personale e dettagliata informazioni (PII) come questa.
Il logging utilizza molto spazio su disco. Esistono tre tipi di file di log che utilizzano spazio su disco: Ripeti log, di log generali e binari.

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

SHOW VARIABLES LIKE 'innodb_log_file%';

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

SHOW BINARY LOGS;
I file di log sono difficili da leggere. Preferisci visualizzare i log come file JSON o di testo. Puoi utilizzare il gcloud logging read comando insieme ai comandi di post-elaborazione di Linux per scaricare i log.

Per scaricare i log in formato JSON:

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

Per scaricare i log come TEXT:

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

Gestione delle istanze

Problema Risoluzione dei problemi
Prestazioni lente dopo il riavvio di MySQL. Cloud SQL consente la memorizzazione nella cache dei dati nel pool di buffer InnoDB. Tuttavia, dopo un riavvio, questa cache è sempre vuota e tutte le letture richiedono un round trip al backend per recuperare i dati. Di conseguenza, le query possono essere più lente del previsto fino a quando la cache non viene riempita.
Ripristino lento in caso di arresto anomalo. Potrebbe essersi accumulato un volume elevato di general_log. Puoi ridurre il tempo di recupero in caso di arresto anomalo impedendo l'accumulo di un gran numero di general_log. Se hai general_log tronca la tabella e abilita general_log solo per brevi diversi periodi di tempo.

Per conoscere le dimensioni dei log generici, connettiti al database ed esegui questa query:

SELECT ROUND(SUM(LENGTH(argument)/POW(1024,2)),2) from mysql.general_log;
Vuoi sapere cosa sta utilizzando lo spazio di archiviazione. Ad esempio, noti che il database utilizza solo 3 GB, che 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 occupato dai log binari utilizzando il seguente comando nell'interfaccia a riga di comando MySQL: SHOW BINARY LOGS;
  • Anche le tabelle temporanee possono occupare una quantità significativa di di archiviazione. Per controllare l'utilizzo dello spazio temporaneo, 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 è 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 maggiori informazioni informazioni, consulta pagina di riferimento istanzas.truncateLog.
  • Scopri di più su come impostare e configurare i log delle query lente.
Le query sono bloccate. È possibile che le query blocchino il database MySQL, causando il blocco/il timeout di tutte le query successive.

Connettiti al database ed esegui questa query:

SHOW PROCESSLIST.

Il primo elemento dell'elenco potrebbe essere quello che detiene la serratura, in attesa degli elementi successivi.

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

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

Connettiti al database ed esegui questa query:

SELECT TABLE_SCHEMA, TABLE_NAME, sum(DATA_LENGTH+INDEX_LENGTH)/pow(1024,2) FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA NOT IN ('PERFORMANCE_SCHEMA','INFORMATION_SCHEMA','SYS','MYSQL') GROUP BY TABLE_SCHEMA, TABLE_NAME;
mysqld ha ricevuto un segnale 11. Prova a eseguire il refactoring delle query in modo che non creino troppe connessioni. Se il problema persiste, contatta l'assistenza clienti. 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. Lo strumento per la pulizia delle pagine non è in grado di tenere il passo con la frequenza di modifica dell'istanza. Una volta al secondo, lo strumento di pulizia delle pagine esegue la scansione del pool di buffer per individuare le pagine sporche da svuotare dal pool di buffer sul disco. L'avviso che vedi indica che ci sono molte pagine sporche da svuotare e che l'operazione richiede più di un secondo per svuotare un batch sul disco.

Esegui lo sharding dell'istanza se possibile. È preferibile utilizzare molte istanze Cloud SQL di piccole dimensioni anziché un'unica istanza di grandi dimensioni.
L'archiviazione temporanea ha aumentato l'archiviazione automatica. Lo spazio di archiviazione automatico è attivo.

Il riavvio elimina i file temporanei, ma non riduce lo spazio di archiviazione. Solo l'assistenza clienti può reimpostare la dimensione 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 malintenzionato da una dashboard o da un'altra procedura automatica.
L'istanza non può essere eliminata. Potresti visualizzare il messaggio di errore ERROR: (gcloud.sql.instances.delete) HTTP Error 409: The instance or operation is not in an appropriate state to handle the request oppure l'istanza potrebbe presentare un INSTANCE_RISKY_FLAG_CONFIG la segnalazione dello stato.

Ecco alcune possibili spiegazioni:

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

Purtroppo non puoi ridurre il file ibtmp1 con alcun 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 tabella file per tabella nella directory dei file temporanei. Tuttavia, il rovescio della medaglia è rappresentato dai costi in termini di prestazioni associati alla creazione e alla rimozione di un tablespace file per tabella per ogni tabella temporanea.
Errore irreversibile durante l'upgrade. I log potrebbero rivelare di più, ma in ogni caso potrebbe essere necessaria l'assistenza clienti per forzare la ricostituzione dell'istanza.
L'istanza è bloccata durante il riavvio dopo aver esaurito lo spazio su disco. La funzionalità di aumento automatico dello spazio di archiviazione non è abilitata.

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

Poiché le connessioni durano meno di 60 secondi, la maggior parte delle è possibile evitare gli arresti, incluse le connessioni dal database al prompt dei comandi. Se mantieni queste connessioni aperte per ore o giorni, gli arresti anomali possono non essere corretti.
Un utente non può essere eliminato. È probabile che l'utente contenga oggetti nel database che dipendono da questo. Devi eliminare questi oggetti o riassegnareli a un altro utente.

Scopri quali oggetti dipendono dall'utente, poi rilasciali o riassegnali per questi oggetti a un altro utente.

Questo articolo spiega come trovare gli oggetti di proprietà dell'utente.
Alcune query sono lente. Le query possono essere lente per molti motivi, principalmente a causa di database specifici aspetti. Uno dei motivi che può influire su Cloud SQL è la latenza di rete, quando la risorsa di origine (autore o lettore) e la destinazione (Cloud SQL) si trovano in regioni diverse.

Consulta consigli generali per le prestazioni.

Per inserimenti, aggiornamenti o eliminazioni del database lenti, valuta le seguenti azioni:

  • Se attivi il flag long_query_time, puoi controllare i log per individuare 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. inviare i dati per molto tempo la distanza introduce latenza.
  • Controlla la posizione del lettore e del database. la latenza influisce sulla lettura il rendimento è ancora superiore a quello della scrittura

Per ridurre la latenza, ti consigliamo di posizionare le risorse di origine e di destinazione nella stessa regione.
Viene indicato che non è disponibile memoria, ma i grafici di monitoraggio non lo mostrano. Un'istanza può generare un errore e segnalare Out of memory, ma I grafici della console Google Cloud o di Cloud Monitoring sembrano indicare che sono ancora memoria rimanente.

Oltre al carico di lavoro, esistono altri fattori che possono influire sulla memoria di rete, ad esempio il numero di connessioni attive e l'overhead interno i processi di machine learning. Questi aspetti non sempre si riflettono nei grafici di monitoraggio.

Assicurati che l'istanza abbia un overhead sufficiente per tenere conto del carico di lavoro più costi aggiuntivi.
Recupero di un'istanza eliminata. Tutti i dati su un'istanza, inclusi i backup, vengono persi definitivamente quando viene eliminata l'istanza.

Per preservare 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 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. Ciò ti 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 della tua istanza in un Cloud Storage bucket, creare una nuova istanza con il nuovo nome import i dati nella nuova istanza.

In entrambi i casi, puoi eliminare la vecchia istanza dopo che l'operazione è stata fatto. Ti consigliamo di utilizzare la procedura di clonazione, in quanto non influisce sul rendimento e non richiede di rifare le impostazioni di configurazione dell'istanza, come flag, tipo di macchina, dimensioni dello spazio di archiviazione e memoria.
Errore durante l'eliminazione di un'istanza. Se per un'istanza è abilitata la protezione da eliminazione, conferma i tuoi piani per eliminare l'istanza. Poi Disabilita la protezione da eliminazione prima di eliminare l'istanza.

Private Service Connect
Problema Risoluzione dei problemi
Il collegamento al 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 dell'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.

Replica

Problema Risoluzione dei problemi
La replica di lettura non è stata avviata al momento della creazione. Probabilmente contiene 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 una segnalazione fornito esplicitamente o uno impostato su un valore predefinito.

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

Se il flag max_connections è impostato correttamente, esamina i log in Cloud Logging per trovare l'errore effettivo.
Impossibile creare la replica di lettura: errore sconosciuto. Probabilmente è presente un errore più specifico nei file di log. Esamina i log in Cloud Logging per trovare l'errore effettivo.

Se l'errore è: set Service Networking service account as servicenetworking.serviceAgent role on consumer project, disattiva e riattiva Service Networking API. Questa azione crea l'account di servizio necessario per continuare la procedura.
Lo spazio sul disco è esaurito. 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 maggiore.
L'istanza di replica utilizza troppa memoria. La replica utilizza memoria temporanea per memorizzare nella cache le operazioni di lettura spesso richieste, il che può portare a utilizzare più memoria dell'istanza principale.

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

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

Ecco alcune possibili soluzioni:
Il ritardo della replica presenta picchi improvvisi. Questo è causato da transazioni a lunga esecuzione. Quando una transazione (una singola istruzione o più istruzioni) viene eseguita nell'istanza di origine, la relativa ora di inizio viene registrata nel log binario. Quando la replica riceve questo evento binlog, confronta il timestamp con per calcolare il tempo di replica. Di conseguenza, una transazione a lunga esecuzione nell'origine comporterebbe un immediato ampio ritardo di replica replica. Se il numero di modifiche delle righe nella transazione è elevato, anche la replica impiegherà molto tempo per eseguirla. Nel frattempo, il ritardo della replica aumenta. Al termine della replica transazione, il periodo di recupero dipende dal carico di lavoro di scrittura dell'origine e la velocità di elaborazione della replica.

Per evitare una transazione lunga, alcune possibili soluzioni sono:

  • Suddividi la transazione in più transazioni di piccole dimensioni
  • Suddividi una singola query di scrittura di grandi dimensioni in batch più piccoli
  • Prova a separare le query SELECT lunghe da una transazione mista a DML
La modifica dei flag di replica parallela genera un errore. È 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 di un timeout. Le transazioni non committate di lunga durata nell'istanza principale possono causare il fallimento della creazione della replica di lettura.

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