Nei post precedenti del blog, abbiamo trattato argomenti per il monitoraggio del cluster Galera, sia esso MySQL o MariaDB. Sebbene le versioni della tecnologia non differiscano molto, MariaDB Cluster ha alcune importanti modifiche rispetto alla versione 10.4.2. In questa versione supporta Galera Cluster 4 e ha alcune fantastiche nuove funzionalità che esamineremo in questo post del blog.
Per i principianti che non hanno ancora familiarità con MariaDB Cluster, è un cluster multimaster virtualmente sincrono per MariaDB. È disponibile solo su Linux e supporta solo i motori di archiviazione XtraDB/InnoDB (sebbene sia disponibile un supporto sperimentale per MyISAM - vedere la variabile di sistema wsrep_replicate_myisam).
Il software è una tecnologia in bundle basata su MariaDB Server, la patch MySQL-wsrep per MySQL Server e MariaDB Server sviluppata da Codership (supporta un sistema operativo simile a Unix) e la libreria del provider wsrep Galera.
Potresti confrontare questo prodotto con MySQL Group Replication o con MySQL InnoDB Cluster, che mira a fornire un'elevata disponibilità. (Sebbene differiscano in modo diverso sui principi e sugli approcci per fornire HA.)
Ora che abbiamo trattato le nozioni di base, in questo blog forniremo suggerimenti che riteniamo utili per il monitoraggio del cluster MariaDB.
Gli elementi essenziali del cluster MariaDB
Quando inizi a utilizzare MariaDB Cluster devi identificare esattamente qual è il tuo scopo e perché hai scelto MariaDB Cluster in primo luogo. Per prima cosa devi digerire quali sono le funzionalità e i loro vantaggi quando si utilizza MariaDB Cluster. Il motivo per identificarli è perché sono essenzialmente ciò che deve essere monitorato e verificato per poter determinare le prestazioni, le normali condizioni di salute e se sta funzionando secondo i tuoi piani.
Essenzialmente, è identificato come nessun ritardo di slave, nessuna transazione persa, scalabilità di lettura e latenze del client più piccole. Quindi possono sorgere domande del tipo, come fa a non ritardare lo slave o perdere transazioni? In che modo la lettura è scalabile o con latenze minori sul lato client? Queste aree sono una delle aree chiave che devi guardare e monitorare soprattutto per un uso intensivo della produzione.
Sebbene lo stesso MariaDB Cluster possa essere personalizzato di conseguenza. L'applicazione di modifiche al comportamento predefinito come pc.weight o pc.ignore_quorum, o anche l'utilizzo del multicast con UDP per un numero elevato di nodi, può influire sul modo in cui monitori la natura del cluster MariaDB. Ma d'altra parte, le variabili di stato più essenziali sono di solito il tuo lato positivo qui, sapendo che lo stato e il flusso del tuo cluster stanno andando bene o il suo degrado mostra in anticipo un possibile problema che porta a un guasto catastrofico.
Monistra sempre l'attività del tuo server (rete, disco, carico, memoria e CPU)
Il monitoraggio dell'attività del server può anche essere un compito complesso se si dispone di uno stack molto complicato che è intrecciato nell'architettura del database. Tuttavia, per un cluster MariaDB, è sempre meglio che i tuoi nodi siano sempre configurati nel modo più dedicato ma semplice possibile. Sebbene ciò non ti impedisca di utilizzare tutte le risorse di riserva, di seguito sono riportate le aree chiave comuni che devi esaminare.
Rete
Galera Cluster 4 presenta la replica in streaming come una delle funzionalità chiave e delle modifiche rispetto alla versione precedente. Poiché la replica in streaming risolve gli inconvenienti delle versioni precedenti, ma consente di gestire più di 2 GB di set di scritture da Galera Cluster 4. Ciò consente la frammentazione delle transazioni di grandi dimensioni ed è altamente consigliato abilitarla solo a livello di sessione. Ciò significa che il monitoraggio dell'attività di rete è molto importante e cruciale per la normale attività del cluster MariaDB. Questo ti aiuterà a identificare quale nodo ha avuto il traffico di rete più o più alto in base al periodo di tempo.
Quindi, in che modo ciò ti aiuterà a migliorare dove sono stati identificati i nodi con il traffico di rete più elevato? Bene, questo ti offre margini di miglioramento con la topologia del tuo database o il livello architettonico del tuo cluster di database. L'uso di bilanciatori di carico o un proxy di database consente di configurare in modo proattivo il traffico del database, soprattutto quando si determina quali scritture specifiche devono andare a un nodo specifico. Diciamo, dei 3 nodi, uno di loro è più capace di gestire query grandi e grandi a causa delle differenze con le specifiche hardware. Ciò ti consente di gestire più spese in conto capitale e migliorare la pianificazione della capacità al variare delle richieste in un determinato periodo di tempo.
Disco
Poiché l'attività di rete è importante anche per le prestazioni del disco, specialmente durante il tempo di svuotamento. È anche meglio determinare le prestazioni del tempo impegnato e del recupero quando viene raggiunto un carico di picco elevato. Ci sono volte in cui fai scorta del tuo host di database non solo dedicandoti a un'attività del cluster Galera, ma anche combinando altri strumenti come docker, proxy SQL come ProxySQL o MaxScale. Ciò ti dà il controllo con server a basso carico e ti consente di utilizzare le risorse di riserva disponibili che possono essere utilizzate per altri scopi vantaggiosi, in particolare per lo stack dell'architettura del database. Una volta che sei in grado di determinare quale nodo durante il monitoraggio ha il carico più basso ma è ancora in grado di gestire l'utilizzo dell'IO del disco, puoi selezionare il nodo specifico mentre guardi il tempo che passa. Ancora una volta, questo ti dà ancora una migliore gestione con la pianificazione della tua capacità.
CPU, memoria e attività di caricamento
Consentitemi di descrivere brevemente queste tre aree da considerare durante il monitoraggio. In questa sezione, è sempre meglio avere una migliore osservabilità delle seguenti aree contemporaneamente. È più rapido e facile da capire, in particolare escludendo un collo di bottiglia delle prestazioni o identificando bug che causano lo stallo dei nodi e che possono influire anche sugli altri nodi e sulla possibilità di interrompere il cluster.
In che modo CPU, memoria e attività di carico durante il monitoraggio aiutano il cluster MariaDB? Bene, come ho menzionato sopra, queste sono una delle poche cose ancora un fattore importante per i controlli di routine quotidiani. Ora, questo ti aiuta anche a identificare se si tratta di occorrenze periodiche o casuali. Se periodico, potrebbe essere correlato a backup in esecuzione in uno dei tuoi nodi Galera, oppure è una query massiccia che richiede l'ottimizzazione. Ad esempio, query errate senza indici appropriati o utilizzo non bilanciato del recupero dei dati come il confronto di stringhe per una stringa così grande. Ciò può essere innegabilmente inapplicabile per i database di tipo OLTP come MariaDB Cluster, soprattutto se è davvero la natura e i requisiti della tua applicazione. Utilizzare meglio altri strumenti analitici come MariaDB Columnstore o altri strumenti di elaborazione analitica di terze parti (Apache Spark, Kafka o MongoDB, ecc.) per il recupero di dati di stringhe di grandi dimensioni e/o la corrispondenza di stringhe.
Quindi, con tutte queste aree chiave monitorate, la domanda è:come devono essere monitorate? Deve essere monitorato almeno al minuto. Con un monitoraggio raffinato, ad es. le metriche collettive al secondo possono essere ad alta intensità di risorse e molto avido in termini di risorse. Sebbene mezzo minuto di collettività sia accettabile soprattutto se i tuoi dati e l'RPO (obiettivo del punto di ripristino) sono molto bassi, quindi hai bisogno di metriche dei dati più granulari e in tempo reale. È molto importante poter controllare l'intera immagine del cluster di database. A parte questo, è anche meglio e importante che ogni volta che si monitorano le metriche, si disponga dello strumento giusto per attirare la propria attenzione quando le cose sono in pericolo o anche solo avvisi. L'utilizzo dello strumento appropriato come ClusterControl consente di gestire queste aree chiave da monitorare. Sto usando qui una versione gratuita o una community edition di ClusterControl e mi aiuta a monitorare i miei nodi senza problemi dall'installazione fino al monitoraggio dei nodi con pochi clic. Ad esempio, guarda gli screenshot seguenti:
La visualizzazione è una panoramica più precisa e rapida di ciò che sta accadendo attualmente. Può essere utilizzato anche un grafico più granulare,
o con un modello di dati più potente e ricco che supporta anche il linguaggio di query può fornirti un'analisi delle prestazioni del tuo cluster MariaDB sulla base di dati storici confrontando le sue prestazioni in modo tempestivo. Ad esempio,
Questo ti fornisce solo metriche più visibili. Quindi vedi quanto sia davvero importante avere lo strumento giusto per monitorare il tuo cluster MariaDB.
Garantire il monitoraggio collettivo delle variabili statistiche del cluster MariaDB
Di tanto in tanto, non può essere inevitabile che le versioni di MariaDB Cluster producano nuove statistiche per monitorare o migliorare la natura del monitoraggio del database fornendo più variabili di stato e perfezionando i valori da considerare. Come ho menzionato sopra, sto usando ClusterControl per monitorare i miei nodi in questo blog di esempio. Tuttavia, ciò non significa che sia lo strumento migliore in circolazione. Voglio dire, PMM di Percona è molto ricco quando si tratta di monitoraggio collettivo per ogni variabile statistica che ogni volta che MariaDB Cluster ha nuove variabili statistiche da offrire, puoi sfruttarlo e anche cambiarlo poiché PMM è uno strumento open source. È un grande vantaggio avere anche tutta la visibilità del tuo cluster MariaDB poiché ogni aspetto conta soprattutto in un database basato sulla produzione che soddisfa centinaia di migliaia di richieste al minuto.
Ma entriamo più nello specifico del problema qui. Quali sono queste variabili statistiche da esaminare? Ci sono molte cose su cui contare per un cluster MariaDB, ma concentrandoci ancora sulle funzionalità e sui vantaggi che riteniamo tu possa utilizzare il cluster MariaDB per ciò che ha da offrire, quindi ci concentreremo su questo.
Galera Cluster - Controllo del flusso
Il controllo di flusso del cluster MariaDB fornisce una panoramica delle prestazioni dell'integrità della replica su tutto il cluster. Il processo di replica in Galera Cluster utilizza un meccanismo di feedback, il che significa che segnala tutti i nodi all'interno di quel cluster e segnala se il nodo deve sospendere o riprendere la replica in base alle sue esigenze. Ciò impedisce anche a qualsiasi nodo di ritardare troppo mentre gli altri stanno applicando le transazioni in entrata. Questo è il modo in cui il controllo del flusso svolge la sua funzione all'interno di Galera. Ora, questo deve essere visto e non trascurato durante il monitoraggio del cluster MariaDB. Questo, come menzionato in uno dei vantaggi dell'utilizzo di MariaDB Cluster è che si evita di avere lo slave lag. Anche se è troppo ingenuo per capire il controllo del flusso e lo slave lag, ma con il controllo del flusso avrà un impatto sulle prestazioni del tuo cluster Galera quando c'è molta coda e commit o lo svuotamento delle pagine sul disco diventa molto basso per tali problemi del disco o è solo che la query in esecuzione è una query errata. Se sei un principiante di come funziona Galera, potresti essere interessato a leggere questo post esterno su cos'è il controllo del flusso in Galera.
Byte inviati/ricevuti
I byte inviati o ricevuti sono correlati all'attività di rete e persino una delle aree chiave da guardare fianco a fianco con il controllo del flusso. Ciò ti consente di determinare quale nodo è il più colpito o attribuire ai problemi di prestazioni che soffrono all'interno del tuo cluster Galera. È molto importante in quanto puoi verificare se può esserci un degrado in termini di hardware come il tuo dispositivo di rete o il dispositivo di archiviazione sottostante per il quale la sincronizzazione delle pagine sporche può richiedere troppo tempo.
Carica cluster
Beh, questa è più l'attività del database di quante modifiche o recuperi di dati sono stati interrogati o eseguiti finora dall'uptime del server. Ti aiuta a escludere che tipo di query influiscono maggiormente sulle prestazioni del cluster di database. Ciò consente di fornire margini di miglioramento, in particolare per quanto riguarda il bilanciamento del carico delle richieste del database. L'uso di ProxySQL ti aiuta qui con un approccio più raffinato e granulare per l'instradamento delle query. Sebbene MaxScale offra anche questa funzionalità, ProxySQL ha una maggiore granularità sebbene abbia anche un impatto sulle prestazioni o sui costi. L'impatto arriva quando hai un solo ProxySQL come proxy SQL per elaborare il routing delle query e può avere difficoltà quando è in corso un traffico elevato. Avendo un costo, se aggiungi più nodi ProxySQL per bilanciare più traffico rispetto a KeepAlived sottostante. Anche se questa è una combinazione perfetta, ma può essere eseguita a basso costo fino a quando non è necessario. Tuttavia, come sarai in grado di determinare se necessario, giusto? Questa è la domanda che resta qui, quindi un occhio attento al monitoraggio di queste aree chiave è molto importante, non solo per l'osservabilità, ma anche per il miglioramento delle prestazioni del tuo cluster di database con il passare del tempo.
In quanto tali, ci sono tonnellate di variabili da considerare in un cluster MariaDB. La cosa più importante da tenere in considerazione qui è lo strumento che stai utilizzando per monitorare il tuo cluster di database. Come accennato in precedenza, preferisco utilizzare la licenza della versione gratuita di ClusterControl (Community Edition) qui in questo blog poiché mi offre più modi con flessibilità per guardare in un Cluster Galera. Vedi l'esempio qui sotto,
Ho contrassegnato o cerchiato in rosso quelle schede che mi consentono di supervisionare visivamente la salute del mio Cluster MariaDB. Diciamo che se la tua applicazione è avida di usare la replica in streaming di tanto in tanto e invia un numero elevato di frammenti (trasferimento di rete di grandi dimensioni) per l'interattività del cluster, è meglio determinare quanto bene i tuoi nodi possono gestire lo stress. Soprattutto durante lo stress test prima di apportare modifiche specifiche all'applicazione, è sempre meglio provare a testare per determinare la gestione della capacità del prodotto dell'applicazione e determinare se i nodi del database e la progettazione attuali possono gestire il carico dei requisiti dell'applicazione.
Anche su un'edizione comunitaria di ClusterControl, sono in grado di raccogliere risultati granulari e più raffinati dello stato di salute del mio Cluster MariaDB. Vedi sotto,
Questo è il modo in cui ti avvicinerai al monitoraggio del tuo cluster MariaDB. Una visualizzazione perfetta è sempre più facile e veloce da gestire. Quando le cose vanno male, non puoi permetterti di perdere la tua produttività e anche i tempi di inattività possono avere un impatto sulla tua attività. Sebbene l'utilizzo gratuito non offra il lusso e il comfort durante la gestione di database ad alto traffico, avere allarmi, notifiche e gestione del database in un'area è un add-on semplice che ClusterControl può fare.
Conclusione
Il cluster MariaDB non è così semplice da monitorare rispetto alle tradizionali configurazioni asincrone MySQL/MariaDB master-slave. Funziona in modo diverso e devi disporre degli strumenti giusti per determinare cosa sta succedendo e cosa sta succedendo nel tuo cluster di database. Prepara sempre la pianificazione della capacità in anticipo prima di eseguire il cluster MariaDB senza un adeguato monitoraggio in anticipo. È sempre meglio che il carico e l'attività del database siano noti prima di un evento catastrofico.
