Galera Cluster for MySQL
Tuning

Galera Cluster for MySQL e' un cluster multimaster basato sulla replicazione sincrona. Per la sua efficienza e scalabilita' sta trovando una sempre maggior diffusione. Gli utilizzi piu' comuni sono per l'implementazione di soluzioni in alta affidabilita' e nelle configurazioni in Cloud.
Il disegno di una corretta configurazione di un Galera richiedono competenze ed esperienza sia sui motori delle basi dati utilizzate (MySQL e MariaDB) che su Galera Cluster. In questa pagina ho cercato di raccogliere i principali elementi utili per il tuning di Galera Cluster.

Questa semplice e pragmatica paginetta riporta quelli che sono i principali parametri di tuning di Galera Cluster evitando di riportare i parametri meno significativi poiche'... sono centinaia ed abbondantemente descritti nelle documentazioni ufficiali.

Nel seguito sono riportate le informazioni di interesse organizzate in paragrafi specifici: Introduzione, Il processo di tuning, Sizing, Tuning, Varie ed eventuali.

Le indicazioni che seguono sono per un pubblico DBA adulto, per i minori o junior consigliamo di approfondire la conoscenza su MySQL, MariaDB, replica MySQL, Galera Cluster, tuning MySQL 5.7, tuning MySQL 8.0, ... prima di leggere questa paginetta!

Introduzione

Galera Cluster for MySQL o MariaDB e' un cluster multimaster basato sulla replicazione sincrona tra nodi in configurazione shared nothing.

I client si collegano ad uno qualsiasi dei database esattamente come se fosse un nodo MySQL standalone ma i dati vengono replicati in modo sincrono su tutti i componenti del cluster; per bilanciare il carico e' possibile utilizzare un qualsiasi proxy o distribuire gli accessi dalle applicazioni.
I nodi di un cluster Galera sono connessi tra loro in configurazione N-N e dialogano mediante l'API wsrep (write set replication API). Vengono gestiti dal cluster i tipici eventi di registrazione dei nodi sul cluster, il trasferimento iniziale dei dati, le situazioni di split-brain, ... Mentre ciascun nodo si occupa localmente di gestire le connessioni con i client ed eseguire le query SQL in modo efficiente.
I nodi vengono mantenuti sempre sincronizzati tra loro replicando le transazioni al momento del commit. La fase di verifica della transazione viene chiamata certification test. Se il risultato e' positivo la transazione viene trasferita (writeset) ed eseguita su tutti i nodi del cluster nello stesso ordine. Se il certification test fallisce la transazione viene abortita con un rollback sul nodo dove e' stata richiesta e l'applicazione dovra' eseguirla nuovamente.
L'algorimo utilizzato da Galera e' di tipo ottimistico ed utilizza una tecnica di ordinamento delle transazioni per ridurre il numero di abort, deadlock e rollback.

I vantaggi di Galera sono:

• HA
  Le transazioni confermate non vengono perse anche nel caso di crash.
• Few Application Changes
  Le applicazioni utilizzano il cluster come se si trattasse di un normale database MySQL (con pochissime differenze).
• Multi-Master
  Tutti i nodi sono paritetici ed effettuano le modifiche sulle stesse tabella in modo concorrente.
• Scalability
  La soluzione e' scalabile anche per applicazioni con un numero abbastanza elevato di DML.
• No specialized hardware
  I nodi non utilizzano dischi shared ma operano sullo storage locale, non sono implementate complesse cache globali, non sono richieste interfacce di rete dedicate per l'heartbeat, ...

La configurazione di Galera e' relativamente semplice e con in parametri di default e' gia' perfettamente funzionante.
Maggiori dettagli sulla configurazione, installazione ed utilizzo di Galera sono riportati su questo documento.

Vi sono pero' anche alcuni limiti in Galera Cluster: non e' un'architettura adatta a tutte le applicazioni ed a tutti i carichi di lavoro.
L'utilizzo di Galera Cluster richiede a volte modifiche alle applicazioni che debbono soddisfare alcune regole per operare correttamente.
L'unico engine supportato e' InnoDB ed ogni tabella deve avere una chiave primaria. Le DDL vanno eseguite con attenzione vi sono limiti alle transazioni: la dimensione massima della trasazioni e' limitata ed in generale e' molto opportuno spezzare grandi transazioni in parti piu' piccole [NdA cosa che puo' portare a performances peggiori]. Non sono supportati: LOCK/UNLOCK table; funzioni di lock (eg. GET_LOCK); transazioni XA; ... Non sono supportati il query logging su tabella e la query cache. Le transazioni possono ricevere l'errore Error: 1213 SQLSTATE: 40001 (ER_LOCK_DEADLOCK) e debbono essere in grado di gestirlo (eg. risottomettendo la transazione).

Dal punto di vista delle prestazioni con un carico transazionale un cluster Galera non puo' mai essere veloce quanto un MySQL standalone o in replica semplice: la fase di certificazione delle transazioni richiede che ogni nodo confermi il commit e questo introduce un ritardo sensibile nella gestione dell'OLTP.

Concludendo se le applicazioni non richiedono funzionalita' particolari (eg. query cache, engine diversi da InnoDB, transazioni di grandi dimensioni, frequenti modifiche agli schema) ed hanno un carico transazionale non elevato l'utilizzo di Galera Cluster e' un'ottima soluzione per distribuire gli accessi e fornire un buon livello di alta affidabilita'.

Attivita' di tuning

Il tuning di una base dati e' un'attivita' che richiede competenza ed esperienza. Se non sapete a cosa serve un parametro... non modificatelo!

Il tuning si fa se e quanto... serve. Se una base dati e' di modeste dimensioni, le applicazioni consolidate, tutto funziona ed i sistemi sono correttamente dimensionati e' sufficiente un'impostazione iniziale ragionevole dei parametri e niente piu'. Quando invece si presentano problemi o si vuole ottenere il massimo da un'architettura complessa il tuning diventa un'attivita' impegnativa ed importante che puo' richiedere diversi cicli per ottenere gli obiettivi previsti.

Nessun tuning si sostituisce ad un disegno corretto della base dati e dell'SQL. Prima di qualsiasi altra attivita' vanno controllati evenuali statement di lunga durata e corretti quelli errati, vanno creati tutti gli indici necessari e, nei casi in cui opportuno, va utilizzato il partitioning e lo sharding.

Misurare, misurare, misurare! Misurare le prestazioni prima delle attivita' di tuning, misurare tutti i test eseguiti e continuare a misurare effettuata una modifica di parametri. Senza misure non si fa tuning. Quali misure? Tutte quelle che servono! In generale dipendono dall'applicazione e dall'utilizzo del database: TPS, MST, Hit Ratio, #utenti, active threads, MTBF (si purtroppo anche questo), ... e dai sistemi ospite: %CPU, %IOW, LA, ... senza dimenticare le due principali: lo spazio ed il tempo (che come e' noto sono fisicamente legati tra loro :).
Se non c'e' una misura prima e dopo la modifica di parametri non si sta eseguendo alcun tuning: se si e' fortunati si ha un effetto placebo, se si e' sfortunati si peggiora il funzionamento.

Tutto cio' premesso... il tuning di una base dati con un Galera Cluster e' rivolto sia alle componenti del cluster che ai parametri tipici di MySQL, nei prossimi capitoli li vedremo entrambe.

Architettura e dimensionamento

Come gia' anticipato con le impostazioni di default Galera Cluster funziona immediatamente ma ci sono alcuni importanti elementi sul sizing e sull'architettura di cui tenere conto.

Per creare un cluster Galera il numero minimo e' di tre nodi. Un cluster Galera risulta correttamente attivo quando viene raggiunto il numero di quorum di nodi connessi: con tre nodi il quorum e' due ed il cluster sopporta un nodo non funzionante. Tuttavia se la caduta/perdita di un nodo risulta frequente e richiede un SST deve essere scelto un nodo come donor e quindi tutto il carico viene rivolto al solo nodo rimanente. Percio' nel caso di un utilizzo significativo in produzione di Galera e' consigliabile utilizzare un cluster a cinque nodi.
In ogni caso non deve mai essere utilizzato un numero pari di nodi: e' una configurazione errata ed il rischio di split brain o di blocco del cluster diventano molto forti.

Poiche' la certificazione delle transazioni deve essere confermata da ogni nodo il cluster va alla velocita' del nodo piu' lento. E' quindi consigliabile utilizzare nodi identici o almeno con le stesse caratteristiche dal punto di vista prestazionale.
I nodi sovvradimensionati consentono di smaltire correttamente il carico richiesto dalle applicazioni anche in caso di situazione degradata, solo in questo modo l'alta affidabilita' puo' essere garantita.

L'aggiunta di piu' nodi in Galera permette di scalare linearmente sulle attivita' in lettura; le attivita' in scrittura non scalano perche' debbono essere eseguite comunque su tutti i nodi. Inoltre l'overhead imposto dal cluster per la certificazione delle transazioni lo rende comunque piu' lento di un nodo MySQL singolo e piu' soggetto alle prestazioni dell'I/O.

Un cluster Galera puo' essere installato su un solo datacenter ma anche su datacenter diversi con un numero variabile di nodi. L'importante e' che il numero di nodi sia sempre dispari. Se distribuito Galera e' su piu' datacenter il numero ideale minimo di segmenti e' tre, ma possibile aggiungere un nodo Arbitrator se sono presenti due soli datacenter.
Un cluster Galera puo' anche essere configurato come Master o come Slave con la normale replica MySQL e' quindi possibile creare architetture distribuite personalizzate a seconda delle esigenze.
Galera sopporta meglio di altri cluster una rete con una latenza variabile. Utilizza infatti diversi protocolli per la riformazione automatica del cluster ed i parametri di default sui tempi di riposta del nodi sono relativamente alti. Vi sono pero' casi in cui la latenza delle trasmissioni, in particolare nelle architetture distribuite in WAN, puo' generare problemi. In questi casi e' possibile agire sulla configurazione come vedremo nel seguito... Ma se a causa di una rete poco affidabile, nonostante il tuning specifico di Galera, il numero di fault risulta troppo elevato non vi e' altra soluzione che rinunciare al cluster ed utilizzare la replica MySQL asincrona.

Nella fase di certificazione possono presentarsi situazioni di deadlock dovute al fatto che la stessa riga e' modificata in modo indipendente su nodi diversi. Se la situazione e' troppo frequente e' possibile indirizzare le applicazioni su un solo nodo in modo che il deadlock venga evitato dai normali meccanismi di locking MySQL. Questo non cambia il sizing del cluster perche' in realta' il carico in scrittura non viene distribuito ma sempre replicato.

Ogni nodo del cluster Galera e' indipendente e gestisce il carico di tutte le sessioni connesse. Il cluster non fornisce alcuna modalita' di bilanciamento dei nodi ma e' possibile utilizzare qualsiasi proxy server o load balancer esterno compatibile con MySQL. In alternativa possono essere le applicazioni che si collegano ai nodi con un ordine stabilito oppure accedendo con priorita' ai nodi locali.
La gestione delle connessioni al DB e' una parte integrante e fondamentale nella definizione dell'architettura di un Galera Cluster.

Tuning

I principali parametri di tuning di Galera vengono impostati con una sola variabile di configurazione MySQL che contiene tutte le opzioni. Oltre a questi sono disponibili tutti i parametri di tuning MySQL / MariaDB.

Le opzioni di configurazione di Galera vengono impostati nella variabile WSREP_PROVIDER_OPTIONS. Le opzioni da cambiare debbono essere impostati nella stessa riga e quelle non definite mantengono il valore di default. Il formato delle opzioni e' gruppo.nome dove il gruppo corrisponde ad un modulo di Galera come: evs (Eviction Control), fc (Flow Control), ... Alcune opzioni sono dinamiche, altre richiedono il riavvio.
Ecco l'elenco delle opzioni e dei parametri Galera in ordine di importanza! Naturalmente secondo il mio fallace personale giudizio...

• gcache.size: e' la cache di Galera presente su ogni nodo per le scritture; se di dimensioni sufficiente possono essere evitati IST o SST in caso di una caduta di un nodo di breve durata. L'impostazione di default e' molto bassa ed un valore piu' generoso evita le pesanti sincronizzazioni.
• evs.*: i parametri di Eviction Control sono molteplici, la loro presenza e le impostazioni di default variano a seconda delle versioni di Galera. Sono i parametri che controllano quando un nodo deve essere considerato all'interno del cluster o quando deve essere escluso o auto-escluso. I valori di default sono adatti in una configurazione su un solo datacenter ma se i nodi vengono distribuiti in WAN spesso e' necessario aumentare i timeout per evitare disconnessioni dovute alla latenza della rete. La catena (con i valori di default tra parentesi) e': evs.inactive_check_period (PT1S) - evs.keepalive_period (PT1S) <= evs.suspect_timeout (PT5S) <= evs.inactive_timeout (PT15S) <= evs.install_timeout (PT15S) evs.consensus_timeout (PT30S deprecato).
  Un'impostazione utile quando si hanno latenze elevate e' la seguente:

  wsrep_provider_options = "evs.keepalive_period = PT3S;
                                evs.suspect_timeout = PT30S;
                                evs.inactive_timeout = PT1M;
                                evs.install_timeout = PT1M;"
  

• gmcast.segment: e' il parametro che indica a quale segmento di rete appartiene il nodo. Per default vale 0 e se non si modifica tutti i nodi appartengono allo stesso segmento di rete. Ma se si hanno piu' nodi distribuiti in datacenter diversi e' molto importante configurarlo: in questo modo Galera cerca di inviare i messaggi una sola volta per segmento e sa quale nodo scegliere per eseguire l'SST o l'IST.
• wsrep_slave_threads: attenzione questo e' parametro e non un'opzione (quindi richiede una riga a parte nel file di configurazione) ed indica il numero di thread che in parallelo eseguono i writeset. Se l'I/O e' significativo e' possibile impostarlo arrivando sino al doppio del numero di core.
• gcs.fc_limit: e' il parametro che determina il limite della coda oltre il quale si attiva il Flow Control (default 16). Quando lo slave supera questo limite la replica viene messa in pausa. Al contrario il parametro gcs.fc_factor e' quello che disattiva il Flow Control (default 0.5). Quando il Flow Control e' attivo entrano in gioco tre ulteriori parametri che regolano i limiti ed il tipo di rallentamento della replica: gcs.recv_q_hard_limit, gcs.max_throttle, gcs.recv_q_soft_limit.
  Il tuning di questi parametri non e' complesso ma richiede un'attenta misurazione per non ottenere risultati controproducenti. Nel caso di utilizzo come Single Master il valore della coda puo' essere aumento in modo significativo (eg. gcs.fc_limit=512).
• gcs.fc_master_slave: questo e' l'ultimo parametro che descrivo perche' e' un'ultima spiaggia: il default e' no ma se si imposta a yes Galera diventa un cluster Single Master. Va usato solo nel caso in cui i deadlock siano troppo elevati serializzando cosi' le transazioni su un nodo [NdA parametro deprecato in 4.10 e sostituito da gcs.fc_single_primary].

Ecco l'elenco dei parametri MySQL/MariaDB piu' utili per Galera in ordine di importanza! Naturalmente secondo il mio fallace personale giudizio...

• innodb_buffer_pool_size: imposta la dimensione della cache per i dati e gli indici InnoDB. Questo e' il principale parametro di tuning e va tenuto il piu' alto possibile per disporre dei dati in memoria anziche' accedere a disco. Nei casi fortunati si puo' ospitare l'intera base dati in memoria, altrimenti si imposta il parametro per utilizzare tra il 50% e l'80% della RAM disponibile facendo attenzione a non generare paginazione sul sistema ospite.
  Come verificare se l'impostazione e' sufficiente? Controllando il rapporto tra INNODB_BUFFER_POOL_READS e INNODB_BUFFER_POOL_READ_REQUESTS [NdA quante letture fisiche si fanno rispetto alle richieste]. Quando l'hit ratio si avvicina al 100% l'impostazione dell'innodb_buffer_pool_size e' adeguata.
• innodb_log_file_size: e' la dimensione dei redo logs. Il default e' basso per un utilizzo transazionale significativo. Poiche' vi sono due log file, con l'impostazione ad 1GB si hanno 2GB di occupazione disco ed una configurazione adatta alla maggioranza dei carichi. Se l'applicazione e' write-intensive si puo' arrivare a 8G.
  In questo caso il rapporto da verificare e' INNODB_LOG_WRITES / INNODB_LOG_WRITE_REQUESTS.
• innodb_flush_log_at_trx_commit: indica la modalita' di scrittura dei log. Con l'impostazione di default InnoDB (1) e' ACID compliant: ad ogni commit corrisponde una write (scrittura su log) ed una flush (scrittura fisica su disco).
  Non andrebbe mai cambiato pero'... con l'impostazione a 2 (scrive ad ogni commit ed effettua un flush al secondo, per default) o a 0 (effettua un flush al secondo) MySQL risulta significativamente piu' veloce con un carico OLTP. Quindi ci sono molte situazioni in cui si modifica il parametro accollandosi il rischio di perdere un secondo di transazioni in caso di crash del sistema (impostandolo a 2). Impostare a 0 generalmente non migliora significativamente le prestazioni rispetto ad impostare a 2 ed aumenta solo il rischio.
  Poiche' con Galera si ha una replica sincrona sul cluster l'impostazione innodb_flush_log_at_trx_commit=2 e' quella piu' utilizzata quando opera in modalita' distribuita.
• sync_binlog: numero di transazioni sincronizzate in gruppo su disco. Il default (1) e' il valore piu' sicuro ma ha un impatto prestazionale. Si puo' aumentare (eg. 256) o disabilitare (impostandolo a 0) anche se con il rischio di perdere transazioni sul binlog nel caso di caduta del Master.
  Come nel caso precedente con Galera distribuito si puo' rilassare il parametro impostandolo a 0 riducendo il rallentamento dell'I/O.
• innodb_flush_log_at_timeout: indica l'intervallo di tempo tra flush in secondi (default: 1). Con I/O particolarmente lento sullo Slave si puo' arrivare fino a 600 secondi, ovvero 10 minuti, superare tale valore non e' significativo.
• innodb_log_buffer_size: e' la dimensione del buffer del log. La dimensione di default va bene nella maggioranza dei casi anche perche' con Galera le transazioni debbono essere generalmente limitate.
• max_connections: numero massimo di connessioni. Da aumentare se si supera tale numero di sessioni al DB. Ma vanno anche verificate le applicazioni per assicurarsi che effettuino correttamente la disconnesione (eventualmente si puo' forzare la disconnesione abbassando wait_timeout e/o interactive_timeout) e che non utilizzino connection pool troppo ampi.
  Con un MySQL standalone il parametro non va sovvradimensionato perche' ha un impatto sul numero di file descriptor aperti. Con Galera Cluster bisogna tenere conto che in caso di caduta di altri nodi il carico viene ridistribuito sui nodi rimanenti e quindi vi deve essere un ampio margine di crescita rispetto al carico normale.
• innodb_autoinc_lock_mode: e' un parametro obbligatorio e va sempre impostato innodb_autoinc_lock_mode=2. Le altre impostazioni, normalmente utilizzabili con un MySQL standalone, possono portare a deadlock o bloccare il cluster con Galera.
• sort_buffer_size: dimensione del buffer di sort. L'allocazione e' per sessione e quindi il parametro va aumentato con attenzione (meglio non superare i 2M). Quando il valore della variabile SORT_MERGE_PASSES cresce in modo significativo il parametro andrebbe aumentato. Il parametro si puo' modificare anche per la singola sessione che effettua query pesanti con ORDER BY e/o GROUP BY.
• performance_schema: attiva la raccolta delle statistiche di performance. Teoricamente rallenta le prestazioni ma in modo minimale e, su un ambiente reale di produzione, e' sempre importante poter raccogliere ed analizzare le indicazioni fornite dalle statistiche MySQL. Da attivare sempre [NdA con MySQL e Percona e' gia' presente di default mentre su MariaDB va attivato].
• Versioni MySQL/MariaDB/Percona, Galera: gli aggiornamenti ed i fix presenti nelle nuove versioni possono avere un impatto significativo sulle performances: sempre meglio utilizzare (dopo averla provata) l'ultima versione di produzione disponibile.
  Gli upgrade generalmente vengono eseguiti in modalita' rolling con Galera, quindi senza interrompere il servizio. Va pero' posta attenzione ad alcuni passaggi (eg. cambio di protocollo tra Galera 3 e Galera 4).

Parametri da non utilizzare Oltre ai parametri utili e' importante ricordare che ci sono parametri spesso utilizzati per il tuning di MySQL/MariaDB ma che non vanno utilizzati con Galera. La Query Cache MySQL non va utilizzata: non e' supportata con Galera.
L'unico Engine supportato da Galera e' InnoDB [NdA InnoDB ed i suoi compatibili come Percona XtraDB], su un cluster non vanno utilizzate tabelle con Engine differenti e naturalmente tutti i parametri di configurazione e tuning relativi (eg. key_buffer_size) non sono da utilizzare.

Attivita' amministrative

L'amministrazione di una base dati con Galera Cluster e' simile a quella di un normale database MySQL. Vi sono pero' alcune importanti differenze da sottolineare.

Oltre ai normali comandi di controllo dello stato di MySQL (eg. SHOW PROCESSLIST; SHOW GLOBAL STATUS; SHOW VARIABLES; ...) e' possibile controllare la configurazione di Galera con:
  SHOW VARIABLES LIKE 'wsrep%' \G
Nello stato di MySQL vi sono tutti i dettagli per Galera pero' sono una cinquantina di valori... i piu' importanti a mio avviso sono:
  show status where variable_name in
   ('wsrep_cluster_size', 'wsrep_cluster_status', 'wsrep_flow_control_paused',
   'wsrep_ready', 'wsrep_connected', 'wsrep_local_state_comment');

Le modifiche alla struttura della base dati vanno eseguite con molta attenzione su un Galera Cluster.
La modalita' di default per l'esecuzione delle DDL e' quella piu' sicura perche' non genera inconsistenze sulle basi dati; viene chiamata TOI (Total Order Isolation). Il problema e' che con il TOI le DDL bloccano le attivita' di commit su tutto il cluster che deve attendere che l'operazione termini. Questo puo' essere un problema per le DDL di una certa durata come le ALTER TABLE. Se si e' certi che vengono eseguite DDL retro-compatibili e' possibile utilizzare la modalita' RSU (Rolling Schema Upgrade) lanciandole su un nodo alla volta come nell'esempio che segue:

Galera Cluster EE ha introdotto una terza modalita' chiamata NBO (Non Blocking Operations), simile alla TOI ma con un minore impatto.
[NdE Galera Cluster Enterprise Edition e' disponibile dal 2022-05 e consiste in Enhanced Galera Server (NBO, supporto XA, TDE per la GCache), Galera Manager e Galera Load Balancer]

Quando vi sono transazioni di lunga durata che non possono realizzate altrimenti o quando le transazioni modificano le stesse righe (e quindi andrebbero in conflitto) e' possibile "spezzare" la transazione in parti inviate sul cluster e certificate singolarmente. Questa modalita', disponibile da Galera 4, e' chiamata Streaming Replication e va usata con attenzione perche' introduce un carico superiore su tutti i nodi del cluster. Tipicamente la streaming replication si utilizza solo per una specifica transazione o per parti di essa:

Riassumendo molto... l'amministrazione di una base dati con Galera Cluster e' analoga a quella di un normale DB con MySQL ma richiede una particolare attenzione nel monitoraggio, nella gestione delle DDL e nel trattare transazioni di lunga durata.

Varie ed eventuali

Manca qualcosa? No: abbiamo gia' descritto tutti i parametri utili!

In generale le configurazioni di default presenti sono gia' ottimali...
innodb_flush_method: non cambiatelo! la scelta del metodo di flush puo' essere importante per le prestazioni in alcuni casi ma per valutare se cambiare rispetto al default fsync (eg. impostandolo a O_DIRECT che evita il double buffering) e' opportuno un benchmark specifico sui dischi ed una conoscenza esatta del comportamento dello storage e del sistema operativo, alcune impostazioni sono corrette su versioni e file system specifici (eg. O_DIRECT_NO_FSYNC 8.0.25+)... insomma io non lo cambio o ne sapete piu' di me o non cambiatelo; innodb_buffer_pool_instances: indica il numero di regioni in cui il buffer pool e' diviso per ridurre le contese dei latch. E' un'ottimizzazione significativa... ma il valore di default e' gia' adatto alla maggioranza dei casi; innodb_doublewrite: non cambiatelo! a meno che non stiate eseguendo un benchmark non e' il caso di rischiare la corruzione del DB; ALTER INSTANCE DISABLE INNODB REDO_LOG: non eseguitelo! e' utile solo per un caricamento iniziale, se si ha un errore il DB va creato da zero; performance_schema: e' vero che ha un peso per le prestazioni, ma non e' consigliabile impostarlo ad OFF su un ambiente di produzione a meno che non siate certi della buona qualita' dell'SQL di tutte le applicazioni ospitate [NdA non sono tutti di questa opinione: su MariaDB per default e' disabilitato e lo stesso avviene con MySQL su Amazon RDS; al contrario Percona, benchmark alla mano, lo ritiene poco invasivo]; spesso sono presenti attese su lock che attendono fino a innodb_lock_wait_timeout, anche se e' possibile monitorarle con INNODB_ROW_LOCK_TIME, INNODB_ROW_LOCK_WAITS, INNODB_ROW_LOCK_CURRENT_WAITS, ... tipicamente non si puo' fare molto dal punto di vista del tuning ma solo agire sull'applicazione; max_allowed_packet: e' un parametro che spesso si modifica, ma non e' un parametro prestazionale; ...
Infine vm.swappiness: da impostare sempre a 1 su un DB server, ma e' un parametro del sistema operativo!

Manca qualcosa? Sicuramente si!

Sarebbe un grave errore pensare di poter riassumere tutto in una paginetta. I parametri MySQL, MariaDB e Galera sono centinaia e sono tutti importanti per sfruttare le funzionalita' ed ottenere le massime performance con un Galera Cluster.

MariaDB Cluster e Percona XtraDB Cluster sono distribuzioni dei noti fork MySQL con il plugin di Galera Cluster; quanto descritto in questa pagina vale anche per tali software.

Titolo: Galera Cluster Tuning
Livello: Esperto (4/5)
Data: 14 Febbraio 2020
Versione: 1.0.2 - 31 Ottobre 2022
Autore: mail [AT] meo.bogliolo.name