Streaming-replicatie is een nieuwe functie die werd geïntroduceerd met de 4.0-release van Galera Cluster. Galera gebruikt replicatie synchroon over het hele cluster, maar voor deze release werden schrijfsets groter dan 2 GB niet ondersteund. Met streamingreplicatie kunt u nu grote schrijfsets repliceren, wat perfect is voor bulkinvoegingen of het laden van gegevens in uw database.
In een eerdere blog schreven we over het afhandelen van grote transacties met streamingreplicatie en MariaDB 10.4, maar op het moment van schrijven van deze blog had Codership hun versie van de nieuwe Galera Cluster nog niet uitgebracht. Percona heeft echter hun experimentele binaire versie van Percona XtraDB Cluster 8.0 uitgebracht, die de volgende kenmerken benadrukt...
-
Streaming-replicatie die grote transacties ondersteunt
-
De synchronisatiefuncties maken actiecoördinatie mogelijk (wsrep_last_seen_gtid, wsrep_last_written_gtid, wsrep_sync_wait_upto_gtid)
-
Meer gedetailleerde en verbeterde foutenregistratie. wsrep_debug is nu een variabele met meerdere waarden om te helpen bij het beheren van de logging, en logging-berichten zijn aanzienlijk verbeterd.
-
Sommige DML- en DDL-fouten op een replicerend knooppunt kunnen worden genegeerd of onderdrukt. Gebruik de variabele wsrep_ignore_apply_errors om te configureren.
-
Meerdere systeemtabellen helpen om meer te weten te komen over de status van de clusterstatus.
-
De wsrep-infrastructuur van Galera 4 is robuuster dan die van Galera 3. Het beschikt over een snellere uitvoering van code met betere statusafhandeling, verbeterde voorspelbaarheid en foutafhandeling.
Wat is er nieuw in Galera Cluster 4.0?
De nieuwe functie voor streaming-replicatie
Met Streaming Replication worden transacties tijdens de transactieverwerking geleidelijk in kleine fragmenten gerepliceerd (d.w.z. vóór de daadwerkelijke vastlegging repliceren we een aantal kleine fragmenten). Gerepliceerde fragmenten worden vervolgens toegepast in slave-threads, waarbij de status van de transactie in alle clusterknooppunten behouden blijft. Fragmenten bevatten vergrendelingen in alle knooppunten en kunnen later niet met elkaar in conflict komen.
Galera-systeemtabellen
Databasebeheerders en clients met toegang tot de MySQL-database kunnen deze tabellen lezen, maar ze kunnen ze niet wijzigen, aangezien de database zelf de nodige wijzigingen zal aanbrengen. Als uw server deze tabellen niet heeft, kan het zijn dat uw server een oudere versie van Galera Cluster gebruikt.
#> 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)Nieuwe synchronisatiefuncties
Deze versie introduceert een reeks SQL-functies voor gebruik in wsrep-synchronisatiebewerkingen. U kunt ze gebruiken om de algemene transactie-ID te verkrijgen die is gebaseerd op de laatst geschreven of laatst geziene transactie. U kunt het knooppunt ook zo instellen dat het wacht tot een specifieke GTID wordt gerepliceerd en toegepast voordat de volgende transactie wordt gestart.
Intelligente donorselectie
Sommige ingetogen functies die sinds Galera 3.x aanwezig zijn, zijn intelligente donorselectie en herstel van clustercrashes. Deze waren oorspronkelijk gepland voor Galera 4, maar zijn grotendeels door de eisen van de klant in eerdere releases terechtgekomen. Als het gaat om de selectie van donorknooppunten in Galera 3, is de State Snapshot Transfer (SST) -donor willekeurig geselecteerd. Met Galera 4 krijgt u echter een veel intelligentere keuze als het gaat om het kiezen van een donor, omdat het een donor zal bevoordelen die een Incremental State Transfer (IST) kan bieden, of een donor in hetzelfde segment kan kiezen. Als databasebeheerder kunt u dit forceren door wsrep_sst_donor in te stellen.
Waarom MySQL Galera Cluster Streaming Replicatie gebruiken?
Langlopende transacties
Galera's problemen en beperkingen hadden altijd te maken met de manier waarop het langlopende transacties afhandelde en zorgde er vaak voor dat het hele cluster trager werd omdat grote schrijfsets werden gerepliceerd. De stroomcontrole gaat vaak hoog, waardoor de schrijfbewerkingen vertragen of zelfs het proces beëindigen om het cluster terug te brengen naar de normale staat. Dit is een vrij algemeen probleem met eerdere versies van Galera Cluster.
Codership adviseert om streamingreplicatie te gebruiken voor uw langlopende transacties om deze situaties te beperken. Zodra het knooppunt een fragment repliceert en certificeert, is het niet langer mogelijk voor andere transacties om het af te breken.
Grote transacties
Dit is erg handig bij het laden van gegevens in uw rapport of analyses. Het maken van bulkinvoegingen, verwijderingen, updates of het gebruik van de LOAD DATA-instructie om grote hoeveelheden gegevens te laden, kan in deze categorie vallen. Hoewel het afhangt van hoe u uw gegevens beheert voor het ophalen of opslaan. U moet er rekening mee houden dat Streaming Replication zijn beperkingen heeft, zodat certificeringssleutels worden gegenereerd uit recordvergrendelingen.
Zonder streamingreplicatie zou het bijwerken van een groot aantal records resulteren in een conflict en zou de hele transactie moeten worden teruggedraaid. Slaves die ook grote transacties repliceren, zijn onderworpen aan de stroomregeling wanneer deze de drempel bereikt en het hele cluster begint te vertragen om schrijfbewerkingen te verwerken, omdat ze de neiging hebben om het ontvangen van inkomende transacties van de synchrone replicatie te ontspannen. Galera zal de replicatie versoepelen totdat de schrijfset beheersbaar is, omdat het de replicatie weer kan voortzetten. Bekijk deze externe blog van Percona om meer te weten te komen over flow control binnen Galera.
Met Streaming Replication begint het knooppunt de gegevens te repliceren met elk transactiefragment, in plaats van te wachten op de vastlegging. Dit betekent dat er geen manier is om conflicterende transacties die binnen de andere knooppunten worden uitgevoerd, af te breken, omdat dit eenvoudig bevestigt dat het cluster de schrijfset voor dit specifieke fragment heeft gecertificeerd. Het is gratis om andere gelijktijdige transacties toe te passen en vast te leggen zonder grote transacties te blokkeren en te verwerken met een minimale impact op het cluster.
Hot Records/Hotspots
Hot records of rijen zijn die rijen in je tabel die constant worden bijgewerkt. Deze gegevens kunnen het meest worden bezocht en krijgen veel verkeer van uw hele database (bijvoorbeeld nieuwsfeeds, een teller zoals het aantal bezoeken of logs). Met Streaming Replication kunt u kritieke updates forceren voor het hele cluster.
Zoals opgemerkt door het Galera-team bij Codership
“Als u een transactie op deze manier uitvoert, wordt de hot record op alle knooppunten effectief vergrendeld, waardoor wordt voorkomen dat andere transacties de rij wijzigen. Het vergroot ook de kans dat de transactie succesvol wordt uitgevoerd en dat de klant op zijn beurt het gewenste resultaat krijgt.”
Dit komt met beperkingen omdat het misschien niet persistent en consistent is dat je succesvolle commits zult hebben. Zonder streamingreplicatie te gebruiken, krijgt u grote kansen of terugdraait en dat kan de eindgebruiker extra kosten wanneer u dit probleem ervaart vanuit het perspectief van de toepassing.
Aandachtspunten bij het gebruik van streamingreplicatie
- Certificeringssleutels worden gegenereerd op basis van recordvergrendelingen, daarom dekken ze geen openingvergrendelingen of volgende sleutelvergrendelingen. Als de transactie een gap-lock krijgt, is het mogelijk dat een transactie, die wordt uitgevoerd op een ander knooppunt, een schrijfset toepast die het gap-log tegenkomt en de streaming-transactie afbreekt.
- Bij het inschakelen van streamingreplicatie worden schrijfset-logboeken geschreven naar de wsrep_streaming_log-tabel in de mysql-systeemdatabase om persistentie te behouden in het geval dat er een crash optreedt, dus deze tabel dient bij herstel. In het geval van overmatige logboekregistratie en verhoogde replicatie-overhead, veroorzaakt streamingreplicatie een verslechterde transactiedoorvoersnelheid. Dit kan een prestatie knelpunt zijn wanneer een hoge piekbelasting wordt bereikt. Daarom wordt aanbevolen dat u streamingreplicatie alleen op sessieniveau inschakelt en dan alleen voor transacties die zonder deze niet correct zouden verlopen.
- Het beste gebruik is om streaming-replicatie te gebruiken voor het afsnijden van grote transacties
- Stel de fragmentgrootte in op ~10K rijen
- Fragmentvariabelen zijn sessievariabelen en kunnen dynamisch worden ingesteld
- Intelligente applicatie kan streaming-replicatie naar behoefte in-/uitschakelen
Conclusie
Bedankt voor het lezen, in deel twee bespreken we hoe u Galera Cluster Streaming Replication kunt inschakelen en hoe de resultaten eruit kunnen zien voor uw installatie.