La replica in streaming è una nuova funzionalità introdotta con la versione 4.0 di Galera Cluster. Galera utilizza la replica in modo sincrono nell'intero cluster, ma prima di questa versione i set di scrittura superiori a 2 GB non erano supportati. Streaming Replication ti consente ora di replicare set di scritture di grandi dimensioni, il che è perfetto per gli inserimenti in blocco o il caricamento di dati nel database.
In un blog precedente abbiamo scritto sulla gestione di grandi transazioni con Streaming Replication e MariaDB 10.4, ma al momento della stesura di questo blog Codership non aveva ancora rilasciato la loro versione del nuovo Galera Cluster. Percona ha, tuttavia, rilasciato la sua versione binaria sperimentale di Percona XtraDB Cluster 8.0 che mette in evidenza le seguenti caratteristiche...
-
Replica in streaming che supporta transazioni di grandi dimensioni
-
Le funzioni di sincronizzazione consentono il coordinamento delle azioni (wsrep_last_seen_gtid, wsrep_last_write_gtid, wsrep_sync_wait_upto_gtid)
-
Registrazione degli errori più granulare e migliorata. wsrep_debug è ora una variabile multivalore che aiuta a controllare la registrazione e i messaggi di registrazione sono stati notevolmente migliorati.
-
Alcuni errori DML e DDL su un nodo di replica possono essere ignorati o eliminati. Usa la variabile wsrep_ignore_apply_errors per configurare.
-
Più tabelle di sistema aiutano a scoprire di più sullo stato dello stato del cluster.
-
L'infrastruttura wsrep di Galera 4 è più robusta di quella di Galera 3. Presenta un'esecuzione più rapida del codice con una migliore gestione dello stato, una migliore prevedibilità e gestione degli errori.
Cosa c'è di nuovo con Galera Cluster 4.0?
La nuova funzione di replica in streaming
Con Streaming Replication, le transazioni vengono replicate gradualmente in piccoli frammenti durante l'elaborazione delle transazioni (ovvero prima del commit effettivo, replichiamo un certo numero di frammenti di piccole dimensioni). I frammenti replicati vengono quindi applicati nei thread slave, preservando lo stato della transazione in tutti i nodi del cluster. I frammenti mantengono i blocchi in tutti i nodi e non possono essere in conflitto in seguito.
Galera SystemTables
Gli amministratori del database ei client con accesso al database MySQL possono leggere queste tabelle, ma non possono modificarle poiché il database stesso apporterà le modifiche necessarie. Se il tuo server non ha queste tabelle, è possibile che il tuo server stia utilizzando una versione precedente di Galera Cluster.
#> show tables from mysql like 'wsrep%';
+--------------------------+
| Tables_in_mysql (wsrep%) |
+--------------------------+
| wsrep_cluster |
| wsrep_cluster_members |
| wsrep_streaming_log |
+--------------------------+
3 rows in set (0.12 sec)Nuove funzioni di sincronizzazione
Questa versione introduce una serie di funzioni SQL da utilizzare nelle operazioni di sincronizzazione di wsrep. Puoi usarli per ottenere l'ID transazione globale che si basa sull'ultima transazione scritta o sull'ultima transazione vista. Puoi anche impostare il nodo in modo che attenda la replica e l'applicazione di un GTID specifico, prima di avviare la transazione successiva.
Selezione intelligente dei donatori
Alcune funzionalità sottovalutate che sono state presenti da Galera 3.x includono la selezione intelligente dei donatori e il ripristino da crash del cluster. Questi erano originariamente previsti per Galera 4, ma sono diventati versioni precedenti in gran parte a causa delle esigenze dei clienti. Quando si tratta di selezione del nodo donatore in Galera 3, il donatore State Snapshot Transfer (SST) è stato selezionato a caso. Tuttavia, con Galera 4, ottieni una scelta molto più intelligente quando si tratta di scegliere un donatore, poiché favorirà un donatore che può fornire un trasferimento di stato incrementale (IST) o scegliere un donatore nello stesso segmento. In qualità di amministratore del database, puoi forzarlo impostando wsrep_sst_donor.
Perché utilizzare MySQL Galera Cluster Streaming Replication?
Transazioni di lunga durata
I problemi e le limitazioni di Galera ruotavano sempre attorno al modo in cui gestiva le transazioni di lunga durata e spesso causavano il rallentamento dell'intero cluster a causa della replica di set di scritture di grandi dimensioni. Il controllo del flusso spesso diventa elevato, causando un rallentamento delle scritture o addirittura l'interruzione del processo per riportare il cluster al suo stato normale. Questo è un problema piuttosto comune con le versioni precedenti di Galera Cluster.
Codership consiglia di utilizzare la replica in streaming per le transazioni di lunga durata per mitigare queste situazioni. Una volta che il nodo replica e certifica un frammento, non è più possibile che altre transazioni lo interrompano.
Grandi transazioni
Questo è molto utile quando si caricano i dati nel report o nell'analisi. La creazione di inserimenti in blocco, eliminazioni, aggiornamenti o l'utilizzo dell'istruzione LOAD DATA per caricare grandi quantità di dati può rientrare in questa categoria. Anche se dipende da come gestisci i tuoi dati per il recupero o l'archiviazione. È necessario tenere conto del fatto che Streaming Replication ha i suoi limiti, tali che le chiavi di certificazione vengono generate dai blocchi dei record.
Senza Streaming Replication, l'aggiornamento di un numero elevato di record comporterebbe un conflitto e l'intera transazione dovrebbe essere annullata. Gli slave che replicano anche transazioni di grandi dimensioni sono soggetti al controllo del flusso quando raggiunge la soglia e inizia a rallentare l'intero cluster per elaborare eventuali scritture poiché tendono a rilassarsi ricevendo le transazioni in entrata dalla replica sincrona. Galera rilasserà la replica fino a quando il set di scrittura non sarà gestibile in quanto consente di continuare la replica di nuovo. Dai un'occhiata a questo blog esterno di Percona per saperne di più sul controllo del flusso all'interno di Galera.
Con Streaming Replication, il nodo inizia a replicare i dati con ogni frammento di transazione, invece di attendere il commit. Ciò significa che non è possibile interrompere le transazioni in conflitto in esecuzione all'interno degli altri nodi poiché ciò afferma semplicemente che il cluster ha certificato il set di scrittura per questo particolare frammento. È gratuito applicare e impegnare altre transazioni simultanee senza bloccare ed elaborare transazioni di grandi dimensioni con un impatto minimo sul cluster.
Hot Record/Hot Spot
Gli hot record o le righe sono quelle righe nella tabella che vengono costantemente aggiornate. Questi dati potrebbero essere i più visitati e ottenere il traffico dell'intero database (ad es. feed di notizie, un contatore come il numero di visite o registri). Con Streaming Replication, puoi forzare gli aggiornamenti critici all'intero cluster.
Come notato dal Team Galera di Codership
“L'esecuzione di una transazione in questo modo blocca efficacemente l'hot record su tutti i nodi, impedendo ad altre transazioni di modificare la riga. Aumenta anche le possibilità che la transazione venga confermata con successo e che il cliente a sua volta riceva il risultato desiderato."
Questo ha delle limitazioni in quanto potrebbe non essere persistente e coerente che avrai commit di successo. Senza utilizzare la replica in streaming, avrai alte possibilità o rollback e ciò potrebbe aggiungere un sovraccarico all'utente finale quando si verifica questo problema dal punto di vista dell'applicazione.
Aspetti da considerare quando si utilizza la replica in streaming
- Le chiavi di certificazione sono generate dai blocchi dei record, quindi non coprono i blocchi dei gap o i blocchi delle chiavi successive. Se la transazione subisce un gap lock, è possibile che una transazione, eseguita su un altro nodo, applichi un write set che incontra il gap log e interrompa la transazione di streaming.
- Quando si abilita Streaming Replication, i registri dei set di scrittura vengono scritti nella tabella wsrep_streaming_log trovata nel database di sistema mysql per preservare la persistenza in caso di arresto anomalo, quindi questa tabella viene utilizzata per il ripristino. In caso di registrazione eccessiva e sovraccarico di replica elevato, la replica in streaming causerà una velocità di trasmissione delle transazioni ridotta. Questo potrebbe essere un collo di bottiglia delle prestazioni quando viene raggiunto un carico di picco elevato. Pertanto, ti consigliamo di abilitare la replica in streaming solo a livello di sessione e solo per le transazioni che non verrebbero eseguite correttamente senza di essa.
- Il miglior caso d'uso è utilizzare la replica in streaming per tagliare transazioni di grandi dimensioni
- Imposta la dimensione del frammento su ~10.000 righe
- Le variabili di frammento sono variabili di sessione e possono essere impostate dinamicamente
- L'applicazione intelligente può attivare/disattivare la replica dello streaming in base alle necessità
Conclusione
Grazie per la lettura, nella seconda parte discuteremo come abilitare Galera Cluster Streaming Replication e quali potrebbero essere i risultati per la tua configurazione.
