MySQL Galera Cluster 4.0 è il nuovo arrivato nel blocco di database con nuove funzionalità molto interessanti. Attualmente è disponibile solo come parte di MariaDB 10.4 ma in futuro funzionerà anche con MySQL 5.6, 5.7 e 8.0. In questo post del blog vorremmo esaminare alcune delle nuove funzionalità che sono arrivate insieme a Galera Cluster 4.0.
Replica in streaming del cluster Galera
La nuova funzionalità più importante di questa versione è la replica in streaming. Finora il processo di certificazione per il Cluster Galera ha funzionato in modo tale che intere transazioni dovevano essere certificate dopo essere state completate.
Questo processo non era l'ideale in diversi scenari...
- Hotspot nelle tabelle, righe che vengono aggiornate molto frequentemente su più nodi - centinaia di transazioni veloci in esecuzione su più nodi, la modifica dello stesso insieme di righe provoca frequenti deadlock e rollback delle transazioni
- Transazioni di lunga durata - se una transazione richiede molto tempo per essere completata, questo aumenta notevolmente le possibilità che qualche altra transazione, nel frattempo, su un altro nodo, possa modificare alcune delle righe che sono state aggiornate anche dalla transazione lunga. Ciò ha comportato una situazione di stallo durante la certificazione e il rollback di una delle transazioni.
- Grandi transazioni - se una transazione modifica un numero significativo di righe, è probabile che un'altra transazione, contemporaneamente, su un nodo diverso, modifichi una delle righe già modificate dalla transazione grande. Ciò si traduce in un deadlock durante la certificazione e una delle transazioni deve essere annullata. Inoltre, le transazioni di grandi dimensioni richiederanno più tempo per essere elaborate, inviate a tutti i nodi del cluster e certificate. Questa non è una situazione ideale in quanto aggiunge ritardo ai commit e rallenta l'intero cluster.
Fortunatamente, la replica in streaming può risolvere questi problemi. La differenza principale è che la certificazione avviene in blocchi in cui non è necessario attendere il completamento dell'intera transazione. Di conseguenza, anche se una transazione è grande o lunga, la maggior parte (o tutte, a seconda delle impostazioni di cui parleremo tra poco) delle righe è bloccata su tutti i nodi, impedendo ad altre query di modificarli.
Opzioni di replica streaming del cluster MySQL Galera
Ci sono due opzioni di configurazione per la replica in streaming:
wsrep_trx_fragment_size
Questo dice quanto dovrebbe essere grande un frammento (per impostazione predefinita è impostato su 0, il che significa che la replica in streaming è disabilitata)
wsrep_trx_fragment_unit
Questo dice che cos'è veramente il frammento. Per impostazione predefinita sono byte, ma possono anche essere "istruzioni" o "righe".
Queste variabili possono (e dovrebbero) essere impostate a livello di sessione, consentendo all'utente di decidere quale particolare query deve essere replicata utilizzando la replica in streaming. L'impostazione dell'unità su "istruzioni" e la dimensione su 1 consentono, ad esempio, di utilizzare la replica in streaming solo per una singola query che, ad esempio, aggiorna un hotspot.
Puoi configurare Galera 4.0 per certificare ogni riga che hai modificato e prendere i lock su tutti i nodi mentre lo fai. Ciò rende la replica in streaming ottima per risolvere problemi con frequenti deadlock che, prima di Galera 4.0, era possibile risolvere solo reindirizzando tutte le scritture su un singolo nodo.
Tabelle WSREP
Galera 4.0 introduce diverse tabelle, che aiuteranno a monitorare lo stato del cluster:
- wsrep_cluster
- wsrep_cluster_members
- wsrep_streaming_log
Tutti si trovano nello schema 'mysql'. wsrep_cluster fornirà informazioni dettagliate sullo stato del cluster. wsrep_cluster_members ti fornirà informazioni sui nodi che fanno parte del cluster. wsrep_streaming_log aiuta a tenere traccia dello stato della replica in streaming.
Funzionalità imminenti del cluster Galera
Codership, l'azienda dietro la Galera, non è ancora finita. Siamo stati in grado di ottenere un'anteprima della roadmap dal CEO, Seppo Jaakola, che è stata data al Percona Live all'inizio di quest'anno. Apparentemente, vedremo funzionalità come il supporto per le transazioni XA e la crittografia gcache. Questa è davvero una buona notizia.
Il supporto per le transazioni XA sarà possibile grazie alla replica in streaming. In breve, le transazioni XA sono le transazioni distribuite che possono essere eseguite su più nodi. Utilizzano il commit in due fasi, che richiede prima l'acquisizione di tutti i blocchi necessari per eseguire la transazione su tutti i nodi e quindi, una volta terminato, il commit delle modifiche. Nelle versioni precedenti Galera non disponeva di mezzi per bloccare le risorse sui nodi remoti, con la replica in streaming questo è cambiato.
Gcache è un file che memorizza i set di scrittura. Il suo contenuto viene inviato ai nodi joiner che richiedono un trasferimento di dati. Se tutti i dati sono archiviati nella gcache, joiner riceverà solo le transazioni mancanti nel processo chiamato Incremental State Transfer (IST). Se gcache non contiene tutti i dati richiesti, sarà richiesto State Snapshot Transfer (SST) e l'intero set di dati dovrà essere trasferito al nodo di unione.
Gcache contiene informazioni sulle modifiche recenti, quindi è fantastico vedere i suoi contenuti crittografati per una maggiore sicurezza. Con l'introduzione di migliori standard di sicurezza attraverso un numero sempre maggiore di normative, è fondamentale che il software diventi migliore nel raggiungere la conformità.
Conclusione
Non vediamo l'ora di vedere come funzionerà Galera Cluster 4.0 sui database rispetto a MariaDB. Essere in grado di distribuire MySQL 5.7 o 8.0 con Galera Cluster sarà davvero fantastico. Dopotutto, Galera è una delle soluzioni di replica sincrona più testate disponibili sul mercato.
