HA per MySQL e MariaDB - Confronto della replica master-master con il cluster Galera

La replica di Galera è relativamente nuova rispetto alla replica di MySQL, che è supportata in modo nativo da MySQL v3.23. Sebbene la replica MySQL sia progettata per la replica unidirezionale master-slave, può essere configurata come configurazione master-master attiva con replica bidirezionale. Sebbene sia facile da configurare e alcuni casi d'uso potrebbero trarre vantaggio da questo "hack", ci sono una serie di avvertimenti. D'altra parte, il cluster Galera è un diverso tipo di tecnologia da apprendere e gestire. Ne vale la pena?

In questo post del blog confronteremo la replica master-master con il cluster Galera.

Concetti di replica

Prima di entrare nel confronto, spieghiamo i concetti di base alla base di questi due meccanismi di replica.

In genere, qualsiasi modifica al database MySQL genera un evento in formato binario. Questo evento viene trasportato agli altri nodi a seconda del metodo di replica scelto:replica MySQL (nativa) o replica Galera (corretta con l'API wsrep).

Replica MySQL

I diagrammi seguenti illustrano il flusso di dati di una transazione riuscita da un nodo all'altro quando si utilizza la replica MySQL:

L'evento binario viene scritto nel log binario del master. Gli slave tramite slave_IO_thread estrarrà gli eventi binari dal registro binario del master e li replicherà nel suo registro di inoltro. Il thread_slave_SQL applicherà quindi l'evento dal registro di inoltro in modo asincrono. A causa della natura asincrona della replica, non è garantito che il server slave disponga dei dati quando il master esegue la modifica.

Idealmente, la replica MySQL avrà lo slave da configurare come server di sola lettura impostando read_only=ON o super_read_only=ON. Questa è una precauzione per proteggere lo slave da scritture accidentali che possono causare incoerenze o errori dei dati durante il failover del master (ad es. transazioni errate). Tuttavia, in una configurazione di replica attiva-attiva master-master, la sola lettura deve essere disabilitata sull'altro master per consentire l'elaborazione simultanea delle scritture. Il master primario deve essere configurato per la replica dal master secondario utilizzando l'istruzione CHANGE MASTER per abilitare la replica circolare.

Replica Galleria

I seguenti diagrammi illustrano il flusso di replica dei dati di una transazione riuscita da un nodo all'altro per Galera Cluster:

L'evento viene incapsulato in un writeset e trasmesso dal nodo di origine agli altri nodi del cluster usando la replica Galera. Il writeset subisce la certificazione su ogni nodo Galera e, se viene superato, i thread dell'applicatore applicheranno il writeset in modo asincrono. Ciò significa che il server slave alla fine diventerà coerente, dopo l'accordo di tutti i nodi partecipanti nell'ordinamento totale globale. È logicamente sincrono, ma la scrittura e il commit effettivi nel tablespace avvengono indipendentemente, e quindi in modo asincrono su ciascun nodo con la garanzia che la modifica si propaghi su tutti i nodi.

Evitare la collisione della chiave primaria

Per implementare la replica MySQL nella configurazione master-master, è necessario regolare il valore di incremento automatico per evitare la collisione della chiave primaria per INSERT tra due o più master replicanti. Ciò consente al valore della chiave primaria sui master di interlacciare e impedire che lo stesso numero di incremento automatico venga utilizzato due volte su uno dei nodi. Questo comportamento deve essere configurato manualmente, a seconda del numero di master nell'impostazione della replica. Il valore di auto_increment_increment è uguale al numero di master replicanti e auto_increment_offset deve essere unico tra loro. Ad esempio, le seguenti righe dovrebbero esistere all'interno del corrispondente my.cnf:

Maestro1:

log-slave-updates
auto_increment_increment=2
auto_increment_offset=1

Maestro2:

log-slave-updates
auto_increment_increment=2
auto_increment_offset=2

Allo stesso modo, Galera Cluster utilizza questo stesso trucco per evitare collisioni di chiavi primarie controllando il valore di incremento automatico e compensando automaticamente con wsrep_auto_increment_control variabile. Se impostato su 1 (impostazione predefinita), regolerà automaticamente auto_increment_increment e auto_increment_offset variabili in base alla dimensione del cluster e quando la dimensione del cluster cambia. Ciò evita conflitti di replica dovuti a auto_increment. In un ambiente master-slave, questa variabile può essere impostata su OFF.

La conseguenza di questa configurazione è che il valore di incremento automatico non sarà in ordine sequenziale, come mostrato nella tabella seguente di un cluster Galera a tre nodi:

Se un'applicazione esegue operazioni di inserimento sui seguenti nodi nel seguente ordine:

• Nodo1, Nodo3, Nodo2, Nodo3, Nodo3, Nodo1, Nodo3 ..

Quindi il valore della chiave primaria che verrà archiviato nella tabella sarà:

• 1, 6, 8, 9, 12, 13, 15 ..

Detto semplicemente, quando si utilizza la replica master-master (replica MySQL o Galera), l'applicazione deve essere in grado di tollerare valori di incremento automatico non sequenziali nel suo set di dati.

Per gli utenti ClusterControl, tieni presente che supporta l'implementazione della replica master-master MySQL con un limite di due master per cluster di replica, solo per la configurazione attiva-passiva. Pertanto, ClusterControl non configura deliberatamente i master con auto_increment_increment e auto_increment_offset variabili.

Coerenza dei dati

Galera Cluster viene fornito con il suo meccanismo di controllo del flusso, in cui ogni nodo nel cluster deve tenere il passo durante la replica, altrimenti tutti gli altri nodi dovranno rallentare per consentire al nodo più lento di recuperare. Questo sostanzialmente riduce al minimo la probabilità di slave lag, anche se potrebbe ancora accadere ma non così significativo come nella replica di MySQL. Per impostazione predefinita, Galera consente ai nodi di essere in ritardo di almeno 16 transazioni nell'applicazione tramite la variabile gcs.fc_limit . Se vuoi eseguire letture critiche (una SELECT che deve restituire informazioni più aggiornate), probabilmente vorrai utilizzare la variabile di sessione, wsrep_sync_wait .

Galera Cluster d'altra parte viene fornito con una protezione contro l'incoerenza dei dati in base alla quale un nodo verrà rimosso dal cluster se non riesce ad applicare alcun writeset per qualsiasi motivo. Ad esempio, quando un nodo Galera non riesce ad applicare il writeset a causa di un errore interno del motore di archiviazione sottostante (MySQL/MariaDB), il nodo si estrarrà dal cluster con il seguente errore:

150305 16:13:14 [ERROR] WSREP: Failed to apply trx 1 4 times
150305 16:13:14 [ERROR] WSREP: Node consistency compromized, aborting..

Per correggere la coerenza dei dati, il nodo incriminato deve essere risincronizzato prima che sia consentito l'accesso al cluster. Questo può essere fatto manualmente o cancellando la directory dei dati per attivare il trasferimento dello stato dell'istantanea (sincronizzazione completa da un donatore).

La replica master-master di MySQL non applica la protezione della coerenza dei dati e uno slave può divergere, ad esempio replicare un sottoinsieme di dati o rimanere indietro, il che rende lo slave incoerente con il master. È progettato per replicare i dati in un unico flusso, dal master fino agli slave. I controlli di coerenza dei dati devono essere eseguiti manualmente o tramite strumenti esterni come Percona Toolkit pt-table-checksum o mysql-replication-check.

Risoluzione dei conflitti

In genere, la replica master-master (o multi-master o bidirezionale) consente a più membri del cluster di elaborare le scritture. Con la replica MySQL, in caso di conflitto di replica, il thread SQL dello slave interrompe semplicemente l'applicazione della query successiva fino a quando il conflitto non viene risolto, saltando manualmente l'evento di replica, correggendo le righe incriminate o risincronizzando lo slave. Detto semplicemente, non esiste un supporto automatico per la risoluzione dei conflitti per la replica di MySQL.

Galera Cluster fornisce un'alternativa migliore riprovando la transazione incriminata durante la replica. Utilizzando wsrep_retry_autocommit variabile, è possibile indicare a Galera di riprovare automaticamente una transazione non riuscita a causa di conflitti a livello di cluster, prima di restituire un errore al client. Se impostato su 0, non verrà effettuato alcun tentativo, mentre un valore pari o superiore a 1 (impostazione predefinita) specifica il numero di tentativi. Questo può essere utile per aiutare le applicazioni che utilizzano il commit automatico per evitare deadlock.

Consenso del nodo e failover

Galera utilizza Group Communication System (GCS) per verificare il consenso e la disponibilità dei nodi tra i membri del cluster. Se un nodo non è integro, verrà automaticamente rimosso dal cluster dopo gmcast.peer_timeout valore, il valore predefinito è 3 secondi. Un nodo Galera sano nello stato "Sincronizzato" è considerato un nodo affidabile per servire letture e scritture, mentre altri no. Questo design semplifica notevolmente le procedure di controllo dello stato dai livelli superiori (bilanciamento del carico o applicazione).

Nella replica MySQL, un master non si preoccupa dei suoi slave, mentre uno slave ha consenso solo con il suo unico master tramite lo slave_IO_thread processo durante la replica degli eventi binari dal registro binario del master. Se un master si interrompe, la replica verrà interrotta e verrà effettuato un tentativo di ristabilire il collegamento ogni slave_net_timeout (predefinito a 60 secondi). Dal punto di vista dell'applicazione o del bilanciamento del carico, le procedure di controllo dello stato per lo slave di replica devono almeno prevedere il controllo del seguente stato:

• Secondi_dietro_il_padrone
• Slave_IO_Running
• Slave_SQL_Running
• Variabile di sola lettura
• Variabile super_read_only (MySQL 5.7.8 e versioni successive)

In termini di failover, in genere, la replica master-master e i nodi Galera sono uguali. Hanno lo stesso set di dati (sebbene sia possibile replicare un sottoinsieme di dati nella replica MySQL, ma non è comune per master-master) e condividono lo stesso ruolo dei master, in grado di gestire letture e scritture contemporaneamente. Pertanto, in realtà non vi è alcun failover dal punto di vista del database a causa di questo equilibrio. Solo dal lato dell'applicazione che richiederebbe il failover per ignorare i nodi non operativi. Tieni presente che poiché la replica di MySQL è asincrona, è possibile che non tutte le modifiche apportate al master si siano propagate all'altro master.

Provisioning del nodo

Il processo di sincronizzazione di un nodo con il cluster prima dell'avvio della replica è noto come provisioning. Nella replica MySQL, il provisioning di un nuovo nodo è un processo manuale. È necessario eseguire un backup del master e ripristinarlo sul nuovo nodo prima di impostare il collegamento di replica. Per un nodo di replica esistente, se i log binari del master sono stati ruotati (in base a expire_logs_days , il valore predefinito su 0 significa nessuna rimozione automatica), potrebbe essere necessario eseguire nuovamente il provisioning del nodo utilizzando questa procedura. Ci sono anche strumenti esterni come Percona Toolkit pt-table-sync e ClusterControl per aiutarti in questo. ClusterControl supporta la risincronizzazione di uno slave con soli due clic. Hai opzioni per risincronizzare eseguendo un backup dal master attivo o da un backup esistente.

In Galera, ci sono due modi per farlo:trasferimento di stato incrementale (IST) o trasferimento di snapshot di stato (SST). Il processo IST è il metodo preferito in cui solo le transazioni mancanti vengono trasferite dalla cache di un donatore. Il processo SST è simile all'esecuzione di un backup completo dal donatore, di solito è piuttosto dispendioso in termini di risorse. Galera determinerà automaticamente quale processo di sincronizzazione attivare in base allo stato del joiner. Nella maggior parte dei casi, se un nodo non riesce a unirsi a un cluster, è sufficiente cancellare la directory dati MySQL del nodo problematico e avviare il servizio MySQL. Il processo di provisioning di Galera è molto più semplice, risulta molto utile quando si ridimensiona il cluster o si reintroduce un nodo problematico nel cluster.

Senza accoppiamento vs strettamente accoppiato

La replica di MySQL funziona molto bene anche con connessioni più lente e con connessioni non continue. Può essere utilizzato anche su hardware, ambiente e sistemi operativi diversi. La maggior parte dei motori di archiviazione lo supporta, inclusi MyISAM, Aria, MEMORY e ARCHIVE. Questa configurazione ad accoppiamento libero consente alla replica master-master di MySQL di funzionare bene in un ambiente misto con meno restrizioni.

I nodi Galera sono strettamente accoppiati, in cui le prestazioni di replica sono veloci quanto il nodo più lento. Galera utilizza un meccanismo di controllo del flusso per controllare il flusso di replica tra i membri ed eliminare qualsiasi ritardo dello slave. La replica può essere tutta veloce o tutta lenta su ogni nodo e viene regolata automaticamente da Galera. Pertanto, si consiglia di utilizzare specifiche hardware uniformi per tutti i nodi Galera, in particolare per quanto riguarda CPU, RAM, sottosistema del disco, scheda di interfaccia di rete e latenza di rete tra i nodi nel cluster.

Conclusioni

In sintesi, Galera Cluster è superiore rispetto alla replica master-master di MySQL grazie al supporto della replica sincrona con una forte coerenza, oltre a funzionalità più avanzate come il controllo automatico dell'appartenenza, il provisioning automatico dei nodi e gli slave multi-thread. In definitiva, questo dipende da come l'applicazione interagisce con il server di database. Alcune applicazioni legacy create per un server di database autonomo potrebbero non funzionare correttamente su una configurazione in cluster.

Per semplificare i nostri punti sopra, i seguenti motivi giustificano quando utilizzare la replica master-master di MySQL:

• Cose che non sono supportate da Galera:
  • Replica per tabelle non InnoDB/XtraDB come MyISAM, Aria, MEMORY o ARCHIVE.
  • Transazioni XA.
  • Replica basata su istruzioni tra master (ad es. quando la larghezza di banda è molto costosa).
  • Fare affidamento su un blocco esplicito come l'istruzione LOCK TABLES.
  • Il registro delle query generali e il registro delle query lente devono essere indirizzati a una tabella, anziché a un file.
• Configurazione liberamente accoppiata in cui le specifiche hardware, la versione del software e la velocità di connessione sono significativamente diverse su ogni master.
• Quando si dispone già di una catena di replica MySQL e si desidera aggiungere un altro master attivo/di backup per la ridondanza per accelerare i tempi di failover e ripristino nel caso in cui uno dei master non sia disponibile.
• Se la tua applicazione non può essere modificata per aggirare le limitazioni di Galera Cluster e avere un sistema di bilanciamento del carico compatibile con MySQL come ProxySQL o MaxScale non è un'opzione.

Motivi per scegliere il cluster Galera rispetto alla replica master-master di MySQL:

• Possibilità di scrivere in sicurezza su più master.
• Coerenza dei dati gestita (e garantita) automaticamente tra i database.
• Nuovi nodi di database facilmente introdotti e sincronizzati.
• Errori o incongruenze rilevati automaticamente.
• In generale, funzionalità di disponibilità elevata più avanzate e robuste.