Best practice per la configurazione di un'istanza di Cloud SQL per MySQL
Anche se puoi eseguire il deployment di MySQL manualmente sulla tua macchina fisica o anche su una macchina virtuale e scegliere di gestirlo autonomamente, un'opzione sempre più diffusa è l'utilizzo di un'offerta gestita da un provider di servizi cloud che si occupa di numerosi aspetti operativi della gestione di MySQL.
Articoli correlati
Best practice
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 dell'interfaccia utente, l'interfaccia a riga di comando gcloud, 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 l'interfaccia utente a scopi illustrativi durante la trattazione di una serie di best practice per la configurazione di un'istanza.
Informazioni istanza
Crea una password efficace
Questa è la password per l'utente predefinito del database "root"@"%" che verrà creato con l'istanza. Se intendi mantenere l'utente root come utente amministratore, assicurati di scegliere una password efficace qui. Per motivi di sicurezza, è consigliabile utilizzare un utente amministratore meno comune invece di utilizzare "root". Fai riferimento alla sezione "Gestire 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.
Versione database
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.
Alta disponibilità
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 ottimizzare disponibilità, configura l'opzione relativa alle zone multiple 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").
Tipo di macchina
Valuta l'utilizzo attuale di CPU/memoria per prendere decisioni informate per la migrazione
Quando esegui la migrazione di un'istanza esistente in Cloud SQL, il tuo attuale carico di lavoro può aiutarti a scegliere le dimensioni delle VM corrette.
- CPU: qual è il tuo utilizzo della CPU in condizioni normali del carico di lavoro? E per quanto riguarda il carico di lavoro di picco? L'istanza è CPU-bound o I/O-bound? Una percentuale di CPU utente e/o di sistema relativamente elevata è sintomo di un carico di lavoro CPU-bound. Una percentuale di I/O relativamente elevata è sintomo di un carico di lavoro I/O-bound.
- Memoria: allo stesso modo, qual è il normale utilizzo della memoria per l'istanza e qual è il picco di utilizzo?
Come riferimento, 1 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 agli upgrade è associato un certo tempo di inattività.
Personalizzare lo spazio di archiviazione
Usa SSD per prestazioni del database migliori
Cloud SQL per MySQL offre HDD come opzione di archiviazione economica, ma se sai che hai bisogno di un database ad alte prestazioni, opta per l'opzione SSD. Vedi questo confronto delle prestazioni di I/O.
Pianifica il bilanciamento tra prestazioni e costi in termini di capacità di archiviazione
Le IOPS e la velocità effettiva del disco sono correlate alle dimensioni del disco permanente. Una capacità maggiore consente di ottenere un numero maggiore di IOPS e velocità entro i limiti dell'istanza.
Per quanto riguarda gli SSD, le configurazioni a livello di zona e di regione influiranno sulle prestazioni. Consulta i dati sulle prestazioni degli SSD a livello di zona e di regione per ulteriori dettagli. Se hai selezionato 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 GB e la velocità effettiva è di 0,48 MB per GB. Con SSD a livello di regione, i dati sulle prestazioni sono simili, tranne per il fatto che le IOPS di scrittura per istanza e la velocità effettiva di scrittura sono inferiori.
Tieni presente che la dimensione massima 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 impedire l'esaurimento dello spazio di archiviazione da parte delle istanze (OOD, Out Of Disk space). Se la funzionalità è abilitata, lo spazio di archiviazione viene controllato ogni 30 secondi e verrà aggiunta capacità di archiviazione incrementale quando necessario.
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, esiste un'opzione per utilizzare una chiave di crittografia gestita dal cliente (CMEK, Customer-Managed Encryption Key) anziché la chiave predefinita gestita da Google, se più adatta alle tue esigenze.
Configura connessioni
Valuta il compromesso tra IP privato e IP pubblico
Gli IP privati e pubblici si riferiscono ai tipi di indirizzi utilizzati dai dispositivi in una rete. L'IP privato offre maggiore sicurezza della rete e minore latenza di rete rispetto all'IP pubblico. Tuttavia, l'IP privato richiede configurazioni aggiuntive di API e IAM per la configurazione, e talvolta l'IP pubblico è effettivamente necessario. Se sai di dover utilizzare un IP pubblico, ma vuoi migliorare la sicurezza, puoi scegliere di richiedere una rete autorizzata o di 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 l'accesso sicuro all'istanza Cloud SQL al posto della configurazione di reti SSL o 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.
Configura la pianificazione e la conservazione dei backup
Abilita backup e recupero point-in-time ed esamina il tuo criterio di conservazione
Backup regolari dei dati e recupero verificabile dei dati sono fondamentali per una gestione efficace dei database. 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). Queste funzionalità sono abilitate per impostazione predefinita e sono obbligatorie sulle 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 (obbligatorio per PITR). Puoi modificare il criterio di conservazione nella sezione Opzioni avanzate.
Configurazione dei flag di database
I flag di database sono configurazioni di server che vanno al file my.cnf. È disponibile un elenco di flag db configurabili e alcuni flag gestiti che non possono essere configurati. È buona prassi esaminare i flag db e configurarli sul valore corretto al momento della creazione dell'istanza. Perché alcuni flag db non sono dinamici, e quindi la loro modifica causerebbe il riavvio di un'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_client, character_set_connection, character_set_database, character_set_results sullo stesso valore. Per character_set_system, il valore predefinito è utf8mb3 in v8.0.
Se esegui la migrazione di un'istanza e la configurazione attuale utilizza un set di caratteri diverso (ad esempio, latin1), assicurati di impostare esplicitamente character_set_server nella nuova istanza.
Esamina il valore di time_zone
Per impostazione predefinita, il fuso orario corrisponde a system_time_zone, ossia UTC. Se vuoi utilizzare un fuso orario diverso, impostalo tramite default_time_zone. Questo flag ha due formati: fuso orario, ad esempio +08:00, e nomi dei fusi orario, ad esempio America/Los_Angeles. Quando il fuso orario è definito dai nomi dei fusi orari, si regola automaticamente all'ora legale (se pertinente). Il flag default_time_zone non è dinamico e richiede il riavvio dell'istanza del db per apportare la modifica.
Attiva il 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 long_query_time su una soglia appropriata per l'applicazione. Il log delle query lente aiuta ad individuare query a lunga esecuzione per l'analisi e l'ottimizzazione. Queste informazioni non aiutano solo con singole query, ma anche con 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 di InnoDB. Maggiore è la quantità di dati che possono essere salvati nel buffer di memoria, migliori saranno le prestazioni del server. Al tempo stesso, è necessario che sia disponibile memoria sufficiente per i buffer globali e per i buffer dinamici associati ai singoli 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 innodb_buffer_pool_size valido 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_reads indica il numero di letture logiche non soddisfatte dal pool di buffer e che è stato quindi necessario effettuare dal disco. Nel caso ideale in cui i dati sono tutti contenuti nel buffer, il rapporto espresso da Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests sarebbe vicino a zero. Il monitoraggio di queste variabili è utile per comprendere l'efficienza del pool di buffer InnoDB. Se il valore di innodb_buffer_pool_size è pari al massimo consentito, l'efficienza del pool di buffer è insufficiente e l'applicazione sta riscontrando problemi di prestazioni delle query, valuta la possibilità di eseguire l'upgrade dell'istanza in modo che la quantità di memoria disponibile si maggiore.
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_files_in_group non erano dinamici e, per modificare, innodb_log_file_size era necessario un arresto completo. Nella versione 8.0.30, è stato introdotto innodb_redo_log_capacity per sostituire innodb_log_file_size e innodb_log_files_in_group.
Le istanze Cloud SQL per MySQL sono configurate con innodb_log_file_size=512 MB, innodb_log_files_in_group=2 (o innodb_redo_log_capacity=1 GB). Ciò consente a InnoDB di conservare un numero maggiore 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 ripetizioni abbastanza grandi da contenere le attività di scrittura eseguite nel corso di un'ora. Un modo per valutare questo problema è osservare Innodb_os_log_written durante una giornata e quindi assicurarti che innodb_log_file_size * innodb_log_files_in_group sia abbastanza grande per l'orario di picco osservato.
Esamina nonodb_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.
Se innodb_log_buffer_size è abbastanza grande da contenere l'intera transazione, non ci saranno ulteriori operazioni di flush nel disco durante l'esecuzione della transazione. Per impostazione predefinita, innodb_log_buffer_size è impostato su 16 MB, che è 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 il flush, Innodb_log_waits aumenterà di uno.
Modifica le variabili dinamiche man mano che procedi
Alcuni flag db correlati alle prestazioni sono dinamici, come table_open_cache e thread_cache_size. È una buona idea impostare le dimensioni giuste per iniziare, mentre è consigliabile stabilire le misurazioni e di regolarle secondo le necessità.
table_open_cache indica il numero di tabelle aperte. Una cache di dimensioni sufficienti aiuta a ridurre i tempi di apertura delle tabelle, migliorando quindi le prestazioni delle query. La variabile di stato Opened_tables mostra il numero di tabelle che sono state aperte. Se Opened_tables continua a crescere, valuta la possibilità di aumentare table_open_cache.
thread_cache_size serve per la memorizzazione nella cache dei thread per il riutilizzo dopo la disconnessione dei client. Se per un'istanza sono previste molte nuove connessioni simultanee, imposta una dimensione maggiore. Il rapporto tra le variabili di stato Threads_created e Connections mostra l'efficienza della cache dei thread. Un rapporto basso è meglio.
Fai attenzione ai flag di memoria associati a singoli thread
Alcuni buffer di memoria associati a singoli thread influiscono sulle prestazioni delle query, ad esempiotmp_table_size, max_heap_table_size, join_buffer_size, sort_buffer_size e altri. Queste variabili hanno un ambito sia globale che di sessione. L'ambito globale imposta il valore per thread per tutte le nuove connessioni, mentre l'ambito di sessione è efficace per le query successive nella sessione attuale. Una memoria più grande per impostazioni come queste porta a prestazioni delle query migliori. Tuttavia, poiché sono dinamiche e allocano uno o più per thread, possono portare a scenari di memoria esaurita.
È preferibile utilizzare numeri moderati per valori globali e riservare numeri più grandi per sessioni specifiche in modo da ottenere prestazioni migliori in modo controllato.
Prendi in considerazione performance_schema .
L'impostazione predefinita di performance_schema per le versioni inferiori a MySQL v8.0.26 è OFF e richiede un riavvio per l'attivazione. performance_schema abilita una vasta gamma di strumentazioni e fornisce un ricco set di dati per analizzare le operazioni del server, ma include i costi legati sia alle prestazioni che alla memoria. Le strumentazioni predefinite provocano cali di prestazioni pari a circa il 5% e questo numero aumenta man mano che vengono aggiunti altri strumenti. Misura il benchmark delle strumentazioni con il tuo carico di lavoro, poiché il consumo di memoria può aumentare fino a 1 GB. Puoi osservare questo consumo di memoria nella tabella memory_summary_global_by_event_name.
Gestire gli utenti del database
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 Google Cloud, questo avrà gli stessi privilegi dell'utente 'root'@'%'. In MySQL v5.6 e v5.7, i privilegi predefiniti includono tutti i privilegi con l'opzione grant, ad eccezione dei privilegi SUPER e FILE. Nella versione 8.0, l'utente dispone di privilegi dinamici e, mentre i privilegi SUPER e FILE sono ancora soggetti a restrizioni, sono disponibili altri ruoli amministrativi (ad esempio, APPLICATION_PASSWORD_ADMIN), CONNECTION_ADMIN, ROLE_ADMIN, SET_USER_ID e XA_RECOVER_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.
Configura il monitoraggio
È molto importante monitorare e tenere traccia di vari aspetti delle operazioni del database e delle risorse di sistema. In questo modo è possibile rivedere e analizzare l'integrità operativa dell'istanza nel tempo, il che può essere utile per la pianificazione delle risorse.
- La pagina di riepilogo della console Google Cloud include un elenco delle metriche principali.
- Cloud Monitoring offre metriche aggiuntive. Puoi creare una dashboard con le metriche selezionate per le tue istanze db. In Cloud Console, dal menu di navigazione in alto a sinistra, scegli OPERAZIONI --> Monitoring per accedere a Cloud Monitoring.
- Utilizza Query Insights in Cloud SQL per l'analisi delle prestazioni delle query. La relativa sezione Panoramica mostra il carico della CPU suddiviso per database, utente o indirizzo client. Anche l'utilizzo della CPU è 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 di query, puoi vedere il tempo di esecuzione medio, il numero di query e le righe medie scansionate e restituite. Queste metriche sono molto utili per identificare i punti chiave e le query da ottimizzare.
- Puoi anche integrare questi strumenti con strumenti di monitoraggio interni e/o di terze parti. L'obiettivo principale è comprendere le operazioni del database che possono influenzare l'ottimizzazione e la risoluzione dei problemi del server e delle query.
Configura avvisi
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.
Configurare le repliche
Per assicurare la scalabilità delle 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 in repliche a cascata.
Le repliche di lettura vengono create con la stessa versione MySQL dell'istanza principale. Dopo la creazione, puoi scegliere di eseguire promuovere la replica a istanza principale.
Pianificare il ripristino di emergenza
La soluzione ad alta disponibilità fornisce ridondanza dei dati in una zona secondaria nella stessa regione. In una situazione di emergenza, una regione potrebbe non essere più disponibile. Le repliche di lettura tra regioni sono una valida risorsa in un piano di ripristino di emergenza, in quanto possono essere promosse a istanze principali quando necessario. Per saperne di più, consulta la documentazione.
Prodotti e servizi correlati
Google Cloud offre un database MySQL gestito che è stato creato per soddisfare le tue esigenze aziendali, dal ritiro del data center on-premise all'esecuzione di applicazioni SaaS, fino alla migrazione dei sistemi aziendali principali.
