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 causano interruzioni. | Consulta Periodo di manutenzione. |
| 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 sia stata completata l'operazione precedente. |
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 Google Cloud console non
indica se è in esecuzione un'operazione. Il segno di spunta verde indica
solo che l'istanza è nello stato |
| 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 una criterio di avviso basata su metriche per la utilizzo del disco metrica con una posizione sopra la soglia e un valore di .8. Per saperne di più, consulta Creare policy di avviso basate su metriche. |
| Evita l'utilizzo eccessivo della CPU. |
Puoi visualizzare la percentuale di CPU disponibile utilizzata dall'istanza nella pagina dei dettagli dell'istanza della Google Cloud 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. 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 workload 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 Google Cloud console, consulta Metriche. |
Sicurezza
| Best practice | Ulteriori informazioni |
|---|---|
| Preferisci l'IP privato | A meno che non sia necessario l'accesso IP pubblico, preferisci utilizzare l'IP privato. In questo modo, ridurrai al minimo le connessioni di rete non autorizzate al tuo 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 delle istanze MySQL o PostgreSQL , specifica le policy per le password appropriate per l'istanza del database per evitare di configurare password inefficaci, impostare la data di scadenza e configurare il blocco dell'account in caso di tentativi di accesso non riusciti. Questo è particolarmente importante se stai configurando l'istanza per IP pubblico. |
| Segui pattern di utilizzo dello schema sicuri |
Per prevenire 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.
|
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 rispetto a una grande. La gestione di un'istanza monolitica di grandi dimensioni presenta sfide che non si pongono in un gruppo di istanze più piccole. |
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 al database. |
| Testa la risposta dell'applicazione agli aggiornamenti di manutenzione, che possono avvenire 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à di ripristino del sistema. |
| Testa la risposta dell'applicazione ai failover, che possono avvenire in qualsiasi momento. | Puoi avviare manualmente un failover utilizzando la Google Cloud console, la gcloud CLI o l'API. Consulta Avviare il 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 |
|---|---|
| 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 l'importazione in Cloud SQL, assicurati di utilizzare la procedura corretta. | Consulta Esportare i 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 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 consentono di 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 dal backup, nemmeno in una regione disponibile. 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 vengono interessate se elimini l'istanza. Inoltre, puoi esportare solo un singolo database o anche una tabella, a seconda del formato di esportazione scelto. |
| Proteggi l'istanza e i backup da eliminazioni accidentali. | Un'istanza Cloud SQL creata nella Google Cloud console 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 delle esportazioni. Per scenari più avanzati, utilizza Cloud Scheduler con Cloud Run Functions per l'automazione. |
Passaggi successivi
Per saperne di più sulle pratiche generali per motore del database, consulta:
- Best practice generali per MySQL
- Best practice generali per PostgreSQL
- Best practice generali per SQL Server