Best practice generali

Questa pagina fornisce le best practice per ottenere le migliori prestazioni, la massima durabilità e disponibilità da Cloud SQL.

Se si verificano problemi con l'istanza Cloud SQL, esamina quanto segue durante la risoluzione dei problemi:

Configurazione e amministrazione delle istanze

Best practice Ulteriori informazioni
Leggi e segui le linee guida operative per assicurarti che le tue istanze siano coperte dall'SLA di Cloud SQL.
Configura un periodo di manutenzione per l'istanza principale da controllare quando possono verificarsi aggiornamenti improvvisi. Vedi Periodo di manutenzione.
Per i carichi di lavoro con un'elevata percentuale di letture, aggiungi repliche di lettura per scaricare il traffico dall'istanza principale. Facoltativamente, puoi utilizzare un bilanciatore del carico come HAProxy per gestire il traffico verso o lo scale out mediante repliche di lettura.
Se elimini e ricrei le istanze regolarmente, utilizza un timestamp l'ID istanza per aumentare la probabilità che i nuovi ID istanza vengano utilizzabili.
Non avviare un'operazione amministrativa prima del completamento dell'operazione precedente.

Le istanze Cloud SQL non accettano nuove richieste di operazioni finché hanno completato l'operazione precedente. Se tenti di avviare una nuova operazione in modo prematuro, la richiesta di operazione non va a buon fine. Sono inclusi i riavvii dell'istanza.

Lo stato dell'istanza nella console Google Cloud non riflette se un'operazione è in esecuzione. Il segno di spunta verde indica solo che l'istanza si trovi nello stato RUNNABLE. Per vedere per vedere se un'operazione è in esecuzione, vai alla scheda Operazioni e per controllare lo stato dell'operazione più recente.

Configura lo spazio di archiviazione per la manutenzione critica del database.

Se l'impostazione dell'istanza Attiva gli incrementi automatici dello spazio di archiviazione è disattivata o se è attivato il limite di aumento automatico dello spazio di archiviazione, assicurati di avere almeno il 20% di spazio disponibile per gestire eventuali operazioni di manutenzione del database critiche che Cloud SQL potrebbe eseguire.

Per ricevere un avviso quando lo spazio su disco disponibile scende al di sotto del 20%, crea un criterio di avviso basato sulle metriche per la metrica Utilizzo disco con una posizione sopra la soglia e un valore di 0,8. Per ulteriori informazioni, consulta Creare criteri di avviso basati su metriche.
Evita l'utilizzo eccessivo della CPU.

Puoi visualizzare la percentuale di CPU disponibile utilizzata dall'istanza nella pagina dei dettagli dell'istanza in Google Cloud Console. Per ulteriori informazioni, consulta Metriche. Puoi anche monitorare l'utilizzo della CPU e ricevere avvisi al raggiungimento di una determinata soglia utilizzando Crea criteri di avviso soglia delle metriche.

Per evitare un utilizzo eccessivo, puoi aumentare il numero di CPU per la tua istanza. Per cambiare le CPU è necessario riavviare l'istanza. Se la tua istanza ha già raggiunto il numero massimo di CPU, devi suddividere il database in più istanze.
Evita di esaurire la memoria.

Quando cerchi segni di esaurimento della memoria, devi principalmente utilizzare la metrica utilizzo. Per evitare errori di esaurimento della memoria, ti consigliamo di mantenere questa metrica al di sotto del 90%.

Puoi anche utilizzare la metrica total_usage per osservare la percentuale di memoria disponibile utilizzata dalla tua istanza Cloud SQL, inclusa la memoria utilizzata dal contenitore del database e la memoria allocata dalla cache del sistema operativo.

Osservando la differenza tra le due metriche, puoi Identificare quanta memoria viene utilizzata dai processi rispetto a quanta viene utilizzata dalla cache del sistema operativo. Puoi riutilizzare il ricordo in questa cache.

Per prevedere i problemi di esaurimento della memoria, controlla entrambe le metriche e interpretale insieme. Se le metriche sembrano elevate, la memoria dell'istanza potrebbe essere insufficiente. Ciò può essere dovuto a una configurazione personalizzata, sottodimensionato a seconda del carico di lavoro oppure una combinazione questi fattori.

Esegui il ridimensionamento dell'istanza Cloud SQL per aumentare le dimensioni della memoria. La modifica della dimensione della memoria dell'istanza richiede il riavvio dell'istanza. Se l'istanza ha già raggiunto la dimensione massima della memoria, devi eseguire lo sharding del database su più istanze. Per scoprire di più sul monitoraggio di entrambe le metriche nella console Google Cloud, consulta Metriche.
Assicurati che l'istanza abbia ID transazione ottimali.

Puoi visualizzare l'utilizzo dell'ID transazione della tua istanza nella pagina Esplora metriche della console Google Cloud impostando Resource Type su Cloud SQL Database e Metric su Percentage of instance's transaction IDs consumed. Per ulteriori informazioni, consulta Creare grafici con Esplora metriche.

L'ottimizzazione e il monitoraggio delle istanze di database possono contribuire a ridurre o evitare i problemi relativi al vuoto. Monitora l'utilizzo degli ID transazione della tua istanza e attiva e modifica i parametri autovacuum in base al carico di lavoro sull'istanza. Per ulteriori informazioni, consulta la sezione Risolvere i problemi di wraparound degli ID transazione (TXID).

Architettura dei dati

Best practice Ulteriori informazioni
Se possibile, dividi le istanze di grandi dimensioni in istanze più piccole. Quando possibile, l'utilizzo di molte istanze Cloud SQL più piccole rispetto a un'istanza di grandi dimensioni. La gestione di un'istanza monolitica di grandi dimensioni presenta sfide non poste da un gruppo di istanze più piccole.
Non utilizzare troppe tabelle di database.

Mantieni il conteggio delle tabelle dell'istanza inferiore a 10.000. Troppi database possono influire sui tempi di upgrade del database.

Implementazione dell'applicazione

Best practice Ulteriori informazioni
Usare buone pratiche di gestione delle connessioni, come il pooling delle connessioni e e il backoff esponenziale. L'utilizzo di queste tecniche migliora l'utilizzo delle risorse da parte dell'applicazione e ti aiuta a rispettare i limiti di connessione di Cloud SQL. Per ulteriori informazioni e esempi di codice, consulta Gestire le connessioni al database.
Testa la risposta della tua applicazione agli aggiornamenti di manutenzione, che possono verificarsi in qualsiasi momento durante il periodo di manutenzione. Prova la manutenzione self-service. per simulare un aggiornamento di manutenzione. Durante la manutenzione, l'istanza non è disponibile per un breve periodo e le connessioni esistenti vengono interrotte. Testare l'implementazione della manutenzione ti consente di comprendere meglio come la tua applicazione gestisce la manutenzione programmata e la rapidità con cui il sistema può recuperare.
Testa la risposta della tua applicazione ai failover, avvengono in qualsiasi momento. Puoi avviare manualmente un failover utilizzando la console Google Cloud, gcloud CLI o l'API. Vedi Avvio del failover.
Evita transazioni di grandi dimensioni. Fai in modo che le transazioni siano brevi e brevi. Se è necessario un aggiornamento di grandi dimensioni del database, eseguilo in più transazioni più piccole anziché in una sola transazione di grandi dimensioni.
Se utilizzi il proxy di autenticazione Cloud SQL, assicurati di utilizzare alla versione aggiornata. Consulta Mantenere aggiornato il proxy di autenticazione Cloud SQL.

Importazione ed esportazione di dati

Best practice Ulteriori informazioni
Usa esportazioni serverless. Le esportazioni serverless trasferiscono l'operazione di esportazione a un'istanza temporanea, consentendo all'istanza principale di continuare a gestire le query ed eseguire operazioni con le consuete prestazioni. Al termine dell'esportazione dei dati, l'istanza temporanea eliminati automaticamente.
Accelera le importazioni per le dimensioni piccole delle istanze. Per le istanze di piccole dimensioni, puoi aumentare temporaneamente la CPU e la RAM di un'istanza per migliorare le prestazioni durante l'importazione di set di dati di grandi dimensioni.
Se esporti dati per importarli in Cloud SQL, assicurati di seguire la procedura corretta. Consulta Esportare dati da un server di database gestito esternamente.

Backup e ripristino

Best practice Ulteriori informazioni
Proteggi i tuoi dati con la funzionalità Cloud SQL appropriata.

I backup, il recupero point-in-time e le esportazioni sono modi per fornire ridondanza e protezione dei dati. Ciascuno di essi protegge da scenari diversi e integra in una solida strategia di protezione dei dati.

I backup sono leggeri e consentono di ripristinare i dati dell'istanza allo stato al momento del backup. Tuttavia, i backup presentano alcune limitazioni. Se elimini il in un'istanza, vengono eliminati anche i backup. Non puoi eseguire il backup di un singolo un database o una tabella. E se la regione in cui si trova l'istanza non è disponibile, non puoi ripristinare l'istanza da quel backup, in una regione disponibile.

Il recupero point-in-time consente di recuperare un'istanza in un punto specifico nel tempo. Ad esempio, se un errore causa una perdita di dati, puoi ripristinare lo stato di un database prima che si verifichi l'errore. Un momento specifico il ripristino crea sempre una nuova istanza, non puoi eseguire recupero point-in-time in un'istanza esistente.

La creazione delle esportazioni richiede più tempo perché in Cloud Storage viene creato un file esterno che può essere utilizzato per ricreare i dati. Le esportazioni non sono interessate se elimini l'istanza. Inoltre, puoi esportare solo un singolo database o anche una tabella, a seconda del formato di esportazione scelto.

Dimensiona le istanze in modo da tenere conto della conservazione dei log delle transazioni (binari). Un'elevata attività di scrittura nel database può generare un volume elevato di log delle transazioni (binari), che possono consumare molto spazio su disco e portare all'aumento del disco per le istanze che consentono di aumentare automaticamente lo spazio di archiviazione. Consigliamo di dimensionare lo spazio di archiviazione dell'istanza in modo da tenere conto dei log delle transazioni.
Proteggi l'istanza e i backup dall'eliminazione accidentale.

Un'istanza Cloud SQL che crei nella console Google Cloud. o tramite Terraform, abilita per impostazione predefinita la prevenzione dell'eliminazione accidentale.

Utilizza la funzionalità di esportazione in Cloud SQL per esportare i dati per una protezione aggiuntiva. Utilizza Cloud Scheduler con l'API REST per automatizzare la gestione dell'esportazione. Per scenari più avanzati, Cloud Scheduler con le funzioni Cloud Run per l'automazione.

Sintonizzazione e monitoraggio

L'ottimizzazione e il monitoraggio delle istanze di database possono aiutare a ridurre o evitare problemi legati all'aspirapolvere.

L'operazione VACUUM ha diverse varianti con diversi livelli di blocco: VACUUM standard e VACUUM FULL. L'opzione VACUUM FULL può recuperare più spazio su disco, ma esclusivamente blocca il tavolo e funziona lentamente. Utilizza invece il formato standard VACUUM, che può essere eseguita in parallelo con le operazioni del database di produzione. Quando utilizzi l'operazione VACUUM, comandi come SELECT, INSERT, UPDATE, and DELETE continuerà per funzionare normalmente. Non potrai modificare la definizione di una tabella con comandi come ALTER TABLE durante l'analisi.

Ecco alcuni consigli che potrebbero aiutarti a ridurre il tempo necessario per completare l'operazione VACUUM:

  • Aumenta la memoria di sistema e maintenance_work_mem. Questo raggruppa più tuple in ogni iterazione e completa il lavoro il più rapidamente possibile. Tieni presente che, quando è in funzione autovacuum, fino a Potrebbe essere allocata autovacuum_max_workers volte questa memoria, quindi fai attenzione a non impostare un valore predefinito troppo alto.
  • L'operazione VACUUM genera molti log write-ahead (WAL) record. Se è possibile ridurre il numero di record WAL, ad esempio non configurando alcuna replica per questa istanza, l'operazione viene completata più rapidamente.
  • Se la tabella ha raggiunto il limite di due miliardi di ID transazione perché nessuna delle tuple è bloccata, prova a ridurre il volume di lavoro svolto in modalità monoutente. Un'opzione possibile è impostare vacuum_freeze_min_age=1,000,000,000 (il valore massimo consentito, superiore al valore predefinito di 50.000.000). Questo nuovo valore riduce il numero di tuple bloccate fino a due volte.
  • PostgreSQL 12.0 e versioni successive supportano la pulizia e VACUUM senza eliminare le voci di indice. Questo è fondamentale, poiché la pulizia dell'indice richiede una scansione completa dell'indice e, se se ci sono più indici, il tempo totale dipende dalle dimensioni dell'indice.
  • Gli indici più grandi richiedono una notevole quantità di tempo per la scansione degli indici. pertanto è preferibile usare INDEX_CLEANUP OFF per eseguire rapidamente la pulizia e bloccare i dati della tabella. Le versioni PostgreSQL precedenti alla 12.0 devono essere ottimizzate il numero di indici. In altre parole, se sono presenti indici non critici, potrebbe essere utile ridurre l'indice NON-CRITICAL per velocizzare l'operazione di vacuum.

Passaggi successivi

Per ulteriori informazioni sulle pratiche generali per motore del database, vedi: