Alcune o tutte le informazioni in questa pagina potrebbero non essere applicabili a Cloud de Confiance di S3NS. Per maggiori dettagli, consulta Differenze rispetto a Google Cloud.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Best practice generali

MySQL | PostgreSQL | SQL Server

Questa pagina fornisce le best practice per ottenere il massimo livello di prestazioni, durabilità e affidabilità da Cloud SQL.

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

Configurazione e amministrazione dell'istanza

Best practice	Ulteriori informazioni
Leggi e segui le linee guida operative per assicurarti che le tue istanze siano coperte dallo SLA di Cloud SQL.
Configura un periodo di manutenzione per l'istanza principale per controllare quando possono verificarsi aggiornamenti che potrebbero causare interruzioni.	Consulta Periodo di manutenzione.
Per i carichi di lavoro con molte operazioni di lettura, aggiungi repliche di lettura per trasferire il traffico dall'istanza principale.	Facoltativamente, puoi utilizzare un bilanciatore del carico come HAProxy per gestire il traffico verso le repliche.
Se elimini e ricrei regolarmente le istanze, utilizza un timestamp in nell'ID istanza per aumentare la probabilità che i nuovi ID istanza siano utilizzabili.
Non avviare un'operazione amministrativa prima che quella precedente sia stata completata.	Le istanze Cloud SQL non accettano nuove richieste di operazioni finché non hanno completato l'operazione precedente. Se tenti di avviare una nuova operazione prematuramente, la richiesta di operazione non va a buon fine. Sono inclusi i riavvii delle istanze. Lo stato dell'istanza nella Cloud de Confiance console non indica 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 ospitare la manutenzione critica del database.	Se l'impostazione dell'istanza Abilita aumenti automatici dello spazio di archiviazione è disabilitata o se il limite di aumento automatico dello spazio di archiviazione è abilitato, assicurati di avere almeno il 20% di spazio disponibile per ospitare eventuali operazioni di manutenzione critica del database 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 su metriche per la metrica di utilizzo del disco con una posizione sopra la soglia e un valore di .8. Per saperne di più, 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 Cloud de Confiance console. Per saperne di più, consulta Metriche. Puoi anche monitorare l'utilizzo della CPU e ricevere avvisi a una soglia specificata utilizzando Crea policy di avviso basate su soglie metriche. Per evitare un utilizzo eccessivo, puoi aumentare il numero di CPU per l'istanza. La modifica delle CPU richiede il riavvio dell'istanza. Se l'istanza ha già raggiunto il numero massimo di CPU, devi partizionare il database in più istanze.
Evita l'esaurimento della memoria.	Quando cerchi segni di esaurimento della memoria, devi utilizzare principalmente la metrica di utilizzo. Per evitare errori di memoria insufficiente, 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 dall'istanza Cloud SQL, inclusa la memoria utilizzata dal container 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 la memoria in questa cache. Per prevedere problemi di memoria insufficiente, controlla entrambe le metriche e interpreta insieme. Se le metriche sembrano elevate, l'istanza potrebbe avere poca memoria. Ciò può essere dovuto a una configurazione personalizzata, le dimensioni insufficienti dell'istanza per il carico di lavoro o a una combinazione di questi fattori. Scala l'istanza Cloud SQL per aumentare le dimensioni della memoria. La modifica delle dimensioni della memoria dell'istanza richiede il riavvio dell'istanza. Se l'istanza ha già raggiunto le dimensioni massime della memoria, devi partizionare il database in più istanze. Per saperne di più sul monitoraggio di entrambe le metriche nella Cloud de Confiance console, consulta Metriche.
Assicurati che l'istanza abbia ID transazione ottimali.	Puoi visualizzare l'utilizzo dell'ID transazione dell'istanza nella pagina Esplora metriche della Cloud de Confiance console impostando `Resource Type` su `Cloud SQL Database` e `Metric` su `Percentage of instance's transaction IDs consumed`. Per saperne di più, consulta Crea grafici con Esplora metriche. L'ottimizzazione e il monitoraggio delle istanze di database possono contribuire a ridurre o evitare problemi correlati a VACUUM. Monitora l'utilizzo dell'ID transazione dell'istanza e abilita e regola i parametri `autovacuum` in base al carico di lavoro dell'istanza. Per saperne di più, consulta Risoluzione dei problemi di wraparound degli ID transazione (TXID).

Sicurezza

Best practice	Ulteriori informazioni
Preferisci l'IP privato	A meno che non sia necessario l'accesso all'IP pubblico, preferisci utilizzare l'IP privato. In questo modo, puoi 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 ciò consente l'accesso da internet globale senza restrizioni.
Evita reti autorizzate eccessivamente grandi	Evita di utilizzare prefissi CIDR piccoli in Reti autorizzate in quanto ciò consente l'accesso da un numero potenzialmente eccessivo di host. Ti consigliamo di utilizzare un prefisso CIDR non inferiore a /16 e, preferibilmente, superiore a /19.
Abilita le policy per le password	Utilizzando le policy per le password dell'istanza, specifica le policy per le password appropriate per l'istanza di database per evitare la configurazione di password deboli, impostare il tempo di scadenza e configurare il blocco dell'account in caso di tentativi di accesso non riusciti. Ciò è particolarmente importante se stai configurando l'istanza per l'IP pubblico.
Segui pattern di utilizzo dello schema sicuri	Per evitare attacchi di hijacking del percorso di ricerca, assicurati che gli utenti amministratori abbiano un percorso di ricerca sicuro. Ti consigliamo di impostare il parametro `search_path` su `pg_catalog` per gli utenti con privilegi elevati. Consulta Utilizzo del percorso di ricerca sicuro usage.
Imposta `log_statement` su `none`	Per impostazione predefinita, il flag log_statement è `none`. Se non è impostato su `none`, PostgreSQL può registrare le istruzioni che contengono password. Ti consigliamo di utilizzare pgAudit per il controllo del database anziché `log_statement`.

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 più piccole anziché una grande istanza. La gestione di un'istanza monolitica di grandi dimensioni presenta sfide che non si pongono con 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 di database può influire sul tempo di upgrade del database.

Implementazione dell'applicazione

Best practice	Ulteriori informazioni
Utilizza le best practice per la 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 connection limits. Per ulteriori informazioni ed esempi di codice, consulta Gestire le connessioni ai database.
Testa la risposta dell'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 eliminate. Il test dei rollout di manutenzione ti consente di comprendere meglio in che modo l'applicazione gestisce la manutenzione pianificata e la velocità con cui il sistema può essere ripristinato.
Testa la risposta dell'applicazione ai failover, che possono verificarsi in qualsiasi momento.	Puoi avviare manualmente un failover utilizzando la Cloud de Confiance console, la gcloud CLI o l'API. Consulta Avvio del failover.
Evita transazioni di grandi dimensioni.	Mantieni le transazioni piccole e brevi. Se è necessario un aggiornamento di un database di grandi dimensioni, eseguilo in più transazioni più piccole anziché in una 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 dei 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 gestire le query ed eseguire le operazioni con le prestazioni abituali. Al termine dell'esportazione dei dati, l'istanza temporanea viene eliminata automaticamente.
Velocizza le importazioni per le istanze di piccole dimensioni.	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 importarli 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. Ognuno protegge da scenari diversi e si completa a vicenda in una strategia di protezione dei dati efficace. I backup sono leggeri e forniscono un modo per ripristinare i dati dell'istanza allo stato in cui si trovavano 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 di una singola tabella. Inoltre, se la regione in cui si trova l'istanza non è disponibile, non puoi ripristinare l'istanza da questo backup, nemmeno in una regione disponibile. Il recupero point-in-time ti aiuta a recuperare un'istanza in un momento specifico in tempo. Ad esempio, se un errore causa una perdita di dati, puoi ripristinare un database nello stato in cui si trovava prima che si verificasse 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.
Dimensiona le istanze in modo da tenere conto della conservazione dei log delle transazioni (binari).	Un'attività di scrittura elevata nel database può generare un volume elevato di log delle transazioni (binari), che può consumare una quantità significativa di spazio su disco e portare alla crescita del disco per le istanze abilitate ad aumentare automaticamente lo spazio di archiviazione. Ti consigliamo di dimensionare lo spazio di archiviazione dell'istanza in modo da tenere conto della conservazione dei log delle transazioni.
Proteggi l'istanza e i backup da eliminazioni accidentali.	Per impostazione predefinita, un'istanza Cloud SQL creata nella Cloud de Confiance console o tramite Terraform abilita 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 delle esportazioni. Per scenari più avanzati, utilizza Cloud Scheduler con Cloud Run Functions per l'automazione.

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. Ognuno protegge da scenari diversi e si completa a vicenda in una strategia di protezione dei dati efficace.

I backup sono leggeri e forniscono un modo per ripristinare i dati dell'istanza allo stato in cui si trovavano 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 di una singola tabella. Inoltre, se la regione in cui si trova l'istanza non è disponibile, non puoi ripristinare l'istanza da questo backup, nemmeno in una regione disponibile.

Il recupero point-in-time ti aiuta a recuperare un'istanza in un momento specifico in tempo. Ad esempio, se un errore causa una perdita di dati, puoi ripristinare un database nello stato in cui si trovava prima che si verificasse 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.

Dimensiona le istanze in modo da tenere conto della conservazione dei log delle transazioni (binari).

Un'attività di scrittura elevata nel database può generare un volume elevato di log delle transazioni (binari), che può consumare una quantità significativa di spazio su disco e portare alla crescita del disco per le istanze abilitate ad aumentare automaticamente lo spazio di archiviazione. Ti consigliamo di dimensionare lo spazio di archiviazione dell'istanza in modo da tenere conto della conservazione dei log delle transazioni.

Proteggi l'istanza e i backup da eliminazioni accidentali.

Per impostazione predefinita, un'istanza Cloud SQL creata nella Cloud de Confiance console o tramite Terraform abilita 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 delle esportazioni. Per scenari più avanzati, utilizza Cloud Scheduler con Cloud Run Functions per l'automazione.

Ottimizzazione e monitoraggio

L'ottimizzazione e il monitoraggio delle istanze di database possono contribuire a ridurre o evitare problemi correlati a VACUUM.

L'operazione VACUUM ha varianti diverse con livelli di blocco diversi: VACUUM standard e VACUUM FULL. L'opzione VACUUM FULL può recuperare più spazio su disco, ma blocca esclusivamente la tabella e viene eseguita lentamente. Utilizza invece la forma standard di VACUUM, che può essere eseguita in parallelo con le operazioni di 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'esecuzione di VACUUM.

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 raggruppati più tuple in ogni iterazione e il lavoro viene completato il più rapidamente possibile. Tieni presente che quando viene eseguito autovacuum, è possibile allocare fino a autovacuum_max_workers volte questa memoria, quindi fai attenzione a non impostare un valore predefinito troppo elevato.
L'operazione VACUUM genera molti record di log write-ahead (WAL) record. Se è possibile ridurre il numero di record WAL, ad esempio non configurando repliche 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 la quantità di lavoro eseguita in modalità utente singolo. Una possibile opzione è impostare vacuum_freeze_min_age=1,000,000,000 (il valore massimo consentito , rispetto al valore predefinito di 50.000.000). Questo nuovo valore riduce il numero di tuple bloccate fino a due volte.
PostgreSQL versione 12.0 e successive 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 sono presenti più indici, il tempo totale dipende dalle dimensioni dell'indice.
Gli indici più grandi consumano una quantità significativa di tempo per la scansione dell'indice, pertanto INDEX_CLEANUP OFF è preferibile per pulire rapidamente e bloccare i dati della tabella. Le versioni di PostgreSQL precedenti alla 12.0 devono ottimizzare il numero di indici. Ovvero, se sono presenti indici non critici, potrebbe essere utile eliminare l'indice NON-CRITICAL per velocizzare l'operazione di VACUUM.