Best practice per la configurazione di un'istanza di Cloud SQL per MySQL

Cloud SQL per MySQL è un servizio di database completamente gestito che semplifica la configurazione, la manutenzione, la gestione e l'amministrazione dei database relazionali MySQL su Google Cloud. Quando è tutto pronto per creare un'istanza di Cloud SQL per MySQL, hai a disposizione alcune opzioni, tra cui la console della UI, la gcloud CLI, Terraform e un'API REST. Puoi seguire la nostra documentazione per i dettagli di ognuno di questi percorsi. Tuttavia, ai fini di questo articolo, utilizzeremo la UI a scopi illustrativi durante la trattazione di una serie di best practice per la configurazione di un'istanza.

Crea una password efficace

Questa è la password per l'utente del database "root"@"%" predefinito che verrà creato con l'istanza. Se intendi mantenere l'utente root come utente amministratore, assicurati di scegliere una password efficace in questo campo. Per problemi di sicurezza, è consigliabile utilizzare un utente amministratore non molto comune al posto dell'utente "root". Fai riferimento alla sezione "Gestisci gli utenti del database". 

Crea un criterio relativo alle password a livello di istanza

La funzionalità dei criteri relativi alle password consente una maggiore sicurezza dei database. Consente di configurare criteri che interessano lunghezza, complessità, scadenza e riutilizzo limitato delle password. Per ulteriori dettagli, consulta Proteggere un'istanza MySQL.

Per prestazioni ottimali, valuta l'utilizzo della versione 8.0

Cloud SQL MySQL supporta più versioni secondarie della versione 8.0. Attualmente v8.0.26 è la versione predefinita. I test di benchmark condotti su un'ampia gamma di tipi di macchine mostrano una maggiore velocità effettiva delle query con la versione predefinita 8.0 rispetto alle versioni 5.7 e 5.6.  

Non utilizzare la versione in disponibilità generale più recente per l'istanza di produzione 

Nonostante tutti gli sforzi di test di Oracle e Cloud SQL, le release di aggiornamento di MySQL non sono completamente verificate in scenari reali. Consigliamo quindi di mantenere le istanze di produzione su una versione stabile e di utilizzare le istanze di sviluppo e di gestione temporanea per testare gli ultimi upgrade della versione secondaria in Cloud SQL per MySQL.

Configura più zone per l'istanza di produzione

Cloud SQL per MySQL offre disponibilità a livello di regione tramite failover automatico in una seconda zona come soluzione ad alta disponibilità. Per una migliore disponibilità, configura l'opzione Più zone per le istanze di produzione in modo da avere automaticamente backup giornalieri e recupero point-in-time. Per ulteriori informazioni, consulta la sezione "Pianificazione del backup".

Valuta l'utilizzo attuale di CPU/memoria per prendere decisioni informate per la migrazione

Quando esegui la migrazione di un'istanza esistente a Cloud SQL, il tuo carico di lavoro attuale può aiutarti a scegliere le dimensioni corrette della VM. 

• CPU: qual è l'utilizzo della CPU in condizioni di carico di lavoro normali? E i picchi di carico di lavoro? L'istanza è vincolata alla CPU o I/O? Se la percentuale di CPU dell'utente e/o del sistema è relativamente alta, questo è un segnale di un carico di lavoro legato alla CPU. Se la percentuale di I/O è relativamente alta, questo è un'indicazione di un carico di lavoro legato a I/O. 
• Memoria: allo stesso modo, qual è l'utilizzo normale della memoria per l'istanza e qual è l'utilizzo di picco? 

Come riferimento, una vCPU in Cloud SQL per MySQL può supportare fino a 6,5 GB di memoria. 

Pianifica dal 20% al 50% di spazio aggiuntivo per CPU e memoria

Anche in un'istanza generalmente stabile, pianifica almeno il 20% di spazio in più affinché CPU e memoria possano assorbire i picchi imprevisti. Questo è ancora più importante per un'attività in crescita: inquesto caso considera un 50% in più. 

Cloud SQL semplifica l'upgrade del tipo di macchina. Tieni presente che esistono tempi di inattività associati a un upgrade.

Usa SSD per prestazioni del database migliori

Cloud SQL per MySQL offre HDD come opzione di archiviazione economica, ma se sai di aver bisogno di un database ad alte prestazioni, scegli l'opzione SSD. Ecco un confronto delle prestazioni di I/O. 

Quando si tratta di capacità di archiviazione, pianifica un equilibrio tra prestazioni e costi

Le IOPS e la velocità effettiva del disco sono correlate alla dimensione del disco permanente. Una capacità maggiore genera un maggior numero di IOPS e una velocità effettiva più elevata entro il limite dell'istanza. 

Per SSD, le configurazioni a livello di zona e di regione influiranno sulle prestazioni. Per ulteriori dettagli, consulta i dati sulle prestazioni degli SSD a livello di zona e di regione. Se hai selezionato la disponibilità di più zone, fai riferimento ai dati sulle prestazioni degli SSD a livello di regione. In breve, le IOPS di lettura e scrittura sono pari a 30 per GB e la velocità effettiva è di 0,48 MB per GB. Con l'SSD a livello di regione, i dati sulle prestazioni sono simili, ad eccezione del fatto che le IOPS di scrittura per istanza e la velocità effettiva di scrittura sono inferiori. 

Tieni presente che la dimensione massima dello spazio di archiviazione supportata è 64 TB su un'istanza Cloud SQL. 

Abilita l'aumento automatico dello spazio di archiviazione e monitora la crescita dei dati su disco

Cloud SQL dispone di una funzionalità di aumento automatico dello spazio di archiviazione per evitare che le istanze esauriscano lo spazio su disco (OOD). Quando la funzionalità è abilitata, lo spazio di archiviazione viene controllato ogni 30 secondi e, se necessario, verrà aggiunta capacità di archivizione incrementale. 

Questa funzionalità protegga dall'esaurimento dello spazio su disco, ma, allo stesso tempo, l'aumento di capacità è permanente: non puoi ridimensionare l'istanza in un secondo momento. Per prima cosa, configura gli avvisi relativi alle dimensioni del disco per poter gestire e pianificare la capacità di archiviazione. 

Acquisisci familiarità con le opzioni di crittografia

Cloud SQL cripta i dati at-rest per impostazione predefinita. Tuttavia, è possibile utilizzare una chiave di crittografia gestita dal cliente (CMEK) al posto della chiave predefinita di proprietà e gestita da Google se questa è più adatta alle tue esigenze.

Valuta il compromesso tra IP privato e IP pubblico

IP pubblico e privato si riferiscono ai tipi di indirizzi utilizzati dai dispositivi in una rete. L'IP privato offre una migliore sicurezza di rete e una latenza di rete inferiore rispetto all'IP pubblico. Tuttavia, l'IP privato richiede configurazioni API e IAM aggiuntive per la configurazione e a volte l'IP pubblico è effettivamente richiesto. Se sai di dover utilizzare l'IP pubblico, ma vuoi migliorare la sicurezza, puoi scegliere di richiedere una rete autorizzata o utilizzare il proxy di autenticazione Cloud SQL. 

Valuta l'utilizzo del proxy di autenticazione Cloud SQL per le connessioni sicure

Il proxy di autenticazione Cloud SQL fornisce accesso sicuro all'istanza Cloud SQL anziché configurare SSL o le reti autorizzate. L'applicazione comunica con il client proxy di autenticazione, che viene eseguito nell'ambiente locale e utilizza un tunnel sicuro per comunicare con il server proxy sull'istanza Cloud SQL.

Abilita i backup e il recupero point-in-time e rivedi il criterio di conservazione 

I backup regolari dei dati e il recupero dei dati verificabili sono fondamentali per una gestione di database efficace. Queste prassi sono inestimabili in situazioni come il danneggiamento dei dati o le operazioni non intenzionali sui dati, nessuna delle quali può essere mitigata dall'alta disponibilità. 

Cloud SQL offre backup automatici, verifica dei backup e recupero point-in-time (PITR). Questi sono abilitati per impostazione predefinita e sono necessari per le istanze con più zone. I backup automatici vengono eseguiti ogni giorno e il criterio di conservazione predefinito prevede sette copie di backup e sette giorni di log binari (richiesti per il PITR). Puoi modificare il criterio di conservazione nella sezione Opzioni avanzate.

I flag di database sono configurazioni server che vanno al file my.cnf. È presente un elenco di flag di database configurabili, mentre alcuni flag gestiti non sono configurabili. È consigliabile rivedere i flag di database e configurarli sul valore corretto al momento della creazione dell'istanza. Poiché alcuni flag di database non sono dinamici, la loro modifica attiverà il riavvio dell'istanza. 

Esamina il valore di character_set_server 

Nelle istanze di Cloud SQL per MySQL, il valore predefinito di character_set_server è utf8 in v5.6 e v5.7 e utf8mb4 in v8.0. Il flag character_set_server determina l'impostazione di character_set_server, character_set_server, character_set_server, character_set_server sullo stesso valore. Per character_set_system, il valore predefinito è utf8mb3 in v8.0. 

Se stai eseguendo la migrazione di un'istanza e la configurazione attuale utilizza un set di caratteri diverso (ad esempio, latin1), assicurati di impostare character_set_server in modo esplicito sulla nuova istanza. 

Esamina il valore di time_zone

Per impostazione predefinita, il fuso orario è system_time_zone, ossia UTC. Se vuoi utilizzare un fuso orario diverso, impostalo tramite default_time_zone. Questo flag ha due formati: differenza di fuso orario, ad esempio +08:00, e nomi dei fusi orari, ad esempio America/Los_Angeles. Quando il fuso orario viene definito dai nomi dei fusi orari, si adatta automaticamente all'ora legale (se pertinente). Il flag default_time_zone non è dinamico e richiede il riavvio dell'istanza del database per apportare una modifica. 

Abilita log delle query lente 

Per impostazione predefinita, slow_query_log è impostato su OFF. Ti consigliamo vivamente di abilitare il log delle query lente e di impostare slow_query_log su una soglia significativa per l'applicazione. Il log delle query lente consente di acquisire le query a lunga esecuzione a scopo di analisi e ottimizzazione. Queste informazioni non sono utili solo per le singole query, ma anche per la velocità effettiva complessiva del server e l'analisi retrospettiva dei carichi di lavoro imprevisti. 

Esamina innodb_buffer_pool_size

Questa è la configurazione più efficace per le prestazioni InnoDB. Maggiore è la quantità di dati che possono eseguire il buffering in memoria, migliori saranno le prestazioni del tuo server. Allo stesso tempo, deve essere presente un numero sufficiente di memorie riservate ai buffer globali e ai buffer dinamici per thread. 

In Cloud SQL, i valori predefiniti, minimi e massimi consentiti del flag innodb_buffer_pool_size dipendono dalla memoria dell'istanza come descritto nella documentazione. 

Un flag innodb_buffer_pool_size efficace non deve contenere tutti i dati, ma solo quelli a cui si accede di frequente. Le variabili di stato che riflettono l'efficienza del pool di buffer sono Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests. Innodb_buffer_pool_read_requests è il numero di richieste di lettura logiche, mentre Innodb_buffer_pool_read_requests è il numero di letture logiche che non sono state soddisfatte dal pool di buffer e che hanno dovuto essere lette dal disco. In un caso ideale in cui i dati si trovino completamente nel pool di buffer, il rapporto di Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests sarebbe vicino a zero. Il monitoraggio di queste variabili darebbe un'idea dell'efficienza del pool di buffer InnoDB. Se per innodb_buffer_pool_size è stato raggiunto il valore massimo consentito, l'efficienza del pool di buffer non è buona e l'applicazione soffre di problemi di prestazioni delle query, valuta la possibilità di eseguire l'upgrade dell'istanza per avere una memoria più grande. 

Questa variabile diventa dinamica in MySQL v5.7 e v8.0, mentre in v5.6, la modifica richiede il riavvio dell'istanza. 

Esamina innodb_log_file_size

Prima della versione 8.0.30, innodb_log_file_size e innodb_log_file_size non erano dinamici e la modifica di innodb_log_file_size richiedeva una chiusura normale. Nella versione 8.0.30, è stato introdotto innodb_redo_log_capacity per sostituire innodb_redo_log_capacity e innodb_redo_log_capacity.  

Le istanze Cloud SQL per MySQL sono configurate con innodb_log_file_size=512MB, innodb_log_file_size=2 (o innodb_log_file_size=1GB). Ciò consente a InnoDB di conservare un numero maggiore di modifiche nel pool di buffer senza sincronizzazione con il disco, migliorando così le prestazioni del server. Lo svantaggio dei file di log di ripetizione di grandi dimensioni è che il recupero da arresti anomali richiede più tempo. A seconda dei requisiti e della configurazione relativi all'alta disponibilità dell'istanza, questa decisione richiede un equilibrio tra prestazioni e disponibilità. 

In genere, consigliamo di creare file di log di ripetizione abbastanza grandi da contenere le attività di scrittura che possono essere eseguite nel corso di un'ora. Un metodo di valutazione è osservare Innodb_os_log_written nell'arco di una giornata e quindi assicurarsi che Innodb_os_log_written * Innodb_os_log_written sia abbastanza grande per l'orario di picco osservato. 

Esamina innodb_log_buffer_size 

In MySQL v5.6 e v5.7, innodb_log_buffer_size non è dinamico e la sua modifica richiede un riavvio dell'istanza. Pertanto, è meglio impostarlo al momento dell'inizializzazione. 

Quando innodb_log_buffer_size è abbastanza grande da contenere l'intera transazione, non ci sarà alcun ulteriore flush nel disco durante l'esecuzione della transazione. Per impostazione predefinita, innodb_log_buffer_size è impostato su 16 MB, generalmente sufficiente. Tuttavia, per capire se una transazione di grandi dimensioni può richiedere un buffer più grande, monitora la variabile di stato Innodb_log_waits quando esegui una transazione di grandi dimensioni. Se innodb_log_buffer_size è troppo piccolo e deve attendere un flush, innodb_log_buffer_size aumenterà di uno. 

Modifica le variabili dinamiche man mano che procedi

Alcuni flag di database correlati alle prestazioni sono dinamici, ad esempio table_open_cache e thread_cache_size. All'inizio è bene avere la dimensione giusta, mentre è consigliabile effettuare le misurazioni e perfezionarle in base alle esigenze. 

table_open_cache indica il numero di tabelle aperte. Avere una cache sufficiente contribuisce a ridurre il tempo di apertura delle tabelle, migliorando quindi le prestazioni delle query. La variabile di stato Opened_tables mostra il numero di tabelle aperte. Se Opened_tables continua a crescere, ti consigliamo di aumentare Opened_tables. 

thread_cache_size serve per memorizzare nella cache i thread per riutilizzarli dopo la disconnessione dei client. Se un'istanza prevede molte nuove connessioni simultanee, imposta una dimensione maggiore. Il rapporto tra le variabili di stato Threads_created e le connessioni mostra l'efficienza della cache dei thread. Un rapporto basso è preferibile. 

Fai attenzione ai flag di memoria associati a singoli thread

Sono presenti buffer di memoria per thread che influiscono sulle prestazioni delle query, ad esempio tmp_table_size, tmp_table_size, tmp_table_size e tmp_table_size. e altri. Queste variabili hanno un ambito sia globale che della sessione. L'ambito globale imposta il valore per thread per tutte le nuove connessioni, mentre l'ambito della sessione è efficace per le query successive nella sessione corrente. Una memoria più grande per impostazioni come queste porta a migliori prestazioni delle query. Tuttavia, a causa della loro dinamicità e della relativa allocazione di una o più per thread, possono portare a scenari di esaurimento della memoria.

È preferibile utilizzare numeri moderati per valori globali e riservare i numeri più grandi per sessioni specifiche in modo da ottenere prestazioni migliori in modo controllato.

Valuta performance_schema 

Per impostazione predefinita, performance_schema è impostato su OFF prima di MySQL v8.0.26 e richiede un riavvio per attivarlo. performance_schema abilita una varietà di strumentazioni e fornisce un ricco set di dati per l'analisi delle operazioni del server, ma comporta dei costi in termini di prestazioni e memoria. Le strumentazioni predefinite producono cali di prestazioni di circa il 5%, e questo aumenterà man mano che vengono aggiunti altri strumenti. Confronta le strumentazioni con il tuo carico di lavoro, poiché il consumo di memoria può crescere fino a 1 GB o più. Puoi osservare questo consumo di memoria nella tabella memory_summary_global_by_event_name. 

Dopo aver creato l'istanza Cloud SQL, è disponibile un utente del database, 'root'@'%'. Probabilmente dovrai creare altri utenti del database. 

Limita l'accesso degli utenti alle operazioni necessarie

Limita sempre l'accesso degli utenti alle esigenze minime. 

Quando crei un utente tramite l'interfaccia a riga di comando di MySQL, devi concedere esplicitamente i privilegi. 

Quando crei un utente tramite la console Cloud, l'utente ha gli stessi privilegi dell'utente "root'@'%". In MySQL v5.6 e v5.7, i privilegi predefiniti includono tutti i privilegi con l'opzione di concessione, ad eccezione dei privilegi SUPER e FILE. Nella versione 8.0, l'utente dispone di privilegi dinamici e, sebbene i privilegi SUPER e FILE siano ancora limitati, gli utenti hanno a disposizione altri ruoli amministrativi (ad esempio, APPLICATION_PASSWORD_ADMIN, APPLICATION_PASSWORD_ADMIN, APPLICATION_PASSWORD_ADMIN, APPLICATION_PASSWORD_ADMIN e APPLICATION_PASSWORD_ADMIN). Dovrai revocare eventuali privilegi non necessari tramite l'interfaccia a riga di comando di MySQL. Nelle istanze v8.0, la variabile partial_revokes è abilitata. 

Prendi in considerazione la sostituzione di 'root'@'%' con un utente amministratore specifico

L'utente 'root'@'%' è il super user predefinito e più popolare e pertanto è spesso preso di mira dagli hacker. Consigliamo di creare i tuoi utenti amministratore con lo stesso insieme di privilegi dell'utente 'root'@'%' e di sostituirlo per una maggiore sicurezza.

È molto importante monitorare e tenere traccia di vari aspetti delle operazioni del database e delle risorse di sistema. Questo consente di rivedere e analizzare l'integrità operativa dell'istanza nel tempo, il che può essere utile anche per la pianificazione delle risorse. 

• La pagina Panoramica della console Cloud contiene un elenco delle metriche principali. 
• Cloud Monitoring offre metriche aggiuntive. Puoi creare una dashboard con metriche selezionate per le istanze DB. Nel menu di navigazione in alto a sinistra della console Cloud, scegli OPERAZIONI --> Monitoring per accedere a Cloud Monitoring. 
• Utilizza Query Insights in Cloud SQL per l'analisi delle prestazioni delle query. La sezione Panoramica mostra il carico della CPU suddiviso per database, utente o indirizzo client. L'utilizzo della CPU è inoltre suddiviso per mostrare l'attesa I/O e l'attesa blocco. Elenca anche le query principali in base al digest delle query. Per ogni digest delle query, puoi vedere il tempo di esecuzione medio, il numero di query e la media delle righe analizzate e restituite. Queste metriche sono molto utili per identificare gli hotspot e le query da ottimizzare. 
• A quanto indicato sopra, puoi anche integrare strumenti di monitoraggio locali e/o di terze parti. L'obiettivo principale è comprendere le operazioni del database che possono influenzare l'ottimizzazione e la risoluzione dei problemi di server e query. 

Avvisi corretti sono un elemento fondamentale per l'integrità del server. Consentono di evitare interruzioni dei servizi come l'esaurimento della memoria (OOM) o blocchi di sistema causati dalla saturazione della CPU. 

Se utilizzi Cloud Monitoring, puoi creare avvisi basati su metriche. Per informazioni dettagliate, consulta la documentazione. 

Se utilizzi altri strumenti di monitoraggio, assicurati di configurare gli avvisi.

Per scalare le letture, valuta la possibilità di aggiungere repliche di lettura. Puoi utilizzare HAProxy, ProxySQL o un altro bilanciatore del carico per distribuire le letture tra più repliche di lettura. 

Cloud SQL supporta anche la replica concatenata, su cui puoi trovare informazioni nelle repliche a cascata.  

Le repliche di lettura vengono create con la stessa versione MySQL dell'istanza principale. Dopo la creazione, puoi scegliere di eseguire l'upgrade della replica a principale.

La soluzione ad alta disponibilità fornisce la ridondanza dei dati in una zona secondaria all'interno della stessa regione. In caso di emergenza, una regione potrebbe non essere più disponibile. Le repliche di lettura tra regioni sono una risorsa importante in un piano di ripristino di emergenza, in quanto possono essere promosse a istanza principale quando necessario. Per ulteriori dettagli, consulta la documentazione.