I giorni più importanti dell'anno per lo shopping online sono proprio dietro l'angolo. Il tuo database è pronto? Ottimizzando 20 variabili di sistema chiave di MariaDB, rafforzerai le prestazioni del tuo database , scalabilità e disponibilità , garantendo a ogni potenziale cliente un'esperienza utente fluida. Le seguenti variabili di sistema vengono visualizzate ripetutamente durante la configurazione di un ambiente server MariaDB ottimale. Implementa i nostri consigli per i valori più sintonizzati e rendi il periodo tra il Black Friday e il Cyber Monday di quest'anno il migliore di sempre.
Un paio di note importanti:
- Non accettare ciecamente questi suggerimenti. Ogni ambiente MariaDB è unico e richiede ulteriori riflessioni prima di apportare modifiche. Molto probabilmente dovrai modificare queste impostazioni per il tuo caso d'uso e ambiente specifico.
- Il file di configurazione di MariaDB si trova in /etc/my.cnf. Ogni volta che modifichi questo file dovrai riavviare il servizio MySQL in modo che le nuove modifiche abbiano effetto.
20 Consigli per l'ottimizzazione del Black Friday e del Cyber Monday
1. Dimensioni del pool di buffer InnoDB
La dimensione del pool di buffer InnoDB questa è l'impostazione n. 1 da considerare per qualsiasi installazione utilizzando InnoDB. Il pool di buffer è il luogo in cui i dati e gli indici vengono memorizzati nella cache; averlo il più grande possibile ti assicurerà di utilizzare la memoria e non i dischi per la maggior parte delle operazioni di lettura.
2. Dimensioni del file di registro di InnoDB
innodb_log-file-size è la dimensione dei log di ripristino, utilizzati per assicurarsi che le scritture siano veloci e durature. Esistono due suggerimenti generali per il dimensionamento del file di registro di InnoDB:
- Imposta la dimensione totale combinata dei file di registro di InnoDB maggiore del 25–50% della dimensione del pool di buffer InnoDB
o
- Imposta la dimensione del registro del file di registro InnoDB combinato su un valore di un'ora di voci di registro durante il carico di picco
File di registro più grandi possono rallentare il ripristino in caso di arresto anomalo del server. Tuttavia, riducono anche il numero di checkpoint necessari e riducono l'I/O del disco.
Valuta la dimensione di un'ora di log binari sotto carico operativo, quindi decidi se aumentare la dimensione dei file di log di InnoDB.
La corretta dimensione del file di registro di innodb è importante per ottenere buone prestazioni del sistema. Il motore di archiviazione InnoDB di MariaDB utilizza uno spazio di log di ripristino (circolare) di dimensioni fisse. La dimensione è controllata da innodb_log_file_size e innodb_log_files_in_group (predefinito 2). Moltiplica questi valori per ottenere lo spazio del registro di ripristino disponibile per l'uso. Anche se tecnicamente non dovrebbe importare se usi la variabile innodb_log_file_size o innodb_log_files_in_group per controllare la dimensione dello spazio di ripristino, la maggior parte delle persone lavora semplicemente con innodb_log_file_size e lascia innodb_log_files_in_group da solo.
La dimensione dello spazio di ripristino di InnoDB è una delle opzioni di configurazione più importanti per i carichi di lavoro ad alta intensità di scrittura. Tuttavia, viene fornito con dei compromessi. Maggiore è lo spazio di ripristino configurato, migliore è la capacità di InnoDB di ottimizzare l'I/O di scrittura. Tuttavia, aumentare lo spazio di ripristino significa anche tempi di ripristino più lunghi quando il sistema perde alimentazione o si arresta in modo anomalo per altri motivi.
3. Dimensioni del buffer di registro InnoDB
Una dimensione del buffer di log InnoDB maggiore significa meno I/O del disco per transazioni più grandi. Si consiglia di impostarlo su 64M su tutti i server.
4. Intervallo di svuotamento registro InnoDB
La variabile innodb_flush_log_at_trx_commit controlla quando si verifica lo svuotamento del buffer di log su disco. innodb_flush_log_at_trx_commit =1 (predefinito) scarica il buffer di log su disco a ogni commit della transazione. Questa è l'opzione più sicura ma anche meno performante.
innodb_flush_log_at_trx_commit =0 scarica il buffer di log su disco ogni secondo, ma nulla durante il commit della transazione. È possibile che si perda fino a un secondo (forse di più a causa della pianificazione del processo). In caso di arresto anomalo, MySQL o il server possono perdere dati. Questa è l'opzione più veloce ma meno sicura.
innodb_flush_log_at_trx_commit =2 scrive il buffer di log in un file su ogni commit ma scarica su disco ogni secondo. Se la cache del disco ha una batteria di backup (ad esempio un controller raid della cache con batteria tampone), questo è generalmente il miglior equilibrio tra prestazioni e sicurezza. Un crash di MySQL non dovrebbe perdere dati. Un arresto anomalo del server o un'interruzione di corrente potrebbe perdere fino a un secondo (probabilmente di più a causa della pianificazione del processo). Una cache con batteria tampone riduce questa possibilità.
Suggeriamo di utilizzare la prima opzione per sicurezza.
5. Capacità di InnoDB IO
innodb_io_capacity dovrebbe essere impostato approssimativamente sul numero massimo di IOPS che l'archiviazione sottostante può gestire.
Per impostazione predefinita, è impostato su 1000. Ti consigliamo di eseguire un benchmarking dello spazio di archiviazione per determinare se puoi aumentare ulteriormente questo valore.
Monitoraggio il valore di Threads_created. Se continua ad aumentare a più di pochi thread al minuto, aumenta il valore di thread_cache_size.
La dimensione della cache del thread è impostata su 200 nella configurazione predefinita corrente.
Le variabili table_open_cache e table_defintion_cache controllano il numero di tabelle e definizioni da mantenere aperte per tutti i thread.
Monitora Open_tables, Open_table_definitions, Opened_tables e Opened_table_definitions per determinare il valore migliore. Il suggerimento generale è di impostare table_open_cache (e successivamente table_definition_cache) solo sufficientemente alto da ridurre il tasso di aumento del valore di stato Opened_tables (e Opened_table_definitions).
Sia table_open_cache che table_defintion_cache sono impostati su 2048 nella configurazione predefinita.
8. Cache delle query
La cache delle query è un noto collo di bottiglia che può essere visto anche quando la concorrenza è moderata. L'opzione migliore è disabilitarla dal primo giorno impostando query_cache_size =0 (l'impostazione predefinita in MariaDB 10) e utilizzare altri modi per velocizzare le query di lettura:avere una buona indicizzazione, aggiungere repliche per distribuire il carico di lettura o utilizzare una cache esterna ( memcache o redis, per esempio). Se hai già creato la tua applicazione MariaDB con la cache delle query abilitata e non hai mai notato alcun problema, la cache delle query potrebbe essere utile per te. In tal caso, sii prudente se decidi di disabilitarlo.
9. Tabelle temporanee, tmp_table_size e max_heap_table_size
MySQL utilizza il valore più basso tra max_heap_table_size e tmp_table_size per limitare la dimensione delle tabelle temporanee in memoria. Queste sono variabili per client. Sebbene avere questo valore di grandi dimensioni può aiutare a ridurre il numero di tabelle temporanee create su disco, aumenta anche il rischio di raggiungere la capacità di memoria del server poiché questa è per client. Generalmente da 32M a 64M è il valore suggerito per iniziare per entrambe le variabili e regolarlo secondo necessità.
Le tabelle temporanee vengono spesso utilizzate per GROUP BY, ORDER BY, DISTINCT, UNION, sotto query e così via. Idealmente, MySQL dovrebbe crearle in memoria, con il minor numero possibile di su disco.
È importante notare che le query che non utilizzano i join in modo appropriato e la creazione di tabelle temporanee di grandi dimensioni possono essere una delle ragioni per un numero maggiore di tabelle temporanee su disco. Un altro motivo è che il motore di archiviazione della memoria utilizza colonne di lunghezza fissa e presuppone lo scenario peggiore. Se le colonne non sono dimensionate correttamente (ad esempio, un VARCHAR(255) per una stringa breve), ciò influisce sulla dimensione della tabella in memoria e può farla andare su disco prima di quanto dovrebbe. Inoltre, le tabelle temporanee con BLOB e colonne di testo andranno immediatamente su disco, poiché il motore di archiviazione della memoria non le supporta.
Entrambi sono attualmente impostati su 64 milioni per impostazione predefinita.
10. Livello del registro di avviso
Ti consigliamo di impostare il livello del registro di avviso su log_warnings =2. In questo modo vengono registrate le informazioni sulle connessioni interrotte e sugli errori di accesso negato.
Se riscontri spesso l'errore "Troppe connessioni", max_connections è troppo basso. Spesso, poiché l'applicazione non chiude correttamente le connessioni al database, sono necessarie molte più connessioni rispetto alle 151 connessioni predefinite. Lo svantaggio principale di valori elevati per max_connections (diciamo, 1.000 o più) è che il server non risponderà se deve eseguire tante transazioni attive. L'uso di un pool di connessioni a livello di applicazione o di un pool di thread a livello di MariaDB può essere d'aiuto in questo caso.
12. Isolamento delle transazioni
Esamina i livelli di isolamento delle transazioni disponibili e determina il miglior isolamento delle transazioni per il caso d'uso del tuo server.
13. Formato registro binario
Consigliamo di utilizzare il formato di log binario ROW per la replica master-master.
Per ridurre le possibilità di collisione tra due master scritti su simultaneamente, i valori di incremento automatico e offset di incremento automatico devono essere regolati di conseguenza.
15. Sincronizza Binlog
Per impostazione predefinita, il sistema operativo gestisce lo svuotamento del binlog sul disco. In caso di arresto anomalo del server, è possibile che le transazioni del log binario vengano perse, con la conseguenza che la replica non è sincronizzata. L'impostazione di sync_binlog =1 provoca lo svuotamento del file binlog ad ogni commit.
Questa è più lenta, ma l'opzione più sicura.
16. Schiavi Crash Safe(r)
Per evitare errori di replica dopo un arresto anomalo dello slave, abilita il ripristino del registro di inoltro e la sincronizzazione del registro di inoltro e i file di informazioni del registro di inoltro su disco.
Per avere la replica concatenata (master -> slave -> slave), log_slave_updates deve essere abilitato. Questo dice a uno slave di scrivere le transazioni replicate nel proprio log binario in modo che possano essere replicate in slave al di fuori di esso.
Gli slave dovrebbero essere di sola lettura per evitare che i dati vengano scritti loro accidentalmente.
Nota :gli utenti con privilegi super possono ancora scrivere quando il server è di sola lettura.
19. Timeout rete slave
La variabile slave_net_timeout è il numero di secondi che lo slave attende per un pacchetto dal master prima di tentare di riconnettersi. Il valore predefinito è 3600 (1 ora). Ciò significa che se il collegamento si interrompe e non viene rilevato, potrebbe trascorrere fino a un'ora prima che lo slave si riconnetta. Ciò potrebbe portare lo schiavo a trovarsi improvvisamente fino a un'ora indietro rispetto al padrone.
Consigliamo di impostare slave_net_timeout su un valore più ragionevole, ad esempio 30 o 60.
20. Guarda il nostro webinar sulla preparazione per il Black Friday e il Cyber Monday
Guarda il nostro webinar su richiesta – Prepararsi per il Black Friday e il Cyber Monday – per apprendere i quattro principi vitali della preparazione del database: misure di sicurezza per proteggere il tuo database da attacchi dannosi, ottimizzazione delle prestazioni per assicurarti un'esperienza utente fluida, strategie di disponibilità elevata per assicurarti di non perdere nemmeno una vendita e la scalabilità per prepararsi sia alla crescita prevista che a picchi imprevisti.
