HA voor MySQL en MariaDB - Master-Master-replicatie vergelijken met Galera-cluster

Galera-replicatie is relatief nieuw in vergelijking met MySQL-replicatie, die standaard wordt ondersteund sinds MySQL v3.23. Hoewel MySQL-replicatie is ontworpen voor master-slave unidirectionele replicatie, kan het worden geconfigureerd als een actieve master-masterconfiguratie met bidirectionele replicatie. Hoewel het eenvoudig in te stellen is en sommige gebruiksscenario's baat kunnen hebben bij deze "hack", zijn er een aantal kanttekeningen. Aan de andere kant is Galera-cluster een ander type technologie om te leren en te beheren. Is het het waard?

In deze blogpost gaan we master-master-replicatie vergelijken met Galera-cluster.

Replicatieconcepten

Voordat we ingaan op de vergelijking, laten we eerst de basisconcepten achter deze twee replicatiemechanismen uitleggen.

Over het algemeen genereert elke wijziging aan de MySQL-database een gebeurtenis in binair formaat. Deze gebeurtenis wordt naar de andere knooppunten getransporteerd, afhankelijk van de gekozen replicatiemethode - MySQL-replicatie (native) of Galera-replicatie (gepatcht met wsrep API).

MySQL-replicatie

De volgende diagrammen illustreren de gegevensstroom van een succesvolle transactie van het ene knooppunt naar het andere bij gebruik van MySQL-replicatie:

De binaire gebeurtenis wordt in het binaire logboek van de master geschreven. De slave(s) via slave_IO_thread haalt de binaire gebeurtenissen uit het binaire logboek van de master en repliceert ze naar het relaislogboek. De slave_SQL_thread zal dan de gebeurtenis uit het relaislogboek asynchroon toepassen. Vanwege de asynchrone aard van replicatie is het niet gegarandeerd dat de slave-server over de gegevens beschikt wanneer de master de wijziging uitvoert.

Idealiter zal bij MySQL-replicatie de slave worden geconfigureerd als een alleen-lezen server door read_only=ON of super_read_only=ON in te stellen. Dit is een voorzorgsmaatregel om de slave te beschermen tegen onbedoeld schrijven, wat kan leiden tot inconsistentie van gegevens of storingen tijdens masterfailover (bijv. foutieve transacties). In een master-master active-active replicatie-setup moet alleen-lezen worden uitgeschakeld op de andere master, zodat schrijfbewerkingen tegelijkertijd kunnen worden verwerkt. De primaire master moet worden geconfigureerd om te repliceren vanaf de secundaire master met behulp van de instructie CHANGE MASTER om circulaire replicatie in te schakelen.

Galera-replicatie

De volgende diagrammen illustreren de gegevensreplicatiestroom van een succesvolle transactie van het ene knooppunt naar het andere voor Galera Cluster:

De gebeurtenis wordt ingekapseld in een schrijfset en uitgezonden van het oorspronkelijke knooppunt naar de andere knooppunten in het cluster met behulp van Galera-replicatie. De schrijfset ondergaat certificering op elke Galera-node en als deze slaagt, passen de toepassingsthreads de schrijfset asynchroon toe. Dit betekent dat de slave-server uiteindelijk consistent zal worden, na overeenstemming van alle deelnemende nodes in de globale totale volgorde. Het is logisch synchroon, maar het daadwerkelijke schrijven en vastleggen in de tablespace gebeurt onafhankelijk en dus asynchroon op elk knooppunt met een garantie dat de wijziging zich op alle knooppunten verspreidt.

Aanvaring met primaire sleutel vermijden

Om MySQL-replicatie in master-masterconfiguratie te implementeren, moet men de auto-incrementwaarde aanpassen om een ​​botsing van de primaire sleutel voor INSERT tussen twee of meer replicerende masters te voorkomen. Hierdoor kan de primaire sleutelwaarde op masters elkaar verweven en wordt voorkomen dat hetzelfde automatische incrementnummer twee keer wordt gebruikt op een van de knooppunten. Dit gedrag moet handmatig worden geconfigureerd, afhankelijk van het aantal masters in de replicatie-instellingen. De waarde van auto_increment_increment is gelijk aan het aantal replicerende masters en de auto_increment_offset moet uniek zijn tussen hen. De volgende regels zouden bijvoorbeeld binnen de corresponderende my.cnf moeten staan:

Meester1:

log-slave-updates
auto_increment_increment=2
auto_increment_offset=1

Meester2:

log-slave-updates
auto_increment_increment=2
auto_increment_offset=2

Evenzo gebruikt Galera Cluster dezelfde truc om botsingen met primaire sleutels te voorkomen door de auto-incrementwaarde te regelen en automatisch te compenseren met wsrep_auto_increment_control variabel. Indien ingesteld op 1 (de standaard), wordt de auto_increment_increment automatisch aangepast en auto_increment_offset variabelen afhankelijk van de grootte van het cluster en wanneer de clustergrootte verandert. Dit voorkomt replicatieconflicten als gevolg van auto_increment. In een master-slave-omgeving kan deze variabele op OFF worden gezet.

Het gevolg van deze configuratie is dat de automatische incrementwaarde niet in de juiste volgorde staat, zoals weergegeven in de volgende tabel van een Galera-cluster met drie knooppunten:

Als een toepassing invoegbewerkingen uitvoert op de volgende knooppunten in de volgende volgorde:

• Node1, Node3, Node2, Node3, Node3, Node1, Node3 ..

Dan is de primaire sleutelwaarde die in de tabel wordt opgeslagen:

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

Simpel gezegd, wanneer u master-master-replicatie (MySQL-replicatie of Galera) gebruikt, moet uw toepassing niet-sequentiële auto-incrementwaarden in de dataset kunnen tolereren.

Voor ClusterControl-gebruikers:houd er rekening mee dat het de implementatie van MySQL-master-master-replicatie ondersteunt met een limiet van twee masters per replicatiecluster, alleen voor actief-passieve installatie. Daarom configureert ClusterControl de masters niet bewust met auto_increment_increment en auto_increment_offset variabelen.

Consistentie van gegevens

Galera Cluster wordt geleverd met zijn flow-control-mechanisme, waarbij elk knooppunt in het cluster gelijke tred moet houden bij het repliceren, anders moeten alle andere knooppunten vertragen om het langzaamste knooppunt de kans te geven om in te halen. Dit minimaliseert in feite de kans op slaafvertraging, hoewel het nog steeds kan gebeuren, maar niet zo belangrijk als bij MySQL-replicatie. Standaard staat Galera toe dat nodes ten minste 16 transacties achterlopen bij het aanvragen via variabele gcs.fc_limit . Als u kritische leesbewerkingen wilt doen (een SELECT die de meest actuele informatie moet retourneren), wilt u waarschijnlijk de sessievariabele wsrep_sync_wait gebruiken .

Galera Cluster daarentegen wordt geleverd met een beveiliging tegen inconsistentie van gegevens, waarbij een knooppunt uit het cluster wordt verwijderd als het om welke reden dan ook geen schrijfset toepast. Als een Galera-knooppunt bijvoorbeeld de schrijfset niet toepast vanwege een interne fout van de onderliggende opslagengine (MySQL/MariaDB), trekt het knooppunt zichzelf uit het cluster met de volgende fout:

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

Om de gegevensconsistentie te herstellen, moet het overtredende knooppunt opnieuw worden gesynchroniseerd voordat het lid mag worden van het cluster. Dit kan handmatig worden gedaan of door de gegevensmap te wissen om de overdracht van de snapshotstatus te activeren (volledige synchronisatie van een donor).

MySQL-master-master-replicatie dwingt geen bescherming van gegevensconsistentie af en een slaaf mag afwijken, bijvoorbeeld een subset van gegevens repliceren of achterblijven, waardoor de slaaf inconsistent is met de meester. Het is ontworpen om gegevens in één stroom te repliceren - van master tot slave. Controles op gegevensconsistentie moeten handmatig worden uitgevoerd of via externe tools zoals Percona Toolkit pt-table-checksum of mysql-replication-check.

Conflictoplossing

Over het algemeen staat master-master (of multi-master of bidirectionele) replicatie meer dan één lid in het cluster toe om schrijfbewerkingen te verwerken. Met MySQL-replicatie, in het geval van een replicatieconflict, stopt de SQL-thread van de slave gewoon met het toepassen van de volgende query totdat het conflict is opgelost, ofwel door de replicatiegebeurtenis handmatig over te slaan, de aanstootgevende rijen te repareren of de slave opnieuw te synchroniseren. Simpel gezegd, er is geen automatische ondersteuning voor conflictoplossing voor MySQL-replicatie.

Galera Cluster biedt een beter alternatief door de overtredende transactie opnieuw te proberen tijdens replicatie. Door wsrep_retry_autocommit . te gebruiken variabele, kan men Galera instrueren om een ​​mislukte transactie automatisch opnieuw te proberen als gevolg van clusterbrede conflicten, voordat een fout naar de klant wordt teruggestuurd. Indien ingesteld op 0, worden er geen nieuwe pogingen ondernomen, terwijl een waarde van 1 (de standaardinstelling) of meer het aantal pogingen specificeert. Dit kan handig zijn om applicaties te helpen die autocommit gebruiken om impasses te voorkomen.

Knooppuntconsensus en failover

Galera gebruikt Group Communication System (GCS) om de consensus van de node en de beschikbaarheid tussen clusterleden te controleren. Als een node niet in orde is, wordt deze automatisch verwijderd uit het cluster na gmcast.peer_timeout waarde, standaard ingesteld op 3 seconden. Een gezond Galera-knooppunt in de status "Gesynchroniseerd" wordt beschouwd als een betrouwbaar knooppunt voor lezen en schrijven, terwijl andere dat niet zijn. Dit ontwerp vereenvoudigt de statuscontroleprocedures van de hogere niveaus (load balancer of applicatie) aanzienlijk.

Bij MySQL-replicatie geeft een master niets om zijn slave(s), terwijl een slave alleen consensus heeft met zijn enige master via de slave_IO_thread proces bij het repliceren van de binaire gebeurtenissen uit het binaire logboek van de master. Als een master uitvalt, zal dit de replicatie verbreken en zal er elke slave_net_timeout een poging worden gedaan om de link opnieuw tot stand te brengen (standaard 60 seconden). Vanuit het perspectief van de applicatie of de load balancer moeten de statuscontroleprocedures voor replicatieslave ten minste de volgende status controleren:

• Seconds_Behind_Master
• Slave_IO_Running
• Slave_SQL_Running
• read_only variabele
• super_read_only variabele (MySQL 5.7.8 en hoger)

In termen van failover zijn master-master-replicatie en Galera-knooppunten over het algemeen gelijk. Ze bevatten dezelfde dataset (hoewel je een subset van data kunt repliceren in MySQL-replicatie, maar dat is ongebruikelijk voor master-master) en delen dezelfde rol als masters, die lees- en schrijfbewerkingen tegelijkertijd kunnen verwerken. Daarom is er eigenlijk geen failover vanuit het oogpunt van de database vanwege dit evenwicht. Alleen vanaf de toepassingskant waarvoor een failover nodig is om de niet-operationele knooppunten over te slaan. Houd er rekening mee dat, omdat MySQL-replicatie asynchroon is, het mogelijk is dat niet alle wijzigingen die op de master zijn aangebracht, zijn doorgevoerd naar de andere master.

Node-inrichting

Het proces waarbij een knoop punt gesynchroniseerd wordt met het cluster voordat de replicatie begint, staat bekend als inrichting. In MySQL-replicatie is het inrichten van een nieuw knooppunt een handmatig proces. Men moet een back-up van de master maken en deze terugzetten naar het nieuwe knooppunt voordat de replicatielink wordt ingesteld. Voor een bestaand replicatieknooppunt, als de binaire logboeken van de master zijn geroteerd (gebaseerd op expire_logs_days , standaard op 0 betekent geen automatische verwijdering), moet u mogelijk het knooppunt opnieuw inrichten met behulp van deze procedure. Er zijn ook externe tools zoals Percona Toolkit pt-table-sync en ClusterControl om u hierbij te helpen. ClusterControl ondersteunt het opnieuw synchroniseren van een slave met slechts twee klikken. Je hebt opties om opnieuw te synchroniseren door een back-up te maken van de actieve master of een bestaande back-up.

In Galera zijn er twee manieren om dit te doen:incrementele statusoverdracht (IST) of status snapshotoverdracht (SST). Het IST-proces is de voorkeursmethode waarbij alleen de ontbrekende transacties worden overgedragen uit de cache van een donor. Het SST-proces is vergelijkbaar met het nemen van een volledige back-up van de donor, het is meestal behoorlijk arbeidsintensief. Galera bepaalt automatisch welk synchronisatieproces moet worden gestart op basis van de status van de schrijnwerker. In de meeste gevallen, als een knooppunt geen lid wordt van een cluster, verwijdert u eenvoudig de MySQL-datadir van het problematische knooppunt en start u de MySQL-service. Het inrichtingsproces van Galera is veel eenvoudiger, het is erg handig bij het uitschalen van uw cluster of het opnieuw introduceren van een problematisch knooppunt in het cluster.

Los gekoppeld versus nauw gekoppeld

MySQL-replicatie werkt heel goed, zelfs over langzamere verbindingen en met verbindingen die niet continu zijn. Het kan ook worden gebruikt in verschillende hardware, omgevingen en besturingssystemen. De meeste storage-engines ondersteunen het, waaronder MyISAM, Aria, MEMORY en ARCHIVE. Dankzij deze losjes gekoppelde configuratie kan MySQL-master-master-replicatie goed werken in een gemengde omgeving met minder beperkingen.

Galera-knooppunten zijn nauw aan elkaar gekoppeld, waarbij de replicatieprestaties net zo snel zijn als het langzaamste knooppunt. Galera gebruikt een stroomcontrolemechanisme om de replicatiestroom tussen leden te regelen en eventuele slaafvertragingen te elimineren. De replicatie kan op elk knooppunt snel of langzaam zijn en wordt automatisch aangepast door Galera. Daarom wordt aanbevolen om uniforme hardwarespecificaties te gebruiken voor alle Galera-knooppunten, vooral met betrekking tot CPU, RAM, schijfsubsysteem, netwerkinterfacekaart en netwerklatentie tussen knooppunten in het cluster.

Conclusies

Samengevat is Galera Cluster superieur in vergelijking met MySQL master-master-replicatie vanwege de synchrone replicatie-ondersteuning met sterke consistentie, plus meer geavanceerde functies zoals automatisch lidmaatschapsbeheer, automatische node-provisioning en multi-threaded slaves. Uiteindelijk hangt dit af van hoe de toepassing samenwerkt met de databaseserver. Sommige legacy-applicaties die zijn gebouwd voor een zelfstandige databaseserver werken mogelijk niet goed op een geclusterde installatie.

Om onze bovenstaande punten te vereenvoudigen, rechtvaardigen de volgende redenen wanneer MySQL master-master replicatie moet worden gebruikt:

• Dingen die niet door Galera worden ondersteund:
  • Replicatie voor niet-InnoDB/XtraDB-tabellen zoals MyISAM, Aria, MEMORY of ARCHIVE.
  • XA-transacties.
  • Replicatie op basis van verklaringen tussen masters (bijv. wanneer bandbreedte erg duur is).
  • Vertrouwen op expliciete vergrendeling zoals LOCK TABLES-instructie.
  • Het algemene zoeklogboek en het trage zoeklogboek moeten naar een tabel worden geleid in plaats van naar een bestand.
• Los gekoppelde configuratie waarbij de hardwarespecificaties, softwareversie en verbindingssnelheid op elke master aanzienlijk verschillen.
• Als je al een MySQL-replicatieketen hebt en je wilt nog een actieve/back-upmaster toevoegen voor redundantie om de failover- en hersteltijd te versnellen als een van de masters niet beschikbaar is.
• Als uw toepassing niet kan worden aangepast om de beperkingen van Galera Cluster te omzeilen en een MySQL-bewuste load balancer zoals ProxySQL of MaxScale geen optie is.

Redenen om Galera Cluster te verkiezen boven MySQL master-master replicatie:

• Mogelijkheid om veilig naar meerdere masters te schrijven.
• Gegevensconsistentie wordt automatisch beheerd (en gegarandeerd) in alle databases.
• Nieuwe databaseknooppunten eenvoudig geïntroduceerd en gesynchroniseerd.
• Fouten of inconsistenties worden automatisch gedetecteerd.
• Over het algemeen meer geavanceerde en robuuste functies voor hoge beschikbaarheid.