Streaming-replikering er en ny funktion, som blev introduceret med 4.0-udgivelsen af Galera Cluster. Galera bruger replikering synkront på tværs af hele klyngen, men før denne udgivelse blev skrivesæt større end 2 GB ikke understøttet. Streaming-replikering giver dig mulighed for nu at replikere store skrivesæt, hvilket er perfekt til masseindsættelser eller indlæsning af data til din database.
I en tidligere blog skrev vi om Håndtering af store transaktioner med Streaming Replication og MariaDB 10.4, men i skrivende stund havde Codership endnu ikke udgivet deres version af den nye Galera Cluster. Percona har dog frigivet deres eksperimentelle binære version af Percona XtraDB Cluster 8.0, som fremhæver følgende funktioner...
-
Streamende replikering, der understøtter store transaktioner
-
Synkroniseringsfunktionerne tillader handlingskoordinering (wsrep_last_seen_gtid, wsrep_last_written_gtid, wsrep_sync_wait_upto_gtid)
-
Mere detaljeret og forbedret fejllogning. wsrep_debug er nu en variabel med flere værdier, der hjælper med at kontrollere logningen, og logningsmeddelelser er blevet væsentligt forbedret.
-
Nogle DML- og DDL-fejl på en replikerende node kan enten ignoreres eller undertrykkes. Brug variablen wsrep_ignore_apply_errors til at konfigurere.
-
Flere systemtabeller hjælper med at finde ud af mere om klyngetilstandens tilstand.
-
Wsrep-infrastrukturen i Galera 4 er mere robust end den i Galera 3. Den har en hurtigere eksekvering af kode med bedre tilstandshåndtering, forbedret forudsigelighed og fejlhåndtering.
Hvad er nyt med Galera Cluster 4.0?
Den nye streamingreplikeringsfunktion
Med Streaming Replikering replikeres transaktioner gradvist i små fragmenter under transaktionsbehandlingen (dvs. før den faktiske commit, replikerer vi en række små fragmenter). Replikerede fragmenter anvendes derefter i slavetråde, hvilket bevarer transaktionens tilstand i alle klynge noder. Fragmenter holder låse i alle noder og kan ikke modstrides senere.
Galera SystemTables
Databaseadministratorer og klienter med adgang til MySQL-databasen kan læse disse tabeller, men de kan ikke ændre dem, da databasen selv vil foretage de nødvendige ændringer. Hvis din server ikke har disse tabeller, kan det være, at din server bruger en ældre version af 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)Nye synkroniseringsfunktioner
Denne version introducerer en række SQL-funktioner til brug i wsrep-synkroniseringsoperationer. Du kan bruge dem til at få det globale transaktions-id, som er baseret på enten den sidst skrive- eller sidst set transaktion. Du kan også indstille noden til at vente på, at et specifikt GTID replikeres og anvendes, før den næste transaktion påbegyndes.
Intelligent donorvalg
Nogle underspillede funktioner, der har været til stede siden Galera 3.x, omfatter intelligent donorudvælgelse og gendannelse af klyngenedbrud. Disse var oprindeligt planlagt til Galera 4, men kom med i tidligere udgivelser, hovedsagelig på grund af kundernes krav. Når det kommer til udvælgelse af donorknudepunkter i Galera 3, blev State Snapshot Transfer (SST) donoren valgt tilfældigt. Men med Galera 4 får du et meget mere intelligent valg, når det kommer til at vælge en donor, da det vil favorisere en donor, der kan levere en inkrementel statsoverførsel (IST), eller vælge en donor i samme segment. Som databaseadministrator kan du gennemtvinge dette via indstilling af wsrep_sst_donor.
Hvorfor bruge MySQL Galera Cluster Streaming-replikering?
Langvarige transaktioner
Galeras problemer og begrænsninger drejede sig altid om, hvordan det håndterede langvarige transaktioner og fik ofte hele klyngen til at bremse på grund af store skrivesæt, der blev replikeret. Dets flowkontrol går ofte højt, hvilket får skrivningerne til at bremse eller endda afslutte processen for at vende klyngen tilbage til sin normale tilstand. Dette er et ret almindeligt problem med tidligere versioner af Galera Cluster.
Codership anbefaler at bruge Streaming Replication til dine langvarige transaktioner for at afbøde disse situationer. Når først noden replikerer og certificerer et fragment, er det ikke længere muligt for andre transaktioner at afbryde det.
Store transaktioner
Dette er meget nyttigt, når du indlæser data til din rapport eller analyse. Oprettelse af masseindsættelser, sletninger, opdateringer eller brug af LOAD DATA-sætning til at indlæse store mængder data kan falde ned i denne kategori. Selvom det afhænger af, hvordan du administrerer dine data til hentning eller opbevaring. Du skal tage højde for, at Streaming Replication har sine begrænsninger, således at certificeringsnøgler genereres fra registreringslåse.
Uden streamingreplikering ville opdatering af et stort antal poster resultere i en konflikt, og hele transaktionen skulle rulles tilbage. Slaver, der også replikerer store transaktioner, er underlagt flowstyringen, når den når tærsklen og begynder at bremse hele klyngen for at behandle eventuelle skrivninger, da de har tendens til at slappe af med at modtage indgående transaktioner fra den synkrone replikering. Galera vil slappe af replikeringen, indtil skrivesættet er overskueligt, da det giver mulighed for at fortsætte replikeringen igen. Tjek denne eksterne blog af Percona for at hjælpe dig med at forstå mere om flowkontrol i Galera.
Med Streaming Replication begynder noden at replikere dataene med hvert transaktionsfragment i stedet for at vente på commit. Dette betyder, at der ikke er nogen måde, hvorpå modstridende transaktioner, der kører inden for de andre noder, kan afbrydes, da dette blot bekræfter, at klyngen har certificeret skrivesættet for dette særlige fragment. Det er gratis at anvende og foretage andre samtidige transaktioner uden at blokere og behandle store transaktioner med en minimal indvirkning på klyngen.
Hot Records/Hot Spots
Hot records eller rows er de rækker i din tabel, der konstant bliver opdateret. Disse data kan være de mest besøgte og får meget trafik fra hele din database (f.eks. nyhedsfeeds, en tæller såsom antal besøg eller logfiler). Med Streaming Replikering kan du tvinge kritiske opdateringer til hele klyngen.
Som bemærket af Galera-teamet på Codership
“At køre en transaktion på denne måde låser effektivt hot record på alle noder, hvilket forhindrer andre transaktioner i at ændre rækken. Det øger også chancerne for, at transaktionen gennemføres med succes, og at kunden til gengæld vil modtage det ønskede resultat."
Dette kommer med begrænsninger, da det muligvis ikke er vedvarende og konsekvent, at du har succesfulde commits. Uden at bruge Streaming-replikering vil du ende med store chancer eller rollbacks, og det kan tilføje overhead til slutbrugeren, når de oplever dette problem i applikationens perspektiv.
Ting at overveje, når du bruger streamingreplikering
- Certificeringsnøgler er genereret fra registreringslåse, og derfor dækker de ikke mellemrumslåse eller næste nøglelåse. Hvis transaktionen tager en gap-lås, er det muligt, at en transaktion, som udføres på en anden node, vil anvende et skrivesæt, som støder på gap-loggen og vil afbryde streamingtransaktionen.
- Når streamingreplikering aktiveres, skrives skrivesætlogfiler til wsrep_streaming_log-tabellen, der findes i mysql-systemdatabasen, for at bevare persistens i tilfælde af nedbrud, så denne tabel tjener ved gendannelse. I tilfælde af overdreven logning og forhøjede replikeringsomkostninger vil streamingreplikering forårsage forringet transaktionsgennemstrømningshastighed. Dette kan være en flaskehals i ydeevnen, når høj spidsbelastning nås. Som sådan anbefales det, at du kun aktiverer streamingreplikering på sessionsniveau og derefter kun for transaktioner, der ikke ville køre korrekt uden det.
- Bedste use case er at bruge streaming replikering til at skære store transaktioner
- Indstil fragmentstørrelsen til ~10K rækker
- Fragmentvariabler er sessionsvariabler og kan indstilles dynamisk
- Intelligent applikation kan slå streamingreplikering til/fra efter behov
Konklusion
Tak fordi du læste med, i del to vil vi diskutere, hvordan du aktiverer Galera Cluster Streaming Replication, og hvordan resultaterne kunne se ud for din opsætning.