Streaming Replication är en ny funktion som introducerades med 4.0-versionen av Galera Cluster. Galera använder replikering synkront över hela klustret, men innan den här utgåvan stöddes inte skrivuppsättningar större än 2 GB. Med strömmande replikering kan du nu replikera stora skrivuppsättningar, vilket är perfekt för massinsättningar eller för att ladda data till din databas.
I en tidigare blogg skrev vi om Hantering av stora transaktioner med Streaming Replication och MariaDB 10.4, men när den här bloggen skrevs hade Codership ännu inte släppt sin version av det nya Galera Cluster. Percona har dock släppt sin experimentella binära version av Percona XtraDB Cluster 8.0 som lyfter fram följande funktioner...
-
Streamande replikering som stöder stora transaktioner
-
Synkroniseringsfunktionerna tillåter åtgärdskoordinering (wsrep_last_seen_gtid, wsrep_last_written_gtid, wsrep_sync_wait_upto_gtid)
-
Mer detaljerad och förbättrad felloggning. wsrep_debug är nu en variabel med flera värden för att hjälpa till att kontrollera loggningen, och loggningsmeddelanden har förbättrats avsevärt.
-
Vissa DML- och DDL-fel på en replikerande nod kan antingen ignoreras eller undertryckas. Använd variabeln wsrep_ignore_apply_errors för att konfigurera.
-
Flera systemtabeller hjälper till att ta reda på mer om tillståndet för klustertillståndet.
-
wsrep-infrastrukturen i Galera 4 är mer robust än den i Galera 3. Den har en snabbare exekvering av kod med bättre tillståndshantering, förbättrad förutsägbarhet och felhantering.
Vad är nytt med Galera Cluster 4.0?
Den nya funktionen för streamingreplikering
Med strömmande replikering replikeras transaktioner gradvis i små fragment under transaktionsbearbetningen (dvs. innan vi faktiskt genomför, replikerar vi ett antal små fragment). Replikerade fragment appliceras sedan i slavtrådar, vilket bevarar transaktionens tillstånd i alla klusternoder. Fragment håller lås i alla noder och kan inte ställas i konflikt senare.
Galera SystemTables
Databasadministratörer och klienter med åtkomst till MySQL-databasen kan läsa dessa tabeller, men de kan inte ändra dem eftersom databasen själv kommer att göra de modifieringar som behövs. Om din server inte har dessa tabeller kan det vara så att din server använder en äldre version av 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)Nya synkroniseringsfunktioner
Denna version introducerar en serie SQL-funktioner för användning i wsrep-synkroniseringsoperationer. Du kan använda dem för att erhålla det globala transaktions-ID:t som är baserat på antingen den senast skrivna eller senast sett transaktionen. Du kan också ställa in noden så att den väntar på att ett specifikt GTID ska replikeras och tillämpas innan nästa transaktion påbörjas.
Intelligent donatorval
Några underskattade funktioner som har funnits sedan Galera 3.x inkluderar intelligent val av givare och återställning av klusterkrasch. Dessa var ursprungligen planerade för Galera 4, men gjorde det till tidigare utgåvor till stor del på grund av kundernas krav. När det gäller val av donatornod i Galera 3 valdes donatorn till State Snapshot Transfer (SST) slumpmässigt. Men med Galera 4 får du ett mycket mer intelligent val när det gäller att välja en givare, eftersom det kommer att gynna en givare som kan tillhandahålla en inkrementell statlig överföring (IST), eller välja en givare i samma segment. Som databasadministratör kan du tvinga fram detta via inställningen wsrep_sst_donor.
Varför använda MySQL Galera Cluster Streaming Replication?
Långvariga transaktioner
Galeras problem och begränsningar kretsade alltid kring hur det hanterade långvariga transaktioner och fick ofta hela klustret att sakta ner på grund av att stora skrivuppsättningar replikerades. Dets flödeskontroll går ofta högt, vilket gör att skrivningarna saktar ner eller till och med avslutar processen för att återställa klustret till sitt normala tillstånd. Detta är ett ganska vanligt problem med tidigare versioner av Galera Cluster.
Codership rekommenderar att du använder Streaming Replication för dina långvariga transaktioner för att mildra dessa situationer. När noden replikerar och certifierar ett fragment är det inte längre möjligt för andra transaktioner att avbryta det.
Stora transaktioner
Detta är mycket användbart när du laddar data till din rapport eller analys. Att skapa massinlägg, ta bort, uppdatera eller använda LOAD DATA-satsen för att ladda stora mängder data kan falla ner i denna kategori. Även om det beror på hur du hanterar din data för hämtning eller lagring. Du måste ta hänsyn till att Streaming Replication har sina begränsningar så att certifieringsnycklar genereras från postlås.
Utan strömmande replikering skulle uppdatering av ett stort antal poster resultera i en konflikt och hela transaktionen skulle behöva återställas. Slavar som också replikerar stora transaktioner är föremål för flödeskontrollen när den når tröskeln och börjar sakta ner hela klustret för att bearbeta eventuella skrivningar eftersom de tenderar att slappna av att ta emot inkommande transaktioner från den synkrona replikeringen. Galera kommer att koppla av replikeringen tills skrivuppsättningen är hanterbar eftersom den gör det möjligt att fortsätta replikeringen igen. Kolla in den här externa bloggen av Percona för att hjälpa dig förstå mer om flödeskontroll inom Galera.
Med strömmande replikering börjar noden replikera data med varje transaktionsfragment, snarare än att vänta på commit. Detta betyder att det inte finns något sätt för eventuella motstridiga transaktioner som körs inom de andra noderna att avbryta eftersom detta helt enkelt bekräftar att klustret har certifierat skrivuppsättningen för just detta fragment. Det är gratis att ansöka och utföra andra samtidiga transaktioner utan att blockera och bearbeta stora transaktioner med minimal påverkan på klustret.
Hot Records/Hot Spots
Hot-poster eller rader är de rader i din tabell som hela tiden uppdateras. Dessa data kan vara de mest besökta och får mycket trafik från hela din databas (t.ex. nyhetsflöden, en räknare som antal besök eller loggar). Med Streaming Replication kan du tvinga fram viktiga uppdateringar till hela klustret.
Som noterat av Galera-teamet på Codership
“Att köra en transaktion på detta sätt låser effektivt hot-posten på alla noder, vilket förhindrar andra transaktioner från att ändra raden. Det ökar också chanserna att transaktionen kommer att genomföras framgångsrikt och att kunden i sin tur får det önskade resultatet.”
Detta kommer med begränsningar eftersom det kanske inte är ihållande och konsekvent att du kommer att ha framgångsrika commits. Utan att använda Streaming Replication kommer du att få höga chanser eller återkallningar och det kan lägga till extra kostnader för slutanvändaren när du upplever det här problemet i programmets perspektiv.
Saker att tänka på när du använder strömmande replikering
- Certifieringsnycklar genereras från registerlås, därför täcker de inte mellanrumslås eller nästa nyckellås. Om transaktionen tar ett gaplås är det möjligt att en transaktion, som exekveras på en annan nod, kommer att tillämpa en skrivuppsättning som möter gaploggen och kommer att avbryta strömmande transaktionen.
- När du aktiverar strömmande replikering skrivs skrivuppsättningsloggar till tabellen wsrep_streaming_log som finns i mysql-systemets databas för att bevara beständigheten om en krasch inträffar, så den här tabellen fungerar vid återställning. I händelse av överdriven loggning och förhöjd replikeringsoverhead, kommer strömmande replikering att orsaka försämrad transaktionsgenomströmningshastighet. Detta kan vara en prestandaflaskhals när hög toppbelastning uppnås. Därför rekommenderas det att du endast aktiverar strömmande replikering på sessionsnivå och då endast för transaktioner som inte skulle fungera korrekt utan den.
- Bästa användningsfallet är att använda strömmande replikering för att klippa stora transaktioner
- Ange fragmentstorlek till ~10 000 rader
- Fragmentvariabler är sessionsvariabler och kan ställas in dynamiskt
- Intelligent applikation kan sätta på/av strömmande replikering efter behov
Slutsats
Tack för att du läste, i del två kommer vi att diskutera hur du aktiverar Galera Cluster Streaming Replication och hur resultaten kan se ut för din installation.