Risoluzione dei problemi di Cloud SQL

Questa pagina include suggerimenti per la risoluzione dei problemi di Cloud SQL per i motori di database supportati. Alcuni di questi suggerimenti si applicano solo a motori di database specifici, mentre altri sono comuni a tutti.

Per suggerimenti per la risoluzione dei problemi relativi a motori di database specifici, consulta le pagine individuali:

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

Gli argomenti trattati in questa pagina includono:

Backup e ripristino

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

Esegui il comando gcloud sql operations list per elencare tutte le operazioni per l'istanza Cloud SQL specificata.

Vuoi scoprire chi ha emesso un'operazione di backup on demand. L'interfaccia utente non mostra l'utente che ha avviato un'operazione.

Cerca nei log e filtra per testo per trovare l'utente. Potresti dover utilizzare i log di controllo per informazioni private. I file di log pertinenti includono:

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

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

Se hai eseguito un'operazione di esportazione, crea una nuova istanza e poi esegui un'operazione di importazione per ricreare il database. Le esportazioni vengono scritte in Cloud Storage e le importazioni vengono lette da lì.

Un backup automatico è bloccato da molte ore e non può essere annullato. I backup possono richiedere molto tempo, a seconda delle dimensioni del database.

Se hai davvero bisogno di annullare l'operazione, puoi chiedere all' assistenza clienti di force restart l'istanza.

Un'operazione di ripristino può non riuscire quando uno o più utenti a cui viene fatto riferimento nel file di dump SQL non esistono. Prima di ripristinare un dump SQL, tutti gli utenti del database che sono proprietari di oggetti o a cui sono state concesse autorizzazioni per gli oggetti nel database di cui è stato eseguito il dump devono esistere nel database di destinazione. In caso contrario, l'operazione di ripristino non riesce a ricreare gli oggetti con la proprietà o le autorizzazioni originali.

Crea gli utenti del database prima di ripristinare il dump SQL.

Vuoi aumentare il numero di giorni per i quali puoi conservare i backup automatici da 7 a 30 giorni o più. Puoi configurare il numero di backup automatici da conservare. I backup automatici vengono eliminati regolarmente in base al valore di conservazione configurato. Purtroppo, ciò significa che i backup attualmente visibili sono gli unici backup automatici da cui puoi eseguire il ripristino.

Per conservare i backup a tempo indeterminato, puoi creare un backup on demand, in quanto non vengono eliminati come i backup automatici. I backup on demand rimangono per un periodo di tempo indefinito. ovvero rimangono finché non vengono eliminati o finché non viene eliminata l'istanza a cui appartengono. Poiché questo tipo di backup non viene eliminato automaticamente, può influire sulla fatturazione.

Un backup automatico non è andato a buon fine e non hai ricevuto una notifica via email. Per fare in modo che Cloud SQL ti invii una notifica sullo stato del backup, configura un avviso basato sui log.
Un'istanza non funziona ripetutamente perché alterna gli stati di errore e ripristino del backup. I tentativi di connessione e utilizzo del database dopo il ripristino non vanno a buon fine.
  • Potrebbero esserci troppe connessioni aperte. Un numero eccessivo di connessioni può derivare da errori che si verificano a metà di una connessione in cui non sono presenti impostazioni autovacuum per eliminare le connessioni inattive.
  • Il ciclo può verificarsi se un codice personalizzato utilizza una logica di ripetizione che non si interrompe dopo alcuni errori.
  • Il traffico potrebbe essere troppo elevato. Utilizza il pooling delle connessioni e altre best practice per la connettività.

Tentativi da effettuare

  1. Verifica che il database sia configurato per autovacuum.
  2. Controlla se nel codice personalizzato è configurata una logica di ripetizione della connessione.
  3. Riduci il traffico finché il database non viene ripristinato, poi aumentalo lentamente.
Ti accorgi che mancano dati durante l'esecuzione di un'operazione di backup/ripristino. Le tabelle sono state create come non registrate. Ad esempio:

CREATE UNLOGGED TABLE ....

Queste tabelle non sono incluse in un ripristino da un backup:

  • I contenuti delle tabelle non registrate non sopravvivono al failover su un'istanza HA.
  • Le tabelle non registrate non sopravvivono agli arresti anomali di Postgres.
  • Le tabelle non registrate non vengono replicate nelle repliche di lettura.
  • Le tabelle non registrate vengono cancellate automaticamente durante il ripristino del backup.

La soluzione è evitare di utilizzare tabelle non registrate se vuoi ripristinarle tramite un backup. Se esegui il ripristino da un database che contiene già tabelle non registrate, puoi eseguire il dump del database in un file e ricaricare i dati dopo aver modificato il file di dump da ALTER TABLE a SET LOGGED in queste tabelle.

Impossibile eliminare un'istanza quando scegli di eseguire un backup finale al momento dell'eliminazione dell'istanza. Quando elimini un'istanza, devi confermare se vuoi eseguire un backup finale dell'istanza prima di eliminarla. Se hai attivato il backup finale utilizzando l'impostazione dell'istanza final-backup, la selezione che effettui quando elimini l'istanza deve corrispondere alla configurazione dell'istanza del backup finale che hai impostato quando hai attivato il backup finale per l'istanza. Per risolvere il problema, procedi in uno dei seguenti modi:
  • Imposta il valore di backup finale in modo che corrisponda alla configurazione di backup esistente dell'istanza.
  • Lascia vuoto il campo Backup finale quando elimini l'istanza. Se lasci il campo vuoto, Cloud SQL utilizza la configurazione del backup finale impostata nelle impostazioni dell'istanza per eseguire un backup finale e definire la relativa conservazione.
Per visualizzare la configurazione finale dell'istanza di backup dell'istanza, consulta Visualizzare le informazioni sull'istanza.
Impossibile creare un'istanza di replica dopo aver creato correttamente un'istanza principale con l'impostazione di backup finale. Se crei una nuova istanza con l'impostazione dell'istanza di backup finale attivata, devi aggiornare il criterio dell'organizzazione di backup finale per applicare le configurazioni di backup solo all'istanza primaria. I backup finali non sono supportati per le istanze di replica.
Per saperne di più, consulta le policy dell'organizzazione Cloud SQL.

Clona

Problema Risoluzione dei problemi
La clonazione non riesce e viene visualizzato l'errore constraints/sql.restrictAuthorizedNetworks. L'operazione di clonazione è bloccata dalla configurazione Authorized Networks. Authorized Networks sono configurati per gli indirizzi IP pubblici nella sezione Connettività della console Google Cloud e la clonazione non è consentita a causa di considerazioni di sicurezza.

Rimuovi tutte le voci Authorized Networks dall'istanza Cloud SQL, se possibile. In caso contrario, crea una replica senza voci Authorized Networks.

Messaggio di errore: Failed to create subnetwork. Couldn't find free blocks in allocated IP ranges. Please allocate new ranges for this service provider. Help Token: [help-token-id].

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

Utilizza gcloud per clonare l'istanza e fornire un valore per il parametro
--allocated-ip-range-name. Per saperne di più, consulta Clonazione di un'istanza con un IP privato.

Connetti

Problema Risoluzione dei problemi
Aborted connection. Il problema potrebbe essere:
  • Instabilità Networking.
  • Nessuna risposta ai comandi TCP keep-alive (il client o il server non risponde, probabilmente sovraccarico)
  • Il lifetime della connessione al motore del database è stato superato e il server termina la connessione.

Le applicazioni devono tollerare gli errori di rete e seguire le best practice come il pooling delle connessioni e i nuovi tentativi. La maggior parte dei pool di connessioni rileva questi errori, se possibile. In caso contrario, l'applicazione deve riprovare o non riuscire in modo controllato.

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

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

La combinazione di questi metodi contribuisce a ridurre la limitazione.

Messaggio di errore: Login failed for user "" Potresti riscontrare questo errore di accesso durante l'autenticazione di Microsoft Entra ID. Per risolvere il problema, assicurati che esista un accesso SQL Server per questo utente Microsoft Entra ID.
Problemi di connettività di rete con istanze IP private Durante la configurazione dell'integrazione potresti riscontrare alcuni dei seguenti problemi:
  • Operazioni lente per creare accessi Microsoft Entra ID
  • Impossibile creare accessi Microsoft Entra ID
  • Impossibile connettersi all'istanza utilizzando l'autenticazione Microsoft Entra ID

Per saperne di più su come risolvere questi problemi, consulta Risoluzione dei problemi di integrazione di Microsoft Entra ID.

FATAL: database 'user' does not exist. gcloud sql connect --user funziona solo con l'utente postgres predefinito.

Connettiti all'utente predefinito, poi cambia utente.

Vuoi scoprire chi è connesso. Accedi al database ed esegui questo comando:

SELECT datname,
usename,
application_name as appname,
client_addr,
state,
now() - backend_start as conn_age,
now() - state_change as last_activity_age
FROM pg_stat_activity
WHERE backend_type = 'client backend'
ORDER BY 6 DESC
LIMIT 20
   

Creare istanze

Problema Risoluzione dei problemi
Messaggio di errore: The zone or region does not have sufficient resources to handle the request at the moment.

La zona selezionata non dispone della capacità per le risorse richieste o il tipo di VM al momento della richiesta di creazione dell'istanza. Al momento della richiesta, potrebbe esserci un'elevata domanda operativa simultanea in quella specifica posizione regionale.

Per risolvere il problema, riprova a creare l'istanza in un'altra zona o riprova a creare l'istanza nella stessa zona che ha ricevuto l'errore in un altro momento della giornata.

Messaggio di errore: Failed to create subnetwork. Couldn't find free blocks in allocated IP ranges. Please allocate new ranges for this service provider. Non sono disponibili altri indirizzi nell'intervallo IP allocato. Possono verificarsi diversi scenari possibili:
  • La dimensione dell'intervallo IP allocato per la connessione di servizio privato è inferiore a /24.
  • La dimensione dell'intervallo IP allocato per la connessione di servizio privato è troppo piccola per il numero di istanze Cloud SQL.
  • Il requisito relativo alle dimensioni dell'intervallo IP allocato sarà maggiore se le istanze vengono create in più regioni. Vedi dimensioni dell'intervallo allocato

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

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

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

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

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

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

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

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

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

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

gcloud services enable servicenetworking.googleapis.com \
--project=PROJECT_ID
    
Messaggio di errore: Failed to create subnetwork. Required 'compute.projects.get' permission for PROJECT_ID. Quando crei un'istanza utilizzando un indirizzo IP privato, viene creato un service account just-in-time utilizzando l'API Service Networking. Se hai abilitato di recente l'API Service Networking, ilaccount di serviziot potrebbe non essere creato e la creazione dell'istanza non riesce. In questo caso, devi attendere che il account di servizio si propaghi in tutto il sistema o aggiungerlo manualmente con le autorizzazioni richieste.
Messaggio di errore: More than 3 subject alternative names are not allowed. Stai tentando di utilizzare un SAN personalizzato per aggiungere più di tre nomi DNS al certificato del server di un'istanza Cloud SQL. Non puoi aggiungere più di tre nomi DNS all'istanza.
Messaggio di errore: Subject alternative names %s is too long. The maximum length is 253 characters. Assicurati che i nomi DNS che vuoi aggiungere al certificato del server di un'istanza Cloud SQL non superino i 253 caratteri.
Messaggio di errore: Subject alternative name %s is invalid.

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

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

Esporta

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

Utilizza le esportazioni CSV per esportare solo ciò che ti serve.

L'esportazione sta richiedendo troppo tempo. Cloud SQL non supporta le operazioni sincrone simultanee.

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

Errore durante la creazione dell'estensione. Il file di dump contiene riferimenti a un'estensione non supportata.

Modifica il file di dump per rimuovere i riferimenti.

Errore durante l'utilizzo di pg_dumpall. L'utilizzo dell'utilità pg_dumpall con il flag --global richiede il ruolo superuser, ma questo ruolo non è supportato in Cloud SQL. Per evitare errori durante l'esecuzione di operazioni di esportazione che includono nomi utente, utilizza anche il flag --no-role-passwords.
L'operazione di esportazione scade prima di esportare qualsiasi elemento e viene visualizzato il messaggio di errore Could not receive data from client: Connection reset by peer. Se Cloud Storage non riceve dati entro un determinato intervallo di tempo, in genere circa sette minuti, la connessione viene reimpostata. È possibile che l'esecuzione della query di esportazione iniziale richieda troppo tempo.

Esegui un'esportazione manuale utilizzando lo strumento pg_dump.

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 Google Cloud prodotti come Cloud Scheduler, Pub/Sub e Cloud Run Functions, in modo simile 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 primaria esterna sia disponibile per la connessione. Puoi anche modificare i valori dei flag net_read_timeout e net_write_timeout nell'istanza di origine per interrompere l'errore. Per saperne di più sui valori consentiti per questi flag, consulta Configura 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

Il dump iniziale non riesce a causa di errori di timeout o di connessione persa (ad esempio, Dump timeout o Lost connection to MySQL server). Questo errore può verificarsi se una o più istruzioni DDL interagiscono con il processo di dump parallelo, causando l'attesa indefinita del processo.

Soluzione:non eseguire istruzioni DDL sul database di origine durante la fase di dump iniziale. Prima di eseguire qualsiasi istruzione DDL, riavvia la migrazione e attendi il completamento della fase di dump iniziale.

La migrazione iniziale dei dati è stata completata, ma non vengono replicati dati.

Una possibile causa principale potrebbe essere che il database di origine ha definito flag di replica che comportano la mancata replica di alcune o di tutte le modifiche al database.

Assicurati che i flag di replica come binlog-do-db, binlog-ignore-db, replicate-do-db o replicate-ignore-db non siano impostati in modo conflittuale.

Esegui il comando show master status sull'istanza primaria per visualizzare le impostazioni correnti.

La migrazione iniziale dei dati è stata completata, ma la replica dei dati smette di funzionare dopo un po' di tempo.

Tentativi da effettuare

  • Controlla le metriche di replica per l'istanza di replica nella sezione Cloud Monitoring della console Google Cloud .
  • Gli errori del thread I/O o SQL di MySQL sono disponibili in Cloud Logging nei file di log mysql.err.
  • L'errore può essere rilevato anche durante la connessione all'istanza di replica. Esegui il comando SHOW REPLICA STATUS e controlla i seguenti campi nell'output:
    • Replica_IO_Running
    • Replica_SQL_Running
    • Last_IO_Error
    • Last_SQL_Error

Se visualizzi l'errore Unknown database DATABASE_NAME on query. Error_code: MY-001049, la replica non è riuscita perché un'istruzione SQL replicata tenta di fare riferimento a un database non selezionato per la migrazione. Per recuperare la replica, determina se l'errore in base al messaggio è dovuto a DDL su uno dei seguenti oggetti:

  • Un evento o una routine. Puoi eseguire CALL mysql.skipReplicationError() sulla replica, il che impedirà la replica dell'evento o della routine e riprenderà la replica.
  • Un vincolo o una vista di chiave esterna. Dopo aver stabilito in quale database si trova l'oggetto modificato dall'istruzione, hai due opzioni per il recupero. Puoi rimuovere il database dai database selezionati che vengono migrati oppure puoi eseguire CALL mysql.skipReplicationError() sulla replica per riprendere la replica ignorando il vincolo o la propagazione della visualizzazione alla replica.
mysqld check failed: data disk is full. Il disco di dati dell'istanza di replica è pieno.

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

Replica esterna

Problema Risoluzione dei problemi
Messaggio di errore: The slave is connecting ... master has purged binary logs containing GTIDs that the slave requires. L'istanza Cloud SQL principale dispone di backup automatici e log binari e il recupero point-in-time è abilitato, quindi dovrebbe avere log sufficienti per consentire alla replica di recuperare. Tuttavia, in questo caso, anche se i log binari esistono, la replica non sa da quale riga iniziare a leggere.

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

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

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

    Scopri di più.

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

Bandiere