Risoluzione dei problemi di Cloud SQL

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

Per suggerimenti sulla risoluzione dei problemi relativi a motori del database specifici, consulta le singole pagine:

Controlla se la tua domanda o il tuo problema sono già stati trattati 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 corrente. La console Google Cloud segnala solo l'esito positivo o negativo al termine dell'operazione. Non è progettato per mostrare avvisi o altri aggiornamenti.

Esegui il comando gcloud sql operations list per elencare tutte le operazioni per l'istanza Cloud SQL specificata.
Vuoi scoprire chi ha eseguito un'operazione di backup on demand. L'interfaccia utente non mostra l'utente che ha avviato un'operazione.

Cerca nei log e filtra per testo per trovare l'utente. Potresti dover utilizzare i log di controllo per le 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.
Dopo l'eliminazione di un'istanza, non puoi eseguirne il backup.

Se elimini un'istanza senza eseguire un backup finale dei dati, non sarà possibile il recupero dati. Tuttavia, se ripristini l'istanza, Cloud SQL ripristina anche i backup. Per saperne di più sul recupero di un'istanza eliminata, consulta Conserva 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 cui 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, questo 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 vengono conservati a tempo indeterminato. In altre parole, 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 è 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.
Un backup automatico o on demand non va a buon fine su un'istanza con più di 50 etichette definite dall'utente. Quando Cloud SQL esegue un backup, copia le etichette definite dall'utente dell'istanza nello snapshot di archiviazione sottostante e aggiunge le etichette di sistema interne. Se il numero combinato di etichette supera il limite di 64 etichette per gli snapshot, il backup non va a buon fine.

Per risolvere il problema, rimuovi le etichette in eccesso in modo che l'istanza abbia 50 o meno etichette definite dall'utente. Per saperne di più, consulta Etichetta le istanze.
Un'istanza non riesce ripetutamente perché passa ciclicamente dallo stato di errore a quello di 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ò essere causato da errori che si verificano nel mezzo 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 pool di 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 si riprende, quindi aumentalo lentamente.
Ti accorgi che mancano dei dati durante un'operazione di backup/ripristino. Le tabelle sono state create senza log. Ad esempio:

CREATE UNLOGGED TABLE ....

Queste tabelle non sono incluse nel ripristino da un backup:

  • I contenuti delle tabelle non registrate non sopravvivono al failover su un'istanza ad alta affidabilità.
  • 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 su queste tabelle.
Impossibile eliminare un'istanza quando scegli di eseguire un backup finale durante l'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 di backup finale impostata quando hai attivato il backup finale per l'istanza. Per mitigare questo 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 del 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 definirne la conservazione.
Per visualizzare la configurazione dell'istanza di backup finale dell'istanza, consulta Visualizza 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 abilitata, devi aggiornare la policy dell'organizzazione per il backup finale per applicare le configurazioni di backup solo all'istanza principale. I backup finali non sono supportati per le istanze di replica.
Per saperne di più, consulta Policy dell'organizzazione di Cloud SQL.

Clona

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

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

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

Utilizza gcloud per clonare l'istanza e fornire un valore per il parametro --allocated-ip-range-name
. 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 keep-alive TCP (il client o il server non risponde, probabilmente è sovraccarico)
  • La durata della connessione al motore del database è stata superata e il server termina la connessione.

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

Per i nuovi tentativi di 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 randomizzato.

La combinazione di questi metodi aiuta a ridurre la limitazione.
Timeout della connessione o errore di connessione generico quando si utilizza l'IP privato o il peering di rete VPC.

I tentativi di connessione non riescono con errori di timeout o di connessione generici senza dettagli diagnostici.

Procedura per la risoluzione del problema:

  1. Esegui un test di connettività di Network Intelligence Center tra il client di origine e l'IP privato di Cloud SQL sulla porta del database (3306 per MySQL, 5432 per PostgreSQL o 1433 per SQL Server). Il test traccia il percorso dei pacchetti e identifica se il traffico viene interrotto da regole firewall, route mancanti o configurazioni errate del peering.
  2. Verifica che lo stato della connessione del peering di rete VPC sia ACTIVE.
  3. Verifica che le regole firewall nella rete VPC consentano il traffico in entrata sulla porta del database.
  4. Se utilizzi intervalli di indirizzi non RFC 1918, verifica di aver aggiornato la configurazione del peering per esportare le route di subnet con IP pubblico.

Per ulteriori dettagli e comandi di diagnostica gcloud, consulta Diagnostica gli errori di connessione alla rete VPC e all'IP privato.
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 a SQL Server per questo utente Microsoft Entra ID.
Problemi di connettività di rete con istanze con IP privato Durante la configurazione dell'integrazione, potresti riscontrare alcuni dei seguenti problemi:
  • Operazioni lente per la creazione di 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 con l'utente predefinito, quindi 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 di capacità sufficiente per le risorse richieste o per 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 località 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 momento diverso 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 più disponibili indirizzi nell'intervallo IP allocato. Possono esserci diversi scenari possibili:
  • La dimensione dell'intervallo IP allocato per la connessione al servizio privato è inferiore a /24.
  • La dimensione dell'intervallo IP allocato per la connessione di servizi privati è 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 servizi privati. Per saperne di più, consulta Alloca 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, assicurati di aumentare solo l'intervallo di allocazione e non di 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 inizi con un'allocazione /24, decrementare la /maschera di 1 per ogni condizione (gruppo di tipi di istanze aggiuntivo, regione aggiuntiva) è una buona regola generale. Ad esempio, se provi a creare entrambi i gruppi di tipi di istanze 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 comando seguente e prova a creare nuovamente 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 attivato l'API Service Networking solo di recente, il account di servizio potrebbe non essere creato e la creazione dell'istanza non riesce. In questo caso, devi attendere che il account di servizio venga propagato 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 contengano più di 253 caratteri.
Messaggio di errore: Subject alternative name %s is invalid.

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

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

Esegui SQL utilizzando l'API Data

Problema Risoluzione dei problemi
The instance doesn't allow using ExecuteSql to access this instance. You can allow it by patching the instance with {settings: { dataApiAccess: "ALLOW_DATA_API" }} L'API di dati è disattivata per impostazione predefinita. Abilita l'API di dati sull'istanza per risolvere il problema.
Secret cannot be provided when auto_iam_authn is true. Quando imposti auto_iam_authn su true, esegui l'autenticazione nel database utilizzando IAM. Questo metodo di autenticazione non richiede una password o un secret. Consulta Autenticati utilizzando IAM.
ExecuteSql API is not supported for instances in certain Assured Workloads control packages folders yet. Lo script SQL e la relativa risposta di esecuzione potrebbero transitare attraverso località intermedie tra il client e la località dell'istanza di destinazione. Per questo motivo, le richieste non andranno a buon fine per le istanze in determinati progetti Assured Workloads. Se il tuo progetto non è registrato in Assured Workloads, ma constraints/sql.restrictNoncompliantResourceCreation viene applicato manualmente, chiedi all'amministratore della tua organizzazione di rimuovere il vincolo. Il problema verrà risolto nelle istanze appena create.
The database is currently unavailable. L'istanza potrebbe essere in fase di riavvio, in manutenzione o in uno stato non integro. Controlla lo stato dell'istanza e riprova più tardi.

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 per l'istanza Cloud SQL (che esegue l'esportazione) disponga del ruolo Storage Object Creator (roles/storage.objectCreator) per consentire l'esportazione nel bucket. Consulta Ruoli IAM per Cloud Storage.
L'esportazione in CSV è riuscita, ma l'esportazione in SQL non è andata a buon fine. 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 ti consente di definire quali elementi del database includere nell'esportazione.

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

Utilizza l' offload delle esportazioni. In generale, nell'offload dell'esportazione, invece di eseguire un'esportazione nell'istanza di origine, Cloud SQL avvia un'istanza di offload per eseguire l'esportazione. L'offload dell'esportazione offre diversi vantaggi, tra cui un aumento delle prestazioni nell'istanza di origine e lo sblocco delle operazioni amministrative durante l'esecuzione dell'esportazione. Con l'offload dell'esportazione, 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 è di dimensioni ridotte, potresti notare un aumento della latenza.
Errore di 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 di super utente, ma questo ruolo non è supportato in Cloud SQL. Per evitare che si verifichino 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 periodo di tempo, in genere circa sette minuti, la connessione viene reimpostata. È possibile che la query di esportazione iniziale richieda troppo tempo per l'esecuzione.

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 prodotti Google Cloudcome Cloud Scheduler, Pub/Sub e Cloud Run Functions, in modo simile a questo articolo sulla creazione di backup automatici.

Principale esterno

Problema Risoluzione dei problemi
Lost connection to MySQL server during query when dumping table. La sorgente 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 interrompere l'errore. Per ulteriori informazioni sui valori consentiti per questi flag, consulta Configura i flag di database.

Per scoprire di più sull'utilizzo dei flag mysqldump per la migrazione di importazione gestita, consulta Flag di sincronizzazione iniziale consentiti e predefiniti
Il dump iniziale non riesce con 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.

Risoluzione: 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 è riuscita, ma non viene eseguita la replica dei dati.

Una possibile causa principale potrebbe essere che il database di origine ha definito flag di replica che impediscono 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'.

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 MySQL o del thread SQL 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 trovi l'errore Unknown database DATABASE_NAME on query. Error_code: MY-001049, la replica non è riuscita perché un'istruzione SQL replicata ha tentato di fare riferimento a un database che non è stato selezionato per la migrazione. Per recuperare la replica, determina se l'errore basato sul messaggio è dovuto a DDL su uno dei seguenti oggetti:

  • Un evento o una routine. Puoi eseguire CALL mysql.skipReplicationError() sulla replica, in modo da impedire la replica dell'evento o della routine e riprendere 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 di cui è in corso la migrazione 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 dati dell'istanza di replica è pieno.

Aumenta le dimensioni 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. Nell'istanza Cloud SQL principale sono abilitati i backup automatici, i log binari e il recupero point-in-time, quindi dovrebbero essere presenti log sufficienti per consentire alla replica di recuperare il ritardo. Tuttavia, in questo caso, anche se i log binari esistono, 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 quel file

  1. Connettiti al tuo client mysql tramite un'istanza 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.

Bandiere

Problema Risoluzione dei problemi

Alta affidabilità

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

Modifica l'istanza per eseguire l'upgrade a una macchina di dimensioni maggiori e ottenere più CPU e memoria.

Importa

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.
L'operazione di importazione richiede troppo tempo. Un numero eccessivo di connessioni attive può interferire con le operazioni di importazione.

Chiudi le operazioni non utilizzate. Controlla l'utilizzo di CPU e memoria utilizzata della tua istanza Cloud SQL per assicurarti che siano disponibili risorse sufficienti. Il modo migliore per garantire le risorse massime per l'importazione è riavviare l'istanza prima di avviare l'operazione.

Un riavvio:

  • Chiude tutte le connessioni.
  • Termina tutte le attività che potrebbero consumare risorse.
Un'operazione di importazione può non riuscire quando uno o più utenti a cui viene fatto riferimento nel file di dump non esistono. Prima di importare un file di dump, 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 importazione non riesce a ricreare gli oggetti con la proprietà o le autorizzazioni originali.

Crea gli utenti del database prima di eseguire l'importazione.
Un'operazione di importazione non riesce e viene visualizzato un errore che indica che una tabella non esiste. 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 l'operazione di importazione è in corso 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.

Integrazione con Vertex AI

Problema Risoluzione dei problemi
Messaggio di errore: Google ML Integration API is not supported on shared core instance. Please upsize your machine type. Se hai selezionato un core condiviso per il tipo di macchina della tua istanza, non puoi abilitare l'integrazione di Vertex AI in Cloud SQL. Esegui l'upgrade del tipo di macchina a un core dedicato. Per saperne di più, consulta Tipo di macchina.
Messaggio di errore: Google ML Integration is unsupported for this maintenance version. Please follow https://cloud.google.com/sql/docs/mysql/self-service-maintenance to update the maintenance version of the instance. Per abilitare l'integrazione di Vertex AI in Cloud SQL, la versione di manutenzione dell'istanza deve essere R20240130 o successiva. Per eseguire l'upgrade dell'istanza a questa versione, consulta Manutenzione self-service.
Messaggio di errore: Cannot invoke ml_predict_row if 'cloudsql.enable_google_ml_integration' is off. Il flag di database cloudsql.enable_google_ml_integration è disattivato. Cloud SQL non può integrarsi con Vertex AI.

Per attivare questo flag, utilizza il comando gcloud sql instances patch:

gcloud sql instances patch INSTANCE_NAME --database-flags cloudsql.enable_google_ml_integration=on

Sostituisci INSTANCE_NAME con il nome dell'istanza Cloud SQL principale.
Messaggio di errore: Failed to connect to remote host: Connection refused. L'integrazione tra Cloud SQL e Vertex AI non è abilitata. Per abilitare questa integrazione, utilizza il comando gcloud sql instances patch:

gcloud sql instances patch INSTANCE_NAME
--enable-google-ml-integration

Sostituisci INSTANCE_NAME con il nome dell'istanza Cloud SQL principale.
Messaggio di errore: Vertex AI API has not been used in project PROJECT_ID before or it is disabled. Enable it by visiting /apis/api/aiplatform.googleapis.com/overview?project=PROJECT_ID then retry. L'API Vertex AI non è abilitata. Per saperne di più sull'abilitazione di questa API, consulta Abilita l'integrazione del database con Vertex AI.
Messaggio di errore: Permission 'aiplatform.endpoints.predict' denied on resource. Le autorizzazioni Vertex AI non vengono aggiunte al account di servizio Cloud SQL per il progetto in cui si trova l'istanza Cloud SQL. Per ulteriori informazioni sull'aggiunta di queste autorizzazioni al account di servizio, consulta Concedi al account di servizio Cloud SQL le autorizzazioni di Identity and Access Management (IAM) per accedere a Vertex AI.
Messaggio di errore: Publisher Model `projects/PROJECT_ID/locations/REGION_NAME/publishers/google/models/MODEL_NAME` not found. Il modello di machine learning o l'LLM non esiste in Vertex AI.
Messaggio di errore: Resource exhausted: grpc: received message larger than max. Le dimensioni della richiesta che Cloud SQL passa a Vertex AI superano il limite gRPC di 4 MB per richiesta.
Messaggio di errore: Cloud SQL attempts to send a request to Vertex AI. However, the instance is in the %s region, but the Vertex AI endpoint is in the %s region. Make sure the instance and endpoint are in the same region. Cloud SQL tenta di inviare una richiesta a Vertex AI. Tuttavia, l'istanza si trova in una regione, ma l'endpoint Vertex AI si trova in un'altra regione. Per risolvere il problema, l'istanza e l'endpoint devono trovarsi nella stessa regione.
Messaggio di errore: The Vertex AI endpoint isn't formatted properly. L'endpoint Vertex AI non è formattato correttamente. Per saperne di più, consulta Utilizza endpoint privati per la previsione online.
Messaggio di errore: Quota exceeded for aiplatform.googleapis.com/online_prediction_requests_per_base_model with base model: textembedding-gecko. Il numero di richieste che Cloud SQL passa a Vertex AI supera il limite di 1500 richieste al minuto per regione per modello per progetto.

Server collegati

Problema Risoluzione dei problemi
Msg 7411, Level 16, State 1, Line 25

Server 'LINKED_SERVER_NAME' is not configured for DATA ACCESS. 		L'opzione DataAccess è disattivata. Esegui il seguente comando per abilitare l'accesso ai dati:
EXEC sp_serveroption
    @server='LINKED_SERVER_NAME',
    @optname='data access',
    @optvalue='TRUE'

Sostituisci LINKED_SERVER_NAME con il nome del server collegato.

Access to the remote server is denied because no login-mapping exists. (Microsoft SQL Server, Error: 7416) Se riscontri questo problema durante la creazione di una connessione criptata, devi provare un altro modo per fornire l'ID utente quando accedi al server collegato. Per farlo, esegui questo comando: 
EXEC master.dbo.sp_addlinkedserver
   @server = N'LINKED_SERVER_NAME',
   @srvproduct= N'',
   @provider= N'MSOLEDBSQL',
   @datasrc= N'TARGET_SERVER_ID',
   @provstr= N'Encrypt=yes;TrustServerCertificate=yes;User ID=USER_ID'

Sostituisci quanto segue:

  • LINKED_SERVER_NAME con il nome del server collegato.
  • TARGET_SERVER_ID con il nome del server di destinazione o l'indirizzo IP e il numero di porta del server di destinazione.
  • USER_ID con l'utente che esegue l'accesso.
Comportamento imprevisto Se riscontri un comportamento imprevisto, assicurati di utilizzare un provider supportato. Per saperne di più, consulta la documentazione di Microsoft.

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 guidata dall'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.
Le informazioni sulle operazioni non vengono trovate nei log. Vuoi trovare ulteriori informazioni su un'operazione.

Ad esempio, un utente è stato eliminato, ma non riesci a scoprire chi lo ha fatto. I log mostrano che l'operazione è iniziata, ma non forniscono ulteriori informazioni. Devi attivare l'audit logging per registrare informazioni dettagliate e che consentono l'identificazione personale (PII) come queste.
Alcuni log vengono filtrati dal log error.log di un'istanza Cloud SQL per SQL Server. I log filtrati includono i log AD senza timestamp e includono: Login failed for user 'x'. Reason: Token-based server access validation failed with an infrastructure error. Login lacks connect endpoint permission. [CLIENT: 127.0.0.1]. Questi log vengono filtrati perché potrebbero causare confusione.
Il logging sta utilizzando molto spazio su disco. Esistono tre tipi di file di log che utilizzano spazio su disco: redo log, log generali e log binari.

Connettiti al database ed esegui questi comandi per i dettagli su ogni 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 testo.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 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
I log delle query non vengono trovati nei log di PostgreSQL. Devi attivare i flag pgaudit.
  1. Da un terminale, connettiti al tuo database: 
    gcloud sql connect INSTANCE_NAME
  2. Esegui questo comando per creare l'estensione: 
    CREATE EXTENSION pgaudit;
  3. Esci dal database ed esegui questo comando da un terminale: 
    gcloud sql instances patch INSTANCE_NAME \
--database-flags=cloudsql.enable_pgaudit=on,pgaudit.log=all

Gestisci le istanze

Problema Risoluzione dei problemi
Vuoi scoprire cosa sta occupando spazio di archiviazione. Ad esempio, noti che il tuo database utilizza solo 3 GB, ma lo spazio di archiviazione mostra che sono in uso 14 GB. Lo spazio non utilizzato dalle tabelle del database viene in genere utilizzato dai log delle transazioni, dai file temporanei o da altri log.

Puoi visualizzare una suddivisione dell'utilizzo del disco dell'istanza per tipo di dati utilizzando la metrica cloudsql.googleapis.com/database/disk/bytes_used_by_data_type in Esplora metriche o il grafico Spazio di archiviazione su disco per tipo nella dashboard Insight di sistema.

Tentativi da effettuare

  • Per Cloud SQL per MySQL, la metrica database/disk/bytes_used_by_data_type suddivide l'utilizzo dello spazio di archiviazione tra Data, Binlog, Tmp_data, Temporary files, Redo_log, Undo_log, General_log, Slow_log, Relaylog, Cloudsql_mysql_audit_log e Other. Per saperne di più, consulta Risolvi i problemi relativi all'utilizzo elevato del disco.
  • Puoi controllare lo spazio di archiviazione occupato dai log binari utilizzando il seguente comando nell'interfaccia a riga di comando MySQL: SHOW BINARY LOGS;
  • Anche le tabelle temporanee potrebbero occupare una quantità significativa di spazio 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 redo log: SHOW VARIABLES LIKE 'innodb_log_file%';
  • Puoi controllare le dimensioni di general_log, se è abilitato, 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 saperne di più, consulta la pagina di riferimento di instances.truncateLog.
  • Scopri di più sull'impostazione e sulla configurazione dei log delle query lente.
  • Per Cloud SQL per PostgreSQL, la metrica database/disk/bytes_used_by_data_type suddivide l'utilizzo dello spazio di archiviazione tra Data, Wal (log write-ahead), Archived_wal_log (log write-ahead archiviati quando i log di recupero point-in-time sono archiviati su disco), Tmp_data, Audit_log, Replication_slot e Other.
  • Per controllare le dimensioni di ogni database nell'istanza Cloud SQL per PostgreSQL, connettiti al database ed esegui questa query: SELECT pg_database.datname, pg_size_pretty(pg_database_size(pg_database.datname)) AS size FROM pg_database;
  • Per verificare se i log di recupero point-in-time (PITR) sono archiviati su disco o in Cloud Storage, consulta Controlla la posizione di archiviazione dei log delle transazioni utilizzati per il PITR.
  • Per Cloud SQL per SQL Server, la metrica database/disk/bytes_used_by_data_type suddivide l'utilizzo del disco dell'istanza in Data, pitr_transaction_log_backups (backup dei log delle transazioni archiviati su disco per il recupero point-in-time), Logs, error_logs, memory_dumps e Other.
  • Per controllare la suddivisione dello spazio di archiviazione tra i file di dati (ROWS) e i file di log delle transazioni (LOG) all'interno di un database Cloud SQL per SQL Server, connettiti al database ed esegui una query su sys.database_files: 
    SELECT name, type_desc,
  size * 8 / 1024.0 AS size_mb,
  FILEPROPERTY(name, 'SpaceUsed') * 8 / 1024.0 AS space_used_mb
FROM sys.database_files;
     Puoi anche eseguire DBCC SQLPERF(LOGSPACE); per controllare le dimensioni del log delle transazioni e lo spazio utilizzato in tutti i database dell'istanza.
  • Per verificare se i backup dei log delle transazioni di recupero point-in-time (PITR) sono archiviati su disco o in Cloud Storage, consulta Controlla la posizione di archiviazione dei log delle transazioni utilizzati per il PITR.
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 andata e ritorno al backend per ottenere i dati. Di conseguenza, le query possono essere più lente del previsto finché la cache non viene riempita.
Ripristino lento in caso di arresto anomalo. Potrebbe essersi accumulato un general_log di grandi dimensioni. Puoi ridurre il tempo di ripristino dopo un arresto anomalo impedendo l'accumulo di un general_log di grandi dimensioni. Se hai attivato general_log, tronca la tabella e attiva general_log solo per brevi periodi di tempo.

Puoi scoprire le dimensioni dei log generali connettendoti al database ed eseguendo questa query:

SELECT ROUND(SUM(LENGTH(argument)/POW(1024,2)),2) from mysql.general_log;
Le query sono bloccate. È possibile che le query blocchino il database MySQL, causando il blocco/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 il blocco, che gli elementi successivi stanno aspettando.

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 dei file temporanei, connettiti al database ed esegui la seguente 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 la seguente query:

SELECT TABLE_SCHEMA, TABLE_NAME, sum(DATA_LENGTH+INDEX_LENGTH)/pow(1024,2) FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA NOT IN ('PERFORMANCE_SCHEMA','INFORMATION_SCHEMA','SYS','MYSQL') GROUP BY TABLE_SCHEMA, TABLE_NAME;
mysqld got a signal 11. Prova a rifattorizzare le 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. Il pulitore di pagine non riesce a tenere il passo con la frequenza di modifica dell'istanza. Una volta al secondo, il pulitore delle pagine esegue la scansione del pool di buffer alla ricerca di pagine modificate di cui eseguire il flush dal pool di buffer al disco. L'avviso che vedi mostra che sono presenti molte pagine dirty da svuotare e che è necessario più di un secondo per svuotare un batch di pagine sul disco.

Esegui lo sharding dell'istanza, se possibile. È meglio utilizzare molte istanze Cloud SQL più piccole anziché un'unica istanza di grandi dimensioni.
Vuoi scoprire quali query sono in esecuzione in questo momento. Connettiti al database ed esegui questa query:

SELECT datname, username, application_name as appname, client_addr, state, now() - backend_start as conn_age, now() - xact_start as xact_age, now() - query_start as query_age, now() - state_change as last_activity_age, wait_event_type, wait_event, query FROM pg_stat_activity WHERE state <> 'idle' ORDER BY 8 DESC LIMIT 20;

Vuoi scoprire quali unità vengono utilizzate per un campo specifico. Connettiti al database ed esegui questa query (utilizzando il tuo FIELD_NAME):

SELECT name, setting, unit FROM pg_settings WHERE name = 'FIELD_NAME'.
Vuoi trovare il valore attuale di un'impostazione del database. Connettiti al database ed esegui la seguente query (utilizzando il tuo SETTING_NAME):

SHOW SETTING_NAME;

Esegui SHOW ALL; per visualizzare tutte le impostazioni.
Vuoi interrompere un processo in background bloccato. L'utente deve avere il ruolo pg_signal_backend.

Esegui questi comandi:

  1.       GRANT pg_signal_backend TO USERNAME;
  2. Trova l'ID di processo del processo bloccato o in stallo: 
          SELECT pid, username, state, query FROM pg_stat_activity;
  3. Arresta un processo in esecuzione o inattivo utilizzando questi comandi: 
          SELECT pg_cancel_backend(pid)
            FROM pg_stat_activity
            WHERE username = 'USERNAME';
      
      
          SELECT pg_terminate_backend(pid)
            FROM pg_stat_activity
            WHERE username = 'USERNAME';
L'istanza sta per raggiungere il 100% di consumo degli ID transazione. Il monitoraggio interno ti avvisa che l'istanza sta per raggiungere il 100% di utilizzo degli ID transazione. Vuoi evitare il wraparound delle transazioni, che può bloccare le scritture.

Il job di autovacuum potrebbe essere bloccato o non recuperare gli ID transazione abbastanza velocemente da stare al passo con il workload.

Per evitare interruzioni dovute al problema di wraparound delle transazioni, puoi consultare questi suggerimenti self-service per gestire il wraparound TXID.

Per consigli generali sull'ottimizzazione, consulta Ottimizzazione, monitoraggio e risoluzione dei problemi delle operazioni vacuum in PostgreSQL.
Lo spazio di archiviazione temporaneo ha aumentato lo spazio di archiviazione automatico. Lo spazio di archiviazione automatico è abilitato.

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

Controlla i log intorno all'ora dell'eliminazione e verifica se è in esecuzione uno script non autorizzato da una dashboard o da un altro processo automatico.
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 o l'istanza potrebbe avere uno stato con flag INSTANCE_RISKY_FLAG_CONFIG.

Ecco alcune possibili spiegazioni:

  • È in corso un'altra operazione. Le operazioni Cloud SQL non vengono eseguite contemporaneamente. Attendi il completamento dell'altra operazione.
  • L'avviso INSTANCE_RISKY_FLAG_CONFIG viene attivato ogni volta che viene utilizzato almeno un flag beta. Rimuovi le impostazioni dei flag rischiosi e riavvia l'istanza
L'istanza è bloccata a causa delle dimensioni elevate dei dati temporanei. Il sistema può creare molte tabelle temporanee contemporaneamente, a seconda delle query e del carico.

Purtroppo, non è possibile ridurre le dimensioni del file ibtmp1 con un metodo diverso dal riavvio del servizio.

Un'opzione di mitigazione consiste nel creare la tabella temporanea con ROW_FORMAT=COMPRESSED, in modo che venga archiviata in tablespace file-per-table nella directory dei file temporanei. Tuttavia, lo svantaggio è rappresentato dai costi di prestazioni associati alla creazione e alla rimozione di un tablespace file-per-table per ogni tabella temporanea.
Errore irreversibile durante l'upgrade. I log potrebbero rivelare ulteriori informazioni, ma in ogni caso potrebbe essere necessaria l'assistenza clienti per forzare la ricreazione dell'istanza.
L'istanza è bloccata in fase di 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 va 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 si trovano in Cloud SQL.
Arresto lento al riavvio. Quando un'istanza viene arrestata, le connessioni in sospeso che non terminano entro 60 secondi rendono l'arresto non corretto.

Se le connessioni durano meno di 60 secondi, è possibile evitare la maggior parte degli arresti non corretti, incluse le connessioni dal prompt dei comandi del database. Se mantieni queste connessioni aperte per ore o giorni, gli arresti potrebbero non essere corretti.
Un utente non può essere eliminato. L'utente probabilmente ha oggetti nel database che dipendono da questo. Devi eliminare questi oggetti o riassegnarli a un altro utente.

Scopri quali oggetti dipendono dall'utente, quindi eliminali o riassegnali a un altro utente.
Query particolari vengono eseguite lentamente. 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 (writer o reader) e la risorsa di destinazione (Cloud SQL) si trovano in regioni diverse.

In particolare, consulta i suggerimenti generali sul rendimento.

Per inserimenti, aggiornamenti o eliminazioni lenti nel database, prendi in considerazione le seguenti azioni:

  • Controlla le località del writer 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 ancora più che sulle prestazioni di scrittura

Per ridurre la latenza, si consiglia di posizionare le risorse di origine e di destinazione nella stessa regione.
Viene indicato un out of memory, ma i grafici di monitoraggio non lo mostrano. Un'istanza può non riuscire e segnalare Out of memory, ma i grafici della console Google Cloud o di Cloud Monitoring sembrano mostrare che rimane ancora memoria.

Esistono altri fattori oltre al workload che possono influire sull'utilizzo della memoria, come il numero di connessioni attive e i processi di overhead interni. Questi non vengono sempre visualizzati nei grafici di monitoraggio.

Assicurati che l'istanza abbia un overhead sufficiente per tenere conto del workload, più un overhead aggiuntivo.
Recupero di un'istanza eliminata. Tutti i dati di 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 evitare 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. In questo modo, puoi creare la nuova istanza senza dover importare i dati manualmente. Come quando crei una nuova istanza, l'istanza 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 che preferisci e poi importare i dati nella nuova istanza.

In entrambi i casi, puoi eliminare la vecchia istanza al termine dell'operazione. Ti consigliamo di scegliere la clonazione, poiché non influisce sulle prestazioni e non richiede di ripetere 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 la protezione da eliminazione è abilitata per un'istanza, conferma l'intenzione di eliminarla. Quindi, disattiva la protezione da eliminazione prima di eliminare l'istanza.
Messaggio di errore: 429 Too Many Requests (rateLimitExceeded). Potresti ricevere un errore HTTP 429 Too Many Requests con il motivo rateLimitExceeded quando un'applicazione o un service account supera la quota di frequenza per utente dell'API Cloud SQL Admin. Poiché le quote di frequenza vengono applicate per minuto, per utente e per regione, le metriche aggregate delle quote a livello di progetto nella pagina Quote di Cloud nella console Google Cloud potrebbero non mostrare l'esaurimento delle quote.

Per diagnosticare quale utente o account di servizio sta esaurendo il limite di frequenza per utente:

  1. Nella console Google Cloud , seleziona il progetto consumer che avvia le richieste, quindi vai alla pagina Esplora metriche.
  2. Fai clic su Seleziona una metrica, poi inserisci serviceruntime.googleapis.com/api/request_count nella barra dei filtri. Nei sottomenu, seleziona API utilizzata > API > Numero di richieste, quindi fai clic su Applica.
  3. Nell'elemento Filtro, fai clic su Aggiungi filtro, seleziona response_code, lascia Comparatore impostato su = (uguale a), inserisci 429 nel campo Valore e poi fai clic su Applica.
  4. Fai di nuovo clic su Aggiungi filtro, seleziona service (inserisci sqladmin.googleapis.com nel campo Valore) o method (ad esempio, inserisci google.cloud.sql.v1.SqlInstancesService.Get nel campo Valore) e poi fai clic su Applica.
  5. Nell'elemento Aggregazione, verifica che il primo menu sia impostato su Somma, quindi nel secondo menu (accanto a per), seleziona credential_id per raggruppare le richieste in base alle singole credenziali.
  6. Nei risultati, trova l'ID credenziale (credential_id) con il numero più alto di risposte 429. Questo valore è l'ID client OAuth 2.0 del account di servizio o della credenziale utente che sta esaurendo il limite di frequenza per utente.
  7. Nella console Google Cloud , vai alla pagina Service account e cerca l'ID client OAuth 2.0 corrispondente all'ID credenziale. La voce corrispondente è il account di servizio che sta esaurendo il limite di frequenza per utente.

Per risolvere l'errore, implementa la memorizzazione nella cache lato client o il backoff esponenziale nella tua applicazione, distribuisci i workload tra service account distinti o richiedi un aggiustamento della quota. Per saperne di più, consulta Risolvi gli errori di limitazione di frequenza.

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 per l'endpoint

    REST

    Prima di utilizzare i dati della richiesta, apporta le sostituzioni seguenti:

    • 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 saperne di più, consulta Modifica un'istanza con Private Service Connect abilitato.
ERROR: (gcloud.compute.forwarding-rules.create) Could not fetch resource: The resource 'projects/PROJECT_ID/regions/REGION/subnetworks/SUBNET_NAME' was not found Questo messaggio di errore può essere visualizzato quando prenoti un indirizzo IP interno statico per l'endpoint Private Service Connect. Assicurati che la subnet specificata esista nel progetto specificato dall'URI. Se vuoi creare un endpoint in un progetto di servizio, ma utilizzare una subnet di una rete VPC condiviso, devi specificare la subnet tramite il relativo URI e utilizzare l'ID progetto del progetto host nell'URI. Per saperne di più, consulta Crea l'endpoint manualmente.
ERROR: (gcloud.compute.forwarding-rules.create) Could not fetch resource: - The resource 'projects/PROJECT_ID/global/networks/NETWORK_NAME' was not found Questo messaggio di errore può essere visualizzato quando crei manualmente un endpoint Private Service Connect. Assicurati che la rete specificata esista nel progetto specificato dall'URI. Se vuoi creare un endpoint in un progetto di servizio, ma utilizzi una rete VPC condiviso, devi specificare la rete in base al relativo URI e utilizzare l'ID progetto del progetto host nell'URI. Per saperne di più, consulta Crea l'endpoint manualmente.
Invalid consumer network status for PSC auto connection.

La rete consumer non è configurata correttamente o non è configurata affatto, pertanto non è disponibile alcun endpoint a cui connettersi. Per connetterti all'endpoint, devi controllare lo stato dell'endpoint e correggere l'errore prima di riprovare a connetterti.
Per controllare lo stato di un endpoint, consulta Recupera l'endpoint. Lo stato dell'endpoint può essere uno dei seguenti:

  • CONNECTION_POLICY_MISSING: non esiste una policy di connessione ai servizi corrispondente sulla rete consumer. Le policy di connessione ai servizi vengono configurate per rete e per regione. Per riconfigurare la rete, consulta Aggiorna una policy di connessione al servizio.
  • CONSUMER_INSTANCE_PROJECT_NOT_ALLOWLISTED: esiste una policy di connessione ai servizi corrispondente, ma il campo Ambito dell'istanza di servizio nella policy non è configurato per consentire la connessione a questa istanza Cloud SQL. Aggiorna la policy per configurare il valore del campo Ambito dell'istanza di servizio (--producer-instance-location) con il progetto, la cartella o l'organizzazione in cui si trova l'istanza Cloud SQL. Per riconfigurare la policy di connessione al servizio, consulta Aggiorna una policy di connessione al servizio.
  • POLICY_LIMIT_REACHED: la policy di connessione al servizio ha raggiunto il limite di endpoint. Per risolvere il problema, devi aumentare il limite di endpoint aggiornando la policy di connessione al servizio.
No permission to create a service connection policy.

Non disponi delle autorizzazioni necessarie per creare una policy di connessione al servizio. Per creare una policy di connessione al servizio, devi disporre del ruolo Compute Network Admin IAM. Per saperne di più, consulta Ruoli e autorizzazioni.

Il collegamento di rete non è in grado di accettare connessioni dall'interfaccia Private Service Connect quando utilizzi la connettività in uscita di Private Service Connect.

Se la tua rete esterna non riesce ad accettare connessioni dall'interfaccia Private Service Connect, le policy di connessione sul collegamento di rete potrebbero non essere configurate correttamente.

I collegamenti di rete devono essere configurati in modo da accettare automaticamente tutte le connessioni o configurati manualmente con un elenco di connessioni accettate. Per saperne di più, consulta Policy di connessione.

Utilizza il seguente comando per verificare le connessioni accettate nel collegamento di rete:

    gcloud compute network-attachments describe default
    --region=REGION_ID

Se l'interfaccia Private Service Connect non è presente nell'elenco accettato, aggiorna il collegamento di rete. Per saperne di più, consulta Gestisci i collegamenti di rete.

Replica

Problema Risoluzione dei problemi
La replica di lettura non ha avviato la replica al momento della creazione. Probabilmente nei file di log è presente un errore più specifico. Ispeziona 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 che hai fornito esplicitamente o uno impostato su un valore predefinito.

Innanzitutto, verifica che il valore del flag max_connections sia maggiore o uguale al valore sul nodo primario.

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 nei file di log è presente 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, puoi creare manualmente il account di servizio necessario seguendo le istruzioni riportate in Crea e concedi ruoli agli agenti di servizio.
Lo spazio sul disco è esaurito. Le dimensioni del disco dell'istanza principale possono riempirsi durante la creazione della replica. Modifica l'istanza principale per eseguire l'upgrade a un disco di dimensioni maggiori.
L'istanza di replica utilizza troppa memoria. La replica utilizza la memoria temporanea per memorizzare nella cache le operazioni di lettura richieste di frequente, il che può comportare un utilizzo di memoria maggiore 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 di replica è costantemente elevato. Il carico di scrittura è troppo elevato per essere gestito dalla replica. Il ritardo di replica si verifica quando il thread SQL su una replica non riesce a stare al passo con il thread IO. Alcuni tipi di query o workload possono causare un ritardo di replica elevato temporaneo o permanente per un determinato schema. Alcune delle cause tipiche del ritardo di replica sono:
  • Query lente sulla replica. Trovali e correggili.
  • Tutte le tabelle devono avere una chiave univoca/primaria. Ogni aggiornamento su una tabella di questo tipo senza una chiave univoca/primaria causa scansioni complete della tabella sulla replica.
  • Query come DELETE ... WHERE field < 50000000 causano un ritardo della replica con la replica basata su righe, poiché sulla replica si accumula un numero enorme di aggiornamenti.

Ecco alcune possibili soluzioni:

  • Modifica l'istanza per aumentare le dimensioni della replica.
  • Riduci il carico sul database.
  • Invia il traffico di lettura alla replica di lettura.
  • Indicizza le tabelle.
  • Identifica e correggi le query di scrittura lente.
  • Ricrea la replica.
La creazione della replica non riesce con un timeout. Le transazioni non sottoposte a commit di lunga durata nell'istanza principale possono causare la mancata creazione della replica di lettura.

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