We hebben eerder geblogd over What's New in MySQL Galera Cluster 4.0, Handling Large Transactions with Streaming Replication en MariaDB 10.4 en hebben enkele handleidingen gepresenteerd over het gebruik van de nieuwe Streaming Replication-functie in een deel 1 en deel 2-serie.
Het verplaatsen van uw databasetechnologie van MySQL-replicatie naar MySQL Galera Cluster vereist dat u over de juiste vaardigheden beschikt en begrijpt wat u doet om succesvol te zijn. In deze blog delen we enkele tips voor het migreren van een MySQL-replicatieconfiguratie naar een MySQL Galera Cluster 4.0-configuratie.
De verschillen tussen MySQL-replicatie en Galera-cluster
Als u Galera nog niet kent, raden we u aan onze Galera-cluster voor MySQL-zelfstudie door te nemen. Galera Cluster gebruikt een heel ander replicatieniveau op basis van synchrone replicatie, in tegenstelling tot de MySQL-replicatie die asynchrone replicatie gebruikt (maar die ook kan worden geconfigureerd om een semi-synchrone replicatie te bereiken).
Galera Cluster ondersteunt ook multi-master replicatie. Het is in staat tot onbeperkte parallelle toepassing (d.w.z. "parallelle replicatie"), multicast-replicatie en automatische node-provisioning.
De primaire focus van Galera Cluster is gegevensconsistentie, terwijl het bij MySQL-replicatie vatbaar is voor gegevensinconsistentie (wat kan worden vermeden met best practices en de juiste configuratie, zoals het afdwingen van alleen-lezen op de slaves om te voorkomen dat ongewenste schrijfacties binnen de slaves).
Hoewel transacties die door Galera worden ontvangen, op elk knooppunt worden toegepast of helemaal niet, certificeert elk van deze knooppunten de gerepliceerde schrijfset in de applier-wachtrij (transactietoezeggingen), die ook informatie bevat over alle sloten die tijdens de transactie door de database werden vastgehouden. Deze schrijfset, zodra er geen conflicterende vergrendelingen zijn geïdentificeerd, worden toegepast. Tot nu toe worden transacties als vastgelegd beschouwd en blijven ze deze toepassen op de tabelruimte. In tegenstelling tot asynchrone replicatie, wordt deze benadering ook virtueel synchrone replicatie genoemd, omdat het schrijven en vastleggen in een logische synchrone modus gebeurt, maar het daadwerkelijke schrijven en vastleggen naar de tabelruimte gebeurt onafhankelijk en gaat asynchroon op elk knooppunt.
In tegenstelling tot MySQL-replicatie is een Galera-cluster een echte multi-master, multi-threaded slave, een pure hot-standby, zonder dat master-failover of lees-schrijfsplitsing nodig is. Migreren naar Galera Cluster betekent echter niet automatisch een antwoord op uw problemen. Galera Cluster ondersteunt alleen InnoDB, dus er kunnen ontwerpwijzigingen zijn als u MyISAM- of geheugenopslagengines gebruikt.
Niet-InnoDB-tabellen converteren naar InnoDB
Met Galera Cluster kunt u MyISAM gebruiken, maar dit is niet waarvoor Galera Cluster is ontworpen. Galera Cluster is ontworpen om gegevensconsistentie strikt te implementeren binnen alle knooppunten binnen de Cluster en dit vereist een sterke ACID-compatibele database-engine. InnoDB is een engine die deze sterke mogelijkheden op dit gebied heeft en het wordt aanbevolen om InnoDB te gebruiken; vooral als het om transacties gaat.
Als u ClusterControl gebruikt, kunt u gemakkelijk uw database-instantie(s) bepalen voor MyISAM-tabellen die worden geleverd door Performance Advisors. U vindt deze onder het tabblad Prestaties → Adviseurs. Bijvoorbeeld,
Als u MyISAM- en MEMORY-tabellen nodig heeft, kunt u deze nog steeds gebruiken, maar zeker van uw gegevens die niet hoeven te worden gerepliceerd. U kunt uw gegevens die zijn opgeslagen voor alleen-lezen gebruiken en waar nodig "START TRANSACTIE ALLEEN-LEZEN" gebruiken.
Primaire sleutels toevoegen aan uw InnoDB-tabellen
Aangezien Galera Cluster alleen InnoDB ondersteunt, is het erg belangrijk dat al uw tabellen een geclusterde index moeten hebben (ook wel primaire sleutel of unieke sleutel genoemd). Om de beste prestaties uit query's, invoegingen en andere databasebewerkingen te halen, is het erg belangrijk dat u elke tabel met een unieke sleutel(s) moet definiëren, aangezien InnoDB de geclusterde index gebruikt om de meest voorkomende opzoek- en DML-bewerkingen voor elke tabel te optimaliseren . Dit helpt langlopende query's binnen het cluster te voorkomen en kan schrijf-/leesbewerkingen in het cluster mogelijk vertragen.
In ClusterControl zijn er adviseurs die u hiervan op de hoogte kunnen stellen. In uw MySQL-replicatie master/slave-cluster krijgt u bijvoorbeeld een alarm uit de of weergave uit de lijst met adviseurs. De voorbeeldscreenshot hieronder laat zien dat je geen tabellen hebt die geen primaire sleutel hebben:
Identificeer een Master (of Active-Writer) Node
Galera Cluster is puur een echte multi-master replicatie. Het betekent echter niet dat u allemaal vrij bent om te schrijven op welk knooppunt u zich ook wilt richten. Een ding om te identificeren is dat wanneer u op een ander knooppunt schrijft en een conflicterende transactie wordt gedetecteerd, u in een impasse komt, zoals hieronder:
2019-11-14T21:14:03.797546Z 12 [Note] [MY-011825] [InnoDB] *** Priority TRANSACTION:
TRANSACTION 728431, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
MySQL thread id 12, OS thread handle 140504401893120, query id 1414279 Applying batch of row changes (update)
2019-11-14T21:14:03.797696Z 12 [Note] [MY-011825] [InnoDB] *** Victim TRANSACTION:
TRANSACTION 728426, ACTIVE 3 sec updating or deleting
mysql tables in use 1, locked 1
, undo log entries 11409
MySQL thread id 57, OS thread handle 140504353195776, query id 1414228 localhost root updating
update sbtest1_success set k=k+1 where id > 1000 and id < 100000
2019-11-14T21:14:03.797709Z 12 [Note] [MY-011825] [InnoDB] *** WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 1663 page no 11 n bits 144 index PRIMARY of table `sbtest`.`sbtest1_success` trx id 728426 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;Het probleem met het schrijven van meerdere knooppunten zonder een huidige actieve schrijver-knooppunt te identificeren, u krijgt deze problemen die veelvoorkomende problemen zijn die ik heb gezien bij het gebruik van Galera Cluster bij het schrijven op meerdere knooppunten op dezelfde tijd. Om dit te voorkomen, kunt u een single-master setup-aanpak gebruiken:
Uit de documentatie,
Als u de stroomregeling wilt ontspannen, kunt u de onderstaande instellingen gebruiken:
wsrep_provider_options = "gcs.fc_limit = 256; gcs.fc_factor = 0.99; gcs.fc_master_slave = YES"Het bovenstaande vereist een herstart van de server, aangezien fc_master_slave niet dynamisch is.
Schakel de foutopsporingsmodus in voor het loggen van conflicten of impasses
Het opsporen van fouten of het opsporen van problemen met uw Galera-cluster is erg belangrijk. Locks in Galera zijn anders geïmplementeerd dan MySQL-replicatie. Het maakt gebruik van optimistische vergrendeling bij het omgaan met transacties in het hele cluster. In tegenstelling tot de MySQL-replicatie, heeft het alleen pessimistische vergrendeling die niet weet of er een dergelijke zelfde of conflicterende transactie wordt uitgevoerd in een co-master op een multi-master setup. Galera gebruikt nog steeds pessimistische vergrendeling, maar op het lokale knooppunt omdat het wordt beheerd door InnoDB, de ondersteunde opslagengine. Galera gebruikt optimistische vergrendeling wanneer het naar andere knooppunten gaat. Dit betekent dat er geen controle wordt gedaan met andere knooppunten op het cluster wanneer lokale vergrendelingen worden bereikt (pessimistische vergrendeling). Galera gaat ervan uit dat, zodra de transactie de commit-fase binnen de storage-engine passeert en de andere nodes op de hoogte zijn, alles in orde zal zijn en er geen conflicten zullen ontstaan.
In de praktijk is het het beste om wsrep_logs_conflicts in te schakelen. Hiermee worden de details van conflicterende MDL- en InnoDB-vergrendelingen in het cluster vastgelegd. Het inschakelen van deze variabele kan dynamisch worden ingesteld, maar let op zodra dit is ingeschakeld. Het zal uw foutenlogboekbestand uitgebreid vullen en uw schijf kan vollopen zodra uw foutenlogboekbestand te groot is.
Wees voorzichtig met uw DDL-query's
In tegenstelling tot MySQL-replicatie kan het uitvoeren van een ALTER-instructie alleen van invloed zijn op inkomende verbindingen die toegang nodig hebben tot of verwijzen naar de tabel waarop uw ALTER-instructie betrekking heeft. Het kan ook van invloed zijn op slaven als de tafel groot is en slaafvertraging kan veroorzaken. Schrijven naar uw master wordt echter niet geblokkeerd zolang uw query's niet in strijd zijn met de huidige ALTER. Dit is echter helemaal niet het geval bij het uitvoeren van uw DDL-statements zoals ALTER met Galera Cluster. ALTER-statements kunnen problemen veroorzaken, zoals het vastlopen van Galera-cluster vanwege clusterbrede vergrendeling of flow control begint de replicatie te verslappen terwijl sommige knooppunten herstellen van grote schrijfacties.
In sommige situaties kan het zijn dat u uitvalt in uw Galera-cluster als die tabel te groot is en een primaire en essentiële tabel is voor uw toepassing. Het kan echter worden bereikt zonder downtime. Zoals Rick James in zijn blog opmerkte, kun je de onderstaande aanbevelingen volgen:
RSU versus TOI
- Rolling Schema Upgrade =doe handmatig één node (offline) tegelijk
- Total Order Isolation =Galera synchroniseert zodat het op hetzelfde moment (in de replicatievolgorde) op alle knooppunten wordt gedaan. RSU en TOI
Let op:aangezien er geen manier is om de clients met de DDL te synchroniseren, moet u ervoor zorgen dat de clients tevreden zijn met het oude of het nieuwe schema. Anders moet u waarschijnlijk het hele cluster uitschakelen en tegelijkertijd zowel het schema als de clientcode omschakelen.
Een "snelle" DDL kan net zo goed via TOI worden gedaan. Dit is een voorlopige lijst van:
- CREATE/DROP/HERNAME DATABASE/TABLE
- VERANDER om STANDAARD te wijzigen
- VERANDER om de definitie van ENUM of SET te wijzigen (zie waarschuwingen in de handleiding)
- Bepaalde PARTITIE WIJZIGINGEN die snel zijn.
- DROP INDEX (anders dan PRIMAIRE SLEUTEL)
- INDEX TOEVOEGEN?
- Andere ALTER's op 'kleine' tafels.
- Met 5.6 en vooral 5.7 met veel ALTER ALGORITHM=INPLACE-gevallen, controleer welke ALTERs op welke manier moeten worden gedaan.
Gebruik anders RSU. Doe het volgende voor elk knooppunt afzonderlijk:
SET GLOBAL wsrep_OSU_method='RSU';Dit haalt ook de node uit het cluster.
ALTER TABLE
SET GLOBAL wsrep_OSU_method='TOI';Plaats terug, wat leidt tot hersynchronisatie (hopelijk een snelle IST, geen langzame SST)
Behoud de consistentie van uw cluster
Galera Cluster ondersteunt geen replicatiefilters zoals binlog_do_db of binlog_ignore_db omdat Galera niet afhankelijk is van binaire logboekregistratie. Het vertrouwt op het ringbufferbestand, ook wel GCache genoemd, waarin schrijfsets worden opgeslagen die langs het cluster worden gerepliceerd. U kunt geen inconsistent gedrag of status van dergelijke databaseknooppunten toepassen.
Galera daarentegen implementeert strikt gegevensconsistentie binnen het cluster. Het is nog steeds mogelijk dat er inconsistentie is waar rijen of records niet kunnen worden gevonden. Als u bijvoorbeeld uw variabele wsrep_OSU_method RSU of TOI instelt voor uw DDL ALTER-instructies, kan dit inconsistent gedrag veroorzaken. Bekijk deze externe blog van Percona over inconsistentie met Galera met TOI vs RSU.
Wsrep_on=OFF instellen en vervolgens DML- of DDL-query's uitvoeren kan gevaarlijk zijn voor uw cluster. U moet ook uw opgeslagen procedures, triggers, functies, gebeurtenissen of weergaven controleren als de resultaten niet afhankelijk zijn van de status of omgeving van een knooppunt. Wanneer een bepaalde node (knooppunten) inconsistent kan zijn, kan dit ertoe leiden dat het hele cluster uitvalt. Zodra Galera inconsistent gedrag detecteert, zal Galera proberen het cluster te verlaten en dat knooppunt te beëindigen. Daarom is het mogelijk dat alle knooppunten inconsistent kunnen zijn, waardoor u in een dilemma verkeert.
Als ook een Galera Cluster-knooppunt een crash ervaart, vooral in een periode met veel verkeer, is het beter om niet meteen met het knooppunt te beginnen. Voer in plaats daarvan een volledige SST uit of breng een nieuwe instantie zo snel mogelijk of zodra het verkeer op is. Het kan zijn dat het knooppunt inconsistent gedrag kan veroorzaken dat mogelijk beschadigde gegevens heeft.
Grote transacties scheiden en bepalen of u streamingreplicatie wilt gebruiken
Laten we meteen beginnen. Een van de grootste veranderingen, vooral op Galera Cluster 4.0, is de streamingreplicatie. Eerdere versies van Galera Cluster 4.0, het beperkt transacties <2GiB, wat doorgaans wordt beheerd door variabelen wsrep_max_ws_rows en wsrep_max_ws_size. Sinds Galera Cluster 4.0 kunt u> 2GiB aan transacties verzenden, maar u moet bepalen hoe groot de fragmenten moeten worden verwerkt tijdens de replicatie. Het moet per sessie worden ingesteld en de enige variabelen waar je op moet letten zijn wsrep_trx_fragment_unit en wsrep_trx_fragment_size. Het uitschakelen van de streamingreplicatie is eenvoudig, omdat het instellen van de wsrep_trx_fragment_size = 0 voldoende is. Houd er rekening mee dat het repliceren van een grote transactie ook overhead heeft op de slave-knooppunten (knooppunten die repliceren tegen de huidige active-writer/master-knooppunt), aangezien logboeken worden geschreven naar de wsrep_streaming_log-tabel in de MySQL-database.
Nog iets om toe te voegen, aangezien u met grote transacties te maken heeft, is het aanzienlijk dat uw transactie enige tijd kan duren om te voltooien, dus u moet rekening houden met het instellen van de variabele innodb_lock_wait_timeout hoog. Stel dit via sessie in, afhankelijk van de tijd die u inschat, maar groter is dan de tijd die u schat om het te voltooien. Verhoog anders een time-out.
We raden je aan deze vorige blog over streaming-replicatie in actie te lezen.
Granten-verklaringen repliceren
Als je GRANT's en gerelateerde bewerkingen gebruikt, handel dan naar de MyISAM/Aria-tabellen in de database `mysql`. De GRANT-instructies worden gerepliceerd, maar de onderliggende tabellen niet. Dit betekent dus dat INSERT INTO mysql.user ... niet wordt gerepliceerd omdat de tabel MyISAM is.
Het bovenstaande is misschien niet meer waar sinds Percona XtraDB Cluster(PXC) 8.0 (momenteel experimenteel) aangezien mysql-schematabellen zijn geconverteerd naar InnoDB, terwijl in MariaDB 10.4 sommige tabellen nog steeds in Aria-formaat, maar andere zijn in CSV of InnoDB. U moet bepalen welke versie en provider van Galera u heeft, maar u kunt het beste geen DML-instructies gebruiken die verwijzen naar het mysql-schema. Anders kunt u onverwachte resultaten krijgen, tenzij u zeker weet dat dit PXC 8.0 is.
XA-transacties, LOCK/UNLOCK TABLES, GET_LOCK/RELEASE_LOCK worden niet ondersteund
Galera Cluster ondersteunt geen XA-transacties, aangezien XA-transacties het terugdraaien en vastleggen anders afhandelt. LOCK/UNLOCK of GET_LOCK/RELEASE_LOCK verklaringen zijn gevaarlijk om te worden toegepast of gebruikt met Galera. U kunt een crash ervaren of sloten die niet kunnen worden gedood en vergrendeld blijven. Bijvoorbeeld,
---TRANSACTION 728448, ACTIVE (PREPARED) 13356 sec
mysql tables in use 2, locked 2
3 lock struct(s), heap size 1136, 5 row lock(s), undo log entries 5
MySQL thread id 67, OS thread handle 140504353195776, query id 1798932 localhost root wsrep: write set replicated and certified (13)
insert into sbtest1(k,c,pad) select k,c,pad from sbtest1_success limit 5Deze transactie is al ontgrendeld en zelfs afgebroken, maar het mocht niet baten. We raden u aan uw applicatieclient opnieuw te ontwerpen en deze functies te verwijderen wanneer u naar Galera Cluster migreert.
Netwerkstabiliteit is een MUST!!!
Galera Cluster kan zelfs probleemloos werken met inter-WAN-topologie of inter-geo-topologie (bekijk deze blog over het implementeren van inter-geo-topologie met Galera). Als uw netwerkverbinding tussen elk knooppunt echter niet stabiel is of af en toe uitvalt voor een onverwachte tijd, kan dit problematisch zijn voor het cluster. U kunt het beste een cluster hebben dat wordt uitgevoerd in een particulier en lokaal netwerk waar elk van deze knooppunten is verbonden. Wanneer u een knoop punt ontwerpt als herstel na nood gevallen, moet u plannen om een cluster te maken als deze zich in een andere regio of geografie bevinden. U kunt beginnen met het lezen van onze vorige blog, MySQL Galera-clusterreplicatie gebruiken om een geo-gedistribueerde cluster te maken:deel één, omdat dit u het beste kan helpen bij het bepalen van uw Galera-clustertopologie.
Nog iets om toe te voegen over het investeren in uw netwerkhardware, het zou problematisch zijn als uw netwerkoverdrachtsnelheid u een lagere snelheid biedt tijdens het opnieuw opbouwen van een instantie tijdens IST of erger bij SST, vooral als uw dataset enorm is . Het kan vele uren netwerkoverdracht vergen en dat kan de stabiliteit van uw cluster beïnvloeden, vooral als u een cluster met 3 knooppunten heeft terwijl er geen 2 knooppunten beschikbaar zijn waarbij deze 2 een donor en een deelnemer zijn. Houd er rekening mee dat tijdens de SST-fase de DONOR/JOINER-knooppunten niet in gebruik kunnen worden genomen totdat deze eindelijk kunnen synchroniseren met het primaire cluster.
In de vorige versie van Galera, als het gaat om de selectie van donorknooppunten, werd de State Snapshot Transfer (SST)-donor willekeurig geselecteerd. In Glera 4 is het veel meer verbeterd en heeft het de mogelijkheid om de juiste donor binnen het cluster te kiezen, omdat het een donor zal bevoordelen die een Incremental State Transfer (IST) kan bieden, of een donor in hetzelfde segment kan kiezen. Als alternatief kunt u de variabele wsrep_sst_donor instellen op de juiste donor die u altijd wilt kiezen.
Maak een back-up van uw gegevens en voer strenge tests uit tijdens de migratie en vóór de productie
Als je eenmaal klaar bent en hebt besloten om te proberen je gegevens te migreren naar Galera Cluster 4.0, zorg er dan voor dat je altijd een back-up hebt voorbereid. Als je ClusterControl hebt geprobeerd, zal het maken van back-ups gemakkelijker zijn om dit te doen.
Zorg ervoor dat u migreert naar de juiste versie van InnoDB en vergeet niet altijd mysql_upgrade toe te passen en uit te voeren voordat u de test uitvoert. Zorg ervoor dat al uw tests slagen voor het gewenste resultaat dat de MySQL-replicatie u kan bieden. Hoogstwaarschijnlijk is er geen verschil tussen de InnoDB-opslagengine die u gebruikt in een MySQL-replicatiecluster versus de MySQL Galera-cluster, zolang de aanbevelingen en tips vooraf zijn toegepast en voorbereid.
Conclusie
Migreren naar Galera Cluster 4.0 is misschien niet de gewenste oplossing voor databasetechnologie. Het trekt u echter niet weg om Galera Cluster 4.0 te gebruiken, zolang de specifieke vereisten kunnen worden voorbereid, ingesteld en geleverd. Galera Cluster 4.0 is nu een zeer krachtige haalbare keuze en optie geworden, vooral op een platform en oplossing met hoge beschikbaarheid. We raden je ook aan om deze externe blogs over Galera Caveats of the Limitations of Galera Cluster of deze handleiding van MariaDB te lezen.