In uno dei blog precedenti, abbiamo trattato le nuove funzionalità che stanno uscendo in MariaDB 10.4. Abbiamo menzionato che inclusa in questa versione sarà una nuova versione di Galera Cluster. In questo post del blog esamineremo le funzionalità di Galera Cluster 26.4.0 (o Galera 4), daremo una rapida occhiata ed esploreremo come influiranno sulla tua configurazione quando lavori con MariaDB Galera Cluster.
Replica in streaming
Galera Cluster non è affatto un sostituto drop-in di MySQL standalone. Il modo in cui funziona la certificazione writeset ha introdotto diverse limitazioni e casi limite che possono limitare seriamente la capacità di migrare in Galera Cluster. Le tre limitazioni più comuni sono...
- Problemi con transazioni lunghe
- Problemi con transazioni di grandi dimensioni
- Problemi con gli hotspot nelle tabelle
La cosa bella da vedere è che Galera 4 introduce Streaming Replication, che può aiutare a ridurre queste limitazioni. Esaminiamo lo stato attuale un po' più in dettaglio.
Transazioni di lunga durata
In questo caso si tratta di tempistiche, decisamente problematiche in Galera. La cosa principale da capire è che Galera replica le transazioni come writeset. Tali set di scritture sono certificati sui membri del cluster, assicurando che tutti i nodi possano applicare un determinato set di scritture. Il problema è che i blocchi vengono creati sul nodo locale, non vengono replicati nel cluster quindi se la transazione impiega diversi minuti per essere completata e se stai scrivendo su più nodi Galera, con il tempo è sempre più probabile che su uno dei nodi rimanenti alcune transazioni modificheranno alcune delle righe aggiornate nella transazione di lunga durata. Ciò causerà il fallimento della certificazione e la transazione di lunga durata dovrà essere annullata. In breve, dato che invii scritture a più di un nodo nel cluster, più lunga è la transazione, più è probabile che la certificazione fallisca a causa di qualche conflitto.
Punti caldi
Con ciò intendiamo le righe, che vengono aggiornate frequentemente. In genere è una sorta di contatore che viene aggiornato più e più volte. Il colpevole del problema è lo stesso delle transazioni lunghe:le righe sono bloccate solo localmente. Anche in questo caso, se invii scritture a più di un nodo, è probabile che lo stesso contatore venga modificato contemporaneamente su più di un nodo, causando conflitti e facendo fallire la certificazione.
Per entrambi questi problemi esiste una soluzione:puoi inviare le tue scritture a un solo nodo invece di distribuirle nell'intero cluster. È possibile utilizzare i proxy per questo:ClusterControl distribuisce HAProxy e ProxySQL, entrambi possono essere configurati in modo che le scritture vengano inviate a un solo nodo. Se non puoi inviare scritture a un solo nodo, devi accettare che di tanto in tanto vedrai conflitti di certificazione e rollback. In generale, l'applicazione deve essere in grado di gestire i rollback dal database:non c'è modo di aggirarlo, ma è ancora più importante quando l'applicazione funziona con Galera Cluster.
Tuttavia, inviare il traffico a un nodo non è sufficiente per gestire il terzo problema.
Transazioni di grandi dimensioni
Ciò che è importante tenere a mente è che il writeset viene inviato per la certificazione solo al termine della transazione. Quindi, il writeset viene inviato a tutti i nodi e ha luogo il processo di certificazione. Ciò induce limiti alle dimensioni della singola transazione poiché Galera, durante la preparazione del writeset, lo archivia nel buffer in memoria. Transazioni troppo grandi ridurranno le prestazioni del cluster. Sono state quindi introdotte due variabili:wsrep_max_ws_rows, che limita il numero di righe per transazione (sebbene possa essere impostato a 0 - illimitato) e, cosa più importante:wsrep_max_ws_size, che può essere impostato fino a 2 GB. Quindi, la transazione più grande che puoi eseguire con Galera Cluster ha una dimensione fino a 2 GB. Inoltre, devi tenere presente che anche la certificazione e l'applicazione della transazione di grandi dimensioni richiedono tempo, creando "lag" - lettura dopo scrittura, quel nodo colpito diverso da quello in cui hai inizialmente commesso la transazione, molto probabilmente risulterà in dati errati poiché il la transazione è ancora in corso.
Galera 4 viene fornito con Streaming Replication, che può essere utilizzato per mitigare tutti questi problemi. La differenza principale sarà che il writeset ora può essere suddiviso in parti:non sarà più necessario attendere il completamento dell'intera transazione prima che i dati vengano replicati. Questo potrebbe farti chiedere:come appare la certificazione in questo caso? In breve, la certificazione è al volo:ogni frammento è certificato e tutte le righe coinvolte sono bloccate su tutti i nodi del cluster. Questo è un serio cambiamento nel modo in cui funziona Galera:fino ad ora i blocchi venivano creati localmente, con i blocchi di replica in streaming verranno creati su tutti i nodi. Questo aiuta nei casi discussi sopra:bloccare le righe quando entrano frammenti di transazione, aiuta a ridurre la probabilità che la transazione debba essere annullata. Le transazioni in conflitto eseguite localmente non saranno in grado di ottenere i blocchi di cui hanno bisogno e dovranno attendere il completamento della transazione di replica e il rilascio dei blocchi di riga.
Nel caso di hotspot, con la replica in streaming è possibile ottenere i lock su tutti i nodi durante l'aggiornamento della riga. Altre query che desiderano aggiornare la stessa riga dovranno attendere il rilascio del blocco prima di eseguire le modifiche.
Le transazioni di grandi dimensioni trarranno vantaggio dalla replica in streaming perché non sarà più necessario attendere il completamento dell'intera transazione né saranno limitate dalle dimensioni della transazione:le transazioni di grandi dimensioni verranno suddivise in frammenti. Aiuta anche a utilizzare meglio la rete:invece di inviare 2 GB di dati contemporaneamente, gli stessi 2 GB di dati possono essere suddivisi in frammenti e inviati per un periodo di tempo più lungo.
Sono disponibili due opzioni di configurazione per la replica in streaming:wsrep_trx_fragment_size, che indica quanto deve essere grande un frammento (per impostazione predefinita è impostato su 0, il che significa che la replica in streaming è disabilitata) e wsrep_trx_fragment_unit, che indica quale sia effettivamente il frammento. Per impostazione predefinita sono byte, ma possono anche essere "istruzioni" o "righe". Tali 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.
Naturalmente, ci sono degli svantaggi nell'esecuzione della replica in streaming, principalmente a causa del fatto che i blocchi ora vengono presi su tutti i nodi del cluster. Se hai visto il rollback di transazioni di grandi dimensioni per anni, ora tale transazione dovrà eseguire il rollback su tutti i nodi. Ovviamente, la best practice consiste nel ridurre il più possibile le dimensioni di una transazione per evitare che i rollback richiedano ore per essere completati. Un altro svantaggio è che, per motivi di ripristino in caso di arresto anomalo, i set di scrittura creati da ciascun frammento vengono archiviati nella tabella wsrep_schema.SR su tutti i nodi, che, in un certo senso, implementa il buffer di doppia scrittura, aumentando il carico sul cluster. Pertanto dovresti decidere con attenzione quale transazione deve essere replicata utilizzando la replica in streaming e, fintanto che è fattibile, dovresti comunque attenerti alle migliori pratiche di avere transazioni piccole e brevi o dividere la transazione di grandi dimensioni in batch più piccoli.
Blocchi backup
Infine, gli utenti di MariaDB potranno beneficiare dei blocchi di backup per SST. L'idea alla base dell'SST eseguito utilizzando (per MariaDB) mariabackup è che l'intero set di dati deve essere trasferito, al volo, con i registri di ripristino raccolti in background. Quindi, è necessario acquisire un blocco globale, assicurando che non avvenga alcuna scrittura, la posizione finale del registro di ripristino deve essere raccolta e archiviata. Storicamente, per MariaDB, la parte di bloccaggio veniva eseguita utilizzando TAVOLI FLUSH CON READ LOCK che faceva il suo lavoro ma sotto carico pesante era piuttosto difficile da acquisire. È anche piuttosto pesante:non solo le transazioni devono attendere il rilascio del blocco, ma anche i dati devono essere scaricati su disco. Ora, con MariaDB 10.4, sarà possibile utilizzare BACKUP LOCK meno invadente, che non richiederà lo svuotamento dei dati, solo i commit verranno bloccati per la durata del blocco. Ciò dovrebbe significare operazioni SST meno invasive, il che è sicuramente fantastico da ascoltare. Tutti coloro che hanno dovuto eseguire il loro cluster Galera in modalità di emergenza, su un nodo, incrociando le dita sul fatto che l'SST non influirà sulle operazioni del cluster, dovrebbero essere più che felici di conoscere questo miglioramento.
Lettura causale dall'applicazione
Galera 4 ha introdotto tre nuove funzioni che hanno lo scopo di aiutare ad aggiungere il supporto per le letture causali nelle applicazioni:WSREP_LAST_WRITTEN_GTID(), che restituisce il GTID dell'ultima scrittura effettuata dal client, WSREP_LAST_SEEN_GTID(), che restituisce il GTID dell'ultima transazione di scrittura osservata dal client e WSREP_SYNC_WAIT_UPTO_GTID(), che bloccherà il client fino a quando il GTID passato alla funzione non verrà eseguito sul nodo. Certo, puoi imporre letture causali in Galera anche adesso, ma utilizzando queste funzioni sarà possibile implementare la lettura sicura dopo la scrittura in quelle parti dell'applicazione dove è necessario, senza dover apportare modifiche alla configurazione di Galera.
Aggiornamento a MariaDB Galera 10.4
Se desideri provare Galera 4, è disponibile nell'ultima versione candidata per MariaDB 10.4. Secondo la documentazione di MariaDB, in questo momento non c'è modo di eseguire un aggiornamento live da 10.3 Galera a 10.4. Devi arrestare l'intero cluster 10.3, aggiornarlo a 10.4 e quindi riavviarlo. Questo è un blocco serio e speriamo che questa limitazione venga rimossa in una delle prossime versioni. È della massima importanza avere l'opzione per un aggiornamento live e per questo sia MariaDB 10.3 che MariaDB 10.4 dovranno coesistere nello stesso Cluster Galera. Un'altra opzione, che potrebbe anche essere adatta, è impostare la replica asincrona tra il vecchio e il nuovo Galera Cluster.
Ci auguriamo davvero che questa breve recensione delle funzionalità di MariaDB 10.4 Galera Cluster vi sia piaciuta, non vediamo l'ora di vedere la replica in streaming in ambienti di produzione live reali. Ci auguriamo inoltre che tali modifiche contribuiranno ad aumentare ulteriormente l'adozione di Galera. Dopotutto, la replica in streaming risolve molti problemi che possono impedire alle persone di migrare a Galera.
