Best practice generali

Questa pagina fornisce le best practice per ottenere il massimo rendimento, la massima durabilità e la massima 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 per controllare quando possono verificarsi aggiornamenti che causano interruzioni. Consulta Periodo di manutenzione.
Per i workload con un'elevata percentuale di operazioni di lettura, aggiungi repliche di lettura per scaricare il traffico dall'istanza principale. Se vuoi, puoi utilizzare un bilanciatore del carico come HAProxy per gestire il traffico verso le repliche.
Se elimini e crei di nuovo le istanze regolarmente, utilizza un timestamp nell'ID istanza per aumentare la probabilità che i nuovi ID istanza siano utilizzabili.
Non avviare un'operazione amministrativa prima del completamento dell'operazione precedente.

Le istanze Cloud SQL non accetteranno nuove richieste di operazioni finché non avranno 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 delle istanze.

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 è nello stato RUNNABLE. Per verificare se un'operazione è in esecuzione, vai alla scheda Operazioni e controlla lo stato dell'operazione più recente.

Configura lo spazio di archiviazione per la manutenzione di database critici.

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 nella console Google Cloud. Per ulteriori informazioni, consulta Metriche. Puoi anche monitorare l'utilizzo della CPU e ricevere avvisi a una soglia specificata utilizzando Creare criteri di avviso basati su soglie di metriche.

Per evitare un utilizzo eccessivo, puoi aumentare il numero di CPU per la tua istanza. La modifica delle CPU richiede il riavvio dell'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 la quantità di memoria utilizzata dai processi rispetto a quella 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, a un'istanza di dimensioni insufficienti per il carico di lavoro o a una combinazione di questi fattori.

Esegui la scalabilità dell'istanza Cloud SQL per aumentare le dimensioni della memoria. La modifica della dimensione della memoria dell'istanza richiede il riavvio dell'istanza. Se la tua 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 Metrics Explorer.

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 sulla tua istanza. Per ulteriori informazioni, consulta la sezione Risolvere i problemi di wraparound degli ID transazione (TXID).

Sicurezza

Best practice Ulteriori informazioni
Preferisci IP privato A meno che non sia richiesto l'accesso tramite IP pubblico, preferisci utilizzare IP privato. In questo modo, contribuirete a ridurre al minimo le connessioni di rete non autorizzate al database.
Evita 0.0.0.0/0 nelle reti autorizzate Evita di includere 0.0.0.0/0 in Reti autorizzate in quanto consente l'accesso da internet globale senza restrizioni.
Evita reti autorizzate eccessivamente grandi Evita di utilizzare prefessi CIDR di piccole dimensioni in Reti autorizzate in quanto consentono l'accesso da un numero potenzialmente eccessivo di host. Consigliamo un prefisso CIDR non inferiore a /16 e preferibilmente superiore a /19.
Abilita le policy per le password Utilizzando le policy delle password per l'istanza, specifica le policy delle password appropriate per l'istanza del database per evitare la configurazione di password deboli, imposta la data di scadenza e configura il blocco dell'account in caso di tentativi di accesso non riusciti. Questo è particolarmente importante se configuri l'istanza per l'IP pubblico.

Architettura dei dati

Best practice Ulteriori informazioni
Se possibile, suddividi le istanze di grandi dimensioni in istanze più piccole. Se possibile, è meglio utilizzare molte istanze Cloud SQL di piccole dimensioni anziché 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 numero di tabelle dell'istanza inferiore a 10.000. Un numero eccessivo di tabelle del database può influire sul tempo di upgrade del database.

Implementazione dell'applicazione

Best practice Ulteriori informazioni
Utilizza buone pratiche di gestione delle connessioni, come il pooling delle connessioni 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 dell'applicazione ai failover, che possono verificarsi in qualsiasi momento. Puoi avviare manualmente un failover utilizzando la console Google Cloud, l'interfaccia a riga di comando gcloud o l'API. Vedi Avvio del failover.
Evita transazioni di grandi dimensioni. Mantieni le transazioni brevi e piccole. 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 la versione più aggiornata. Consulta Mantenere aggiornato il proxy di autenticazione Cloud SQL.

Importazione ed esportazione di dati

Best practice Ulteriori informazioni
Utilizza le esportazioni serverless. Le esportazioni serverless trasferiscono l'operazione di esportazione a un'istanza temporanea, consentendo all'istanza principale di continuare a eseguire query ed eseguire operazioni con le consuete prestazioni. Al termine dell'esportazione dei dati, l'istanza temporanea viene eliminata 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 i dati per l'importazione in Cloud SQL, assicurati di utilizzare 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. Ognuna protegge da scenari diversi e si completano a vicenda in una strategia di protezione dei dati solida.

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 l'istanza, vengono eliminati anche i backup. Non puoi eseguire il backup di un singolo database o tabella. Inoltre, se la regione in cui si trova l'istanza non è disponibile, non puoi ripristinare l'istanza da quel backup, anche in una regione disponibile.

Il recupero point-in-time ti aiuta a recuperare un'istanza in un momento specifico. Ad esempio, se un errore causa una perdita di dati, puoi ripristinare lo stato di un database prima che si verifichi l'errore. Un recupero point-in-time crea sempre una nuova istanza. Non puoi eseguire un 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.

Definisci le dimensioni delle istanze in base alla conservazione dei log delle transazioni (binari). Un'attività di scrittura elevata 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. Ti consigliamo di determinare le dimensioni dello spazio di archiviazione dell'istanza in modo da tenere conto della conservazione dei log delle transazioni.
Proteggi l'istanza e i backup dall'eliminazione accidentale.

Per impostazione predefinita, un'istanza Cloud SQL creata nella console Google Cloud o tramite Terraform attiva 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.

Ottimizzare e monitorare

L'ottimizzazione e il monitoraggio delle istanze di database possono contribuire a ridurre o evitare i problemi relativi al vuoto.

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 blocca la tabella in modo esclusivo e funziona lentamente. Utilizza invece la forma standard di VACUUM, che può essere eseguita in parallelo con le operazioni del database di produzione. Quando utilizzi l'operazione VACUUM, i comandi come SELECT, INSERT, UPDATE, and DELETE continueranno a 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. In questo modo, vengono raggruppate più tuple in ogni iterazione e il lavoro viene completato il più rapidamente possibile. Tieni presente che quando viene eseguito autovacuum, questa memoria può essere allocata fino a autovacuum_max_workers volte, quindi fai attenzione a non impostare il valore predefinito troppo alto.
  • L'operazione VACUUM genera molti record del log write-ahead (WAL). 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.
  • La versione 12.0 e le versioni successive di PostgreSQL supportano le operazioni di pulizia e VACUUM senza pulire le voci dell'indice. Questo è fondamentale, in quanto la pulizia dell'indice richiede una scansione completa dell'indice e se esistono più indici, il tempo totale dipende dalle dimensioni dell'indice.
  • Gli indici più grandi richiedono molto tempo per la scansione dell'indice, pertanto è preferibile utilizzare INDEX_CLEANUP OFF per ripulire rapidamente e bloccare i dati della tabella. Le versioni di PostgreSQL precedenti alla 12.0 devono ottimizzare il numero di indici. In altre parole, se sono presenti indici non critici, potrebbe essere utile eliminare l'indice NON-CRITICAL per velocizzare l'operazione di svuotamento.