Controlla se la tua domanda o il tuo problema è già stato risolto in una delle seguenti pagine:
- Domande frequenti
- Problemi noti
- Messaggi di errore
- Diagnosticare i problemi
- Eseguire il debug dei problemi di connessione
Gli argomenti di questa pagina includono:
- Backup e ripristino
- Annulla importazione ed esportazione
- Clonazione
- Connettività
- Creazione di istanze
- Principale esterna
- Replica esterna
- Flag
- Alta disponibilità
- Importazione ed esportazione
- Logging
- Gestione delle istanze
- Replica
Backup e ripristino
Problema | Risoluzione dei problemi |
---|---|
Non puoi visualizzare lo stato dell'operazione corrente. | La console Google Cloud segnala solo l'esito positivo o negativo al termine dell'operazione. Non è progettata per mostrare avvisi o altri aggiornamenti.
Esegui il
comando |
Vuoi sapere chi ha eseguito un'operazione di backup on demand. | L'interfaccia utente non mostra l'utente che ha avviato un'operazione.
Cerca l'utente nei log e filtra per testo. Potresti dover utilizzare gli audit log per le informazioni private. I file di log pertinenti includono:
|
Dopo aver eliminato un'istanza, non puoi eseguirne il backup. | Dopo l'eliminazione definitiva di un'istanza, non è possibile recuperare i dati. Tuttavia, se l'istanza viene ripristinata, vengono ripristinati anche i backup. Per ulteriori informazioni sul recupero di un'istanza eliminata, consulta Backup di recupero. Se hai eseguito un'operazione di esportazione, crea una nuova istanza, quindi esegui un'operazione di importazione per ricreare il database. Le esportazioni vengono scritte in Cloud Storage e le importazioni vengono lette da lì. |
Un backup automatico è bloccato per molte ore e non può essere annullato. | I backup possono richiedere molto tempo, a seconda delle dimensioni del database.
Se devi davvero annullare l'operazione, puoi chiedere all'
assistenza clienti di |
Un'operazione di ripristino può non riuscire quando non esistono uno o più utenti a cui viene fatto riferimento nel file di dump SQL. | 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 riesce a ricreare gli oggetti con le autorizzazioni o la proprietà 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 o più giorni. | Puoi
configurare il numero di backup automatici da conservare,
compreso tra 1 e 365. I backup automatici vengono eliminati regolarmente in base al valore di conservazione configurato. Purtroppo, ciò significa che i backup attualmente visibili sono gli unici backup automatici da cui puoi eseguire il ripristino.
Per conservare i backup a tempo indeterminato, puoi creare un backup on demand, poiché non vengono eliminati come i backup automatici. I backup on demand rimangono a tempo indeterminato. In altre parole, rimangono 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 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 |
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 è riuscita e viene restituito constraints/sql.restrictAuthorizedNetworks errore. |
L'operazione di clonazione è bloccata dalla configurazione Authorized Networks .
I 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 |
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 |
Connetti
Problema | Risoluzione dei problemi |
---|---|
Aborted connection . |
Il problema potrebbe essere:
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 pooler di connessioni rileva questi errori dove possibile. In caso contrario, l'applicazione deve riprovare o l'applicazione non riesce. Per riprovare la connessione, consigliamo i seguenti metodi:
La combinazione di questi metodi consente di ridurre la limitazione. |
Certificate verify failed . |
I certificati client sono scaduti o il percorso dei certificati 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 disponibili altri indirizzi nell'intervallo IP allocato. Possono esserci diversi scenari possibili:
Per risolvere il problema, puoi espandere l'intervallo IP allocato esistente o allocare un intervallo IP aggiuntivo alla connessione privata ai servizi. Per maggiori informazioni, consulta Allocare un intervallo di indirizzi IP. Se hai utilizzato il flag Se stai allocando 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 ridurlo. Ad esempio, se l'allocazione originale era 10.0.10.0/24, imposta la nuova allocazione almeno su 10.0.10.0/23. In generale, se parte da un'allocazione /24, come regola generale conviene diminuire /mask di 1 per ogni condizione (gruppo di tipi di istanze aggiuntivi, regione aggiuntiva). Ad esempio, se provi a creare entrambi i gruppi di tipi di istanza nella stessa allocazione, è sufficiente passare da /24 a /23. Dopo aver espanso un intervallo IP esistente, aggiorna il peering VPC con il seguente comando: gcloud services vpc-peerings update \ --service=servicenetworking.googleapis.com \ --ranges=RESERVED_RANGE_NAME \ --network=VPC_NETWORK \ --project=PROJECT_ID |
Messaggio di errore: Failed to create subnetwork. Router status is
temporarily unavailable. Please try again later. Help Token:
[token-ID] . |
Prova a creare di nuovo l'istanza Cloud SQL. |
Messaggio di errore: Failed to create subnetwork. Required
'compute.projects.get' permission for PROJECT_ID . |
Quando crei un'istanza utilizzando un indirizzo IP privato, viene creato un account di servizio just-in-time utilizzando l'API Service Networking. Se hai abilitato solo di recente l'API Service Networking, l'account di servizio potrebbe non essere creato e la creazione dell'istanza non riesce. In questo caso, devi attendere la propagazione dell'account di servizio in tutto il 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 il completamento dell'operazione attuale. |
HTTP Error 403: The service account does not have the required
permissions for the bucket. |
Assicurati che il bucket esista e che 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 in formato CSV è riuscita, ma l'esportazione SQL non è riuscita. | I formati CSV e SQL esportano in modo diverso. Il formato SQL esporta
l'intero database e il suo completamento richiede probabilmente più tempo. Il formato CSV consente di definire quali elementi del database includere nell'esportazione.
Utilizza le esportazioni CSV per esportare solo ciò che ti serve. |
L'esportazione sta richiedendo troppo tempo. | Cloud SQL non supporta le operazioni sincrone simultanee.
Utilizza l' esportazione offloading. A livello generale, in fase di offloading dell'esportazione, anziché inviare un'esportazione sull'istanza di origine, Cloud SQL avvia un'istanza di offload per eseguire l'esportazione. La distribuzione dell'esportazione presenta diversi vantaggi, tra cui maggiori prestazioni sull'istanza di origine e lo sblocco delle operazioni amministrative mentre l'esportazione è in esecuzione. Con l'offloading dell'esportazione, la latenza totale può aumentare della quantità di tempo necessaria per attivare l'istanza di offload. In genere, per 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 automatizzato utilizzando prodotti Google Cloud come Cloud Scheduler, Pub/Sub e Cloud Functions, come in questo articolo sull' automazione dei backup. |
Principale esterna
Problema | Risoluzione dei problemi |
---|---|
Lost connection to MySQL server during query when dumping table . |
L'origine potrebbe non essere più disponibile o il dump conteneva pacchetti troppo grandi.
Assicurati che l'istanza principale esterna sia disponibile per la connessione. Puoi anche modificare i valori dei flag net_read_timeout e net_write_timeout nell'istanza di origine per 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 |
La migrazione iniziale dei dati è riuscita, ma nessun dato viene replicato. | Una possibile causa principale potrebbe essere che il database di origine abbia definito flag di replica che impediscono la replica di alcune o tutte le modifiche al database.
Assicurati che i flag di replica come Esegui il comando |
La migrazione iniziale dei dati è riuscita, ma la replica dei dati si interrompe dopo un po' di tempo. | Tentativi da effettuare
|
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 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 dispone di backup automatici e log binari e il recupero point-in-time è abilitato, quindi dovrebbe avere log sufficienti per consentire alla replica di recuperare. Tuttavia, in questo caso, sebbene esistano i log binari, la replica non sa da quale riga iniziare a leggere.
Crea un nuovo file di dump utilizzando le impostazioni del flag corrette e configura la replica esterna utilizzando il file
|
Flag
Problema | Risoluzione dei problemi |
---|---|
Dopo aver abilitato un flag, l'istanza passa tra panico e arresto anomalo. | Contatta l' assistenza clienti per richiedere la rimozione di una segnalazione seguita da un hard drain . Ciò forza il riavvio dell'istanza su un host diverso con una nuova configurazione senza il flag o l'impostazione indesiderati.
|
Viene visualizzato il messaggio di errore Bad syntax for dict arg quando cerchi di impostare un flag.
| I valori dei parametri complessi, ad esempio 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 presi in considerazione 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à. | La dimensione della macchina dell'istanza è troppo piccola per il caricamento.
Modifica l'istanza per eseguire l'upgrade a una dimensione della macchina più grande e ottenere più CPU e memoria. |
Importazione
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 il completamento 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 ci siano molte risorse disponibili. Il modo migliore per garantire il numero massimo di risorse per l'importazione è riavviare l'istanza prima di iniziare l'operazione. Un riavvio:
|
Un'operazione di importazione può non riuscire se uno o più utenti a cui viene fatto riferimento nel file di dump non esistono. | Prima di importare un file di dump, tutti gli utenti del database che sono proprietari 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 importazione non ricrea gli oggetti con le autorizzazioni o la proprietà originali.
Crea gli utenti del database prima dell'importazione. |
Un'operazione di importazione non riesce e genera un errore che indica che la tabella non esiste. | Le tabelle possono avere dipendenze di chiave esterna 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, perché i dati sono già stati convalidati 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 è una chiamata API autenticata basata sull'utente che crea, modifica o legge i dati creati dall'utente oppure se l'operazione accede a file di configurazione o 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 l'operazione avviata, ma non forniscono altre informazioni. Per registrare le informazioni che consentono l'identificazione personale (PII) dettagliate e personali, devi abilitare l'audit logging. |
Il logging sta utilizzando molto spazio su disco. | Esistono tre tipi di file di log che utilizzano spazio su disco: Ripeti log, log generali e log binari.
Connettiti al database ed esegui questi comandi per maggiori 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 in formato json o text.Per scaricare i log, puoi utilizzare il comando
gcloud logging read
insieme ai comandi di post-elaborazione di Linux.
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 operazioni di lettura richiedono un round trip al backend per acquisire i dati. Di conseguenza, le query possono essere più lente del previsto fino a quando la cache non viene riempita. |
Ripristino dopo arresto anomalo lento. | È possibile che un general_log di grandi dimensioni si sia accumulato.
Puoi ridurre i tempi di ripristino in caso di arresto anomalo impedendo l'accumulo di
general_log di grandi dimensioni. Se hai attivato general_log , 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 sapere cosa sta utilizzando lo spazio di archiviazione. | Ad esempio, noti che il 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 è utilizzata dai log binari e/o dai file temporanei.
Tentativi da effettuare
|
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:
Il primo elemento dell'elenco potrebbe essere quello che contiene il blocco, su cui sono in attesa gli elementi successivi. Anche la query |
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, cosa che in genere avviene 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 sull'utilizzo dei file temporanei, connettiti al database ed esegui questa query:
|
Vuoi saperne di più sulle dimensioni delle tabelle. | Queste informazioni sono disponibili nel database.
Connettiti al database ed esegui questa query:
|
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, il servizio di pulizia pagine analizza il pool di buffer per individuare le pagine "sporche" da eseguire lo svuotamento dal pool di buffer sul disco. L'avviso che vedi indica che sono presenti molte pagine sporche da svuotare e per il flush di un batch su disco è necessario più di un secondo.
Se possibile, esegui il sharding dell'istanza. Utilizzare molte istanze Cloud SQL più piccole è meglio di un'istanza di grandi dimensioni. |
L'archiviazione temporanea ha aumentato l'archiviazione automatica. | L'archiviazione automatica è abilitata.
Il riavvio elimina i file temporanei, ma non riduce lo spazio di archiviazione. Solo l' assistenza clienti può reimpostare la dimensione dell'istanza. |
È in corso l'eliminazione automatica dei dati. | Molto probabilmente uno script è in esecuzione da qualche parte nel tuo ambiente.
Controlla nei log al momento dell'eliminazione e verifica se è presente uno script non autorizzato in esecuzione da una dashboard o da 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 l'istanza potrebbe avere uno stato di flag INSTANCE_RISKY_FLAG_CONFIG .
Ecco alcune possibili spiegazioni:
|
L'istanza è bloccata a causa di grandi dimensioni di dati temporanei. | Il sistema può creare molte tabelle temporanee contemporaneamente, a seconda delle query e del carico.
Purtroppo, il file Un'opzione di mitigazione è creare la tabella temporanea con
|
Errore irreversibile durante l'upgrade. | I log potrebbero rivelarne di più, ma in ogni caso potrebbe essere necessaria l'assistenza clienti per forzare la ricreazione 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 in modo da abilitare l'aumento automatico dello spazio di archiviazione. |
L'istanza principale on-premise è bloccata. | Google Cloud non può aiutarti con le istanze che non si trovano in Cloud SQL. |
Arresto lento al riavvio. | Quando un'istanza si arresta, eventuali connessioni in sospeso che non terminano entro 60 secondi rendono sporco l'arresto.
Se le connessioni durano meno di 60 secondi, è possibile evitare la maggior parte degli arresti sporchi, incluse le connessioni dal prompt dei comandi del database. Se tieni queste connessioni aperte per ore o giorni, gli arresti possono essere sporchi. |
Impossibile eliminare un utente. | È probabile che l'utente contenga oggetti nel database che dipendono da questo. Devi
rilasciare questi oggetti o riassegnarli a un altro utente.
Scopri quali oggetti dipendono dall'utente, quindi rilasciali o riassegnali a un utente diverso. 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 aspetti specifici del database. Uno dei motivi che può influire su Cloud SQL è la latenza di rete, quando la risorsa di origine (writer o lettore) e la risorsa di destinazione (Cloud SQL) si trovano in regioni diverse.
In particolare, consulta i suggerimenti generali per le prestazioni. Per inserimenti, aggiornamenti o eliminazioni lenti dei database, considera queste azioni:
Per ridurre la latenza, il consiglio è quello di individuare le risorse di origine e di destinazione nella stessa regione. |
È indicato che la memoria è insufficiente, ma non è indicato dai grafici di monitoraggio. | Un'istanza può non riuscire e segnalare Out of memory , ma i grafici
della console Google Cloud o di Cloud Monitoring sembrano mostrare che è ancora
presente memoria.
Oltre al carico di lavoro, esistono altri fattori che possono influire sull'utilizzo della memoria, ad esempio il numero di connessioni attive e i processi di overhead interni. Questi aspetti non sempre si riflettono nei grafici di monitoraggio. Assicurati che l'overhead dell'istanza sia sufficiente per tenere conto del carico di lavoro e dell'overhead aggiuntivo. |
Recupero di un'istanza eliminata. | 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 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.
In entrambi i casi, puoi eliminare la vecchia istanza al termine dell'operazione. Ti consigliamo di utilizzare la route di clonazione perché 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 per un'istanza è abilitata la protezione da eliminazione, conferma di voler eliminare l'istanza. Quindi disabilita la protezione da eliminazione prima di eliminare l'istanza. |
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 un flag da te fornito esplicitamente o impostato su un valore predefinito.
Innanzitutto, verifica che il valore del flag Se il flag |
Impossibile creare la replica di lettura: errore sconosciuto. | Probabilmente contiene un errore più specifico nei file di log.
Esamina i log in Cloud Logging per trovare l'errore effettivo.
Se l'errore è: |
Il disco è pieno. | 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 la memoria temporanea per memorizzare nella cache le operazioni di lettura richieste
più spesso, il che può comportare l'utilizzo di 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 |
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 temporaneo o permanente elevato per uno schema specifico. Alcune delle cause tipiche del ritardo della replica sono:
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 (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 della replica. Di conseguenza, una transazione a lunga esecuzione
sull'origine comporterebbe un ritardo di replica immediato di un elevato livello sulla
replica. Se il numero di modifiche delle righe nella transazione è elevato, anche la replica impiegherà molto tempo per eseguirla. Durante questo periodo, il ritardo della replica è in aumento. Una volta che la replica termina questa transazione, il periodo di recupero dipende dal carico di lavoro di scrittura sull'origine e dalla velocità di elaborazione della replica.
Per evitare una transazione lunga, alcune possibili soluzioni sono:
|
La modifica dei flag di replica parallela genera un errore. | Per uno o più di questi flag è stato impostato un valore errato.
Nell'istanza principale in cui viene visualizzato il messaggio di errore, imposta i flag di replica parallela:
|
La creazione della replica non riesce con il timeout. | Le transazioni non impegnate a lunga esecuzione sull'istanza principale possono causare un errore nella creazione della replica di lettura.
Ricrea la replica dopo aver interrotto tutte le query in esecuzione. |