Vi har tidigare bloggat om vad som är nytt i MySQL Galera Cluster 4.0, Hantering av stora transaktioner med strömmande replikering och MariaDB 10.4 och presenterat några guider om hur du använder den nya strömreplikeringsfunktionen i en del 1 och del 2-serie.
Att flytta din databasteknik från MySQL-replikering till MySQL Galera Cluster kräver att du har rätt kompetens och förståelse för vad du gör för att bli framgångsrik. I den här bloggen kommer vi att dela med oss av några tips för att migrera från en MySQL-replikeringsinstallation till MySQL Galera Cluster 4.0 one.
Skillnaderna mellan MySQL-replikering och Galera-kluster
Om du ännu inte är bekant med Galera, föreslår vi att du går igenom vårt Galera-kluster för MySQL-handledning. Galera Cluster använder en helt annan nivå av replikering baserad på synkron replikering, i motsats till MySQL-replikeringen som använder asynkron replikering (men kan också konfigureras för att uppnå en semi-synkron replikering).
Galera Cluster stöder också multi-master replikering. Den är kapabel till obegränsad parallell applicering (d.v.s. "parallell replikering"), multicast-replikering och automatisk nodprovisionering.
Det primära fokuset för Galera Cluster är datakonsistens, medan det med MySQL-replikering är benäget att datainkonsekvens (vilket kan undvikas med bästa praxis och korrekt konfiguration som att tillämpa skrivskyddat på slavarna för att undvika oönskade skrivningar inom slavarna).
Även om transaktioner som tas emot av Galera antingen tillämpas på varje nod eller inte alls, certifierar var och en av dessa noder den replikerade skrivuppsättningen i applier-kön (transaktionsbekräftelser) som också innehåller information om alla lås som hölls av databasen under transaktionen. Dessa skrivuppsättningar, när inga motstridiga lås har identifierats, tillämpas. Fram till denna punkt anses transaktioner vara genomförda och fortsätter att tillämpa det på tabellutrymmet. Till skillnad från i asynkron replikering kallas detta tillvägagångssätt också praktiskt taget synkron replikering eftersom skrivningar och commits sker i ett logiskt synkront läge men själva skrivningen och commiteringen till tabellutrymmet sker oberoende och går asynkront på varje nod.
Till skillnad från MySQL-replikering är ett Galera-kluster en sann multi-master, flertrådad slav, en ren hot-standby, utan behov av master-failover eller läs-skriv-delning. Att migrera till Galera Cluster innebär dock inte ett automatiskt svar på dina problem. Galera Cluster stöder endast InnoDB, så det kan bli designändringar om du använder MyISAM- eller Memory-lagringsmotorer.
Konvertera icke-InnoDB-tabeller till InnoDB
Galera Cluster tillåter dig att använda MyISAM, men det är inte vad Galera Cluster designades för. Galera Cluster är designat för att strikt implementera datakonsistens inom alla noder inom klustret och detta kräver en stark ACID-kompatibel databasmotor. InnoDB är en motor som har så starka möjligheter inom detta område och rekommenderas att du använder InnoDB; speciellt när det gäller transaktioner.
Om du använder ClusterControl kan du enkelt bestämma din databasinstans(er) för alla MyISAM-tabeller som tillhandahålls av Performance Advisors. Du hittar detta under fliken Prestanda → Rådgivare. Till exempel,
Om du behöver MyISAM- och MEMORY-tabeller kan du fortfarande använda det men göra säkerställ din data som inte behöver replikeras. Du kan använda dina lagrade data för skrivskyddad och använda "STARTA TRANSAKTION ENDAST" där det är lämpligt.
Lägga till primärnycklar till dina InnoDB-tabeller
Eftersom Galera Cluster endast stöder InnoDB, är det mycket viktigt att alla dina tabeller måste ha ett klustrat index, (även kallad primärnyckel eller unik nyckel). För att få bästa möjliga prestanda från frågor, infogningar och andra databasoperationer är det mycket viktigt att du måste definiera varje tabell med en unik nyckel eftersom InnoDB använder det klustrade indexet för att optimera de vanligaste uppslags- och DML-operationerna för varje tabell. . Detta hjälper till att undvika långa pågående frågor inom klustret och kan eventuellt sakta ner skriv-/läsoperationer i klustret.
I ClusterControl finns det rådgivare som kan meddela dig om detta. Till exempel, i ditt MySQL-replikeringsmästar-/slavkluster kommer du att larma från eller från listan över rådgivare. Exemplet på skärmdumpen nedan visar att du inte har några tabeller som inte har någon primärnyckel:
Identifiera en huvudnod (eller Active-Writer)
Galera Cluster är en ren replikering av flera master. Det betyder dock inte att ni alla är fria att skriva vilken nod ni vill rikta in er på. En sak att identifiera är att när du skriver på en annan nod och en motstridig transaktion kommer att upptäckas, hamnar du i ett dödläge precis som nedan:
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;;Problemet med att flera noder skriver utan att identifiera en aktuell nod för aktiv skrivare, du kommer att sluta med dessa problem som är mycket vanliga problem som jag har sett när jag använder Galera Cluster när jag skriver på flera noder på samtidigt. För att undvika detta kan du använda en-master-inställningsmetod:
Från dokumentationen,
För att slappna av flödeskontrollen kan du använda inställningarna nedan:
wsrep_provider_options = "gcs.fc_limit = 256; gcs.fc_factor = 0.99; gcs.fc_master_slave = YES"Ovanstående kräver omstart av servern eftersom fc_master_slave inte är dynamisk.
Aktivera felsökningsläge för loggningskonflikter eller dödlägen
Att felsöka eller spåra problem med ditt Galera-kluster är mycket viktigt. Lås i Galera implementeras annorlunda jämfört med MySQL-replikering. Den använder optimistisk låsning när den hanterar transaktioner över hela kluster. Till skillnad från MySQL-replikeringen har den bara pessimistisk låsning som inte vet om det finns en sådan samma eller motstridiga transaktion som exekveras i en co-master på en multi-master setup. Galera använder fortfarande pessimistisk låsning men på den lokala noden eftersom den hanteras av InnoDB, som är lagringsmotorn som stöds. Galera använder optimistisk låsning när den går till andra noder. Detta innebär att inga kontroller görs med andra noder på klustret när lokala låsningar uppnås (pessimistisk låsning). Galera antar att när transaktionen passerar commit-fasen i lagringsmotorn och de andra noderna är informerade, kommer allt att vara okej och inga konflikter kommer att uppstå.
I praktiken är det bäst att aktivera wsrep_logs_conflicts. Detta kommer att logga detaljerna för motstridiga MDL- och InnoDB-lås i klustret. Aktivering av denna variabel kan ställas in dynamiskt, men varning när detta är aktiverat. Det kommer att fylla i din felloggfil och kan fylla upp din disk när din felloggfil är för stor.
Var försiktig med dina DDL-frågor
Till skillnad från MySQL-replikering kan körning av en ALTER-sats endast påverka inkommande anslutningar som kräver åtkomst till eller referens till den tabellen som din ALTER-sats är inriktad på. Det kan också påverka slavar om bordet är stort och kan ge slavlag. Skriver till din master kommer dock inte att blockeras så länge dina frågor inte kommer i konflikt med den aktuella ALTER. Detta är dock helt och hållet inte fallet när du kör dina DDL-satser som ALTER med Galera Cluster. ALTER-satser kan orsaka problem som att Galera Cluster har fastnat på grund av klusteromfattande låsning eller flödeskontroll börjar slappna av replikeringen medan vissa noder återhämtar sig från stora skrivningar.
I vissa situationer kan det sluta med driftstopp för ditt Galera-kluster om tabellen är för stor och är en primär och viktig tabell för din applikation. Det kan dock uppnås utan stillestånd. Som Rick James påpekade i sin blogg kan du följa rekommendationerna nedan:
RSU vs TOI
- Rolling Schema Upgrade =gör manuellt en nod (offline) åt gången
- Total Order Isolation =Galera synkroniseras så att det görs samtidigt (i replikeringssekvensen) på alla noder. RSU och TOI
Varning:Eftersom det inte finns något sätt att synkronisera klienterna med DDL, måste du se till att klienterna är nöjda med antingen det gamla eller det nya schemat. Annars måste du förmodligen ta ner hela klustret samtidigt som du byter över både schemat och klientkoden.
En "snabb" DDL kan lika gärna göras via TOI. Detta är en preliminär lista över sådana:
- SKAPA/SLÄPP/BYT NAMN DATABAS/TABELL
- ÄNDRA för att ändra STANDARD
- ÄNDRA för att ändra definitionen av ENUM eller SET (se varningar i manualen)
- Vissa PARTITIONSÄNDRINGAR som är snabba.
- DROP INDEX (annat än PRIMARY KEY)
- LÄGG TILL INDEX?
- Andra ALTERs på "små" tabeller.
- Med 5.6 och särskilt 5.7 som har många ALTER ALGORITHM=INPLACE-fall, kontrollera vilka ALTERs som ska göras åt vilket sätt.
Använd annars RSU. Gör följande separat för varje nod:
SET GLOBAL wsrep_OSU_method='RSU';Detta tar också noden ur klustret.
ALTER TABLE
SET GLOBAL wsrep_OSU_method='TOI';Lägger in igen, vilket leder till omsynkronisering (förhoppningsvis en snabb IST, inte en långsam SST)
Bevara konsistensen i ditt kluster
Galera Cluster stöder inte replikeringsfilter som binlog_do_db eller binlog_ignore_db eftersom Galera inte är beroende av binär loggning. Den förlitar sig på ringbuffertfilen även kallad GCache som lagrar skrivuppsättningar som replikeras längs klustret. Du kan inte tillämpa något inkonsekvent beteende eller tillstånd för sådana databasnoder.
Galera, å andra sidan, implementerar strikt datakonsistens inom klustret. Det är fortfarande möjligt att det kan finnas inkonsekvens där rader eller poster inte kan hittas. Om du till exempel ställer in din variabel wsrep_OSU_method antingen RSU eller TOI för dina DDL ALTER-satser kan ge inkonsekvent beteende. Kolla in den här externa bloggen från Percona som diskuterar inkonsekvens med Galera med TOI vs RSU.
Att ställa in wsrep_on=OFF och därefter köra DML- eller DDL-frågor kan vara farligt för ditt kluster. Du måste också granska dina lagrade procedurer, utlösare, funktioner, händelser eller vyer om resultaten inte är beroende av en nods tillstånd eller miljö. När en viss nod(er) kan vara inkonsekvent, kan det potentiellt få hela klustret att gå ner. När Galera upptäcker ett inkonsekvent beteende kommer Galera att försöka lämna klustret och avsluta den noden. Därför är det möjligt att alla noder kan vara inkonsekventa och lämnar dig i ett tillstånd av dilemma.
Om en Galera Cluster-nod också råkar ut för en krasch, särskilt under en period med hög trafik, är det bättre att inte starta noden direkt. Utför istället en fullständig SST eller ta med en ny instans så snart som möjligt eller när trafiken blir låg. Det kan vara möjligt att noden kan ge inkonsekvent beteende som kan ha skadat data.
Segregera stora transaktioner och avgör om du ska använda strömmande replikering
Låt oss ta det här direkt. En av de största förändringsfunktionerna speciellt på Galera Cluster 4.0 är strömmande replikering. Tidigare versioner av Galera Cluster 4.0, det begränsar transaktioner <2GiB vilket vanligtvis styrs av variablerna wsrep_max_ws_rows och wsrep_max_ws_size. Sedan Galera Cluster 4.0 kan du skicka> 2GiB med transaktioner men du måste bestämma hur stora fragmenten måste bearbetas under replikering. Det måste ställas in per session och de enda variablerna du behöver ta hand om är wsrep_trx_fragment_unit och wsrep_trx_fragment_size. Att inaktivera strömmande replikering är enkelt eftersom inställningen av wsrep_trx_fragment_size = 0 gör det. Observera att replikering av en stor transaktion också har overhead på slavnoderna (noder som replikerar mot den aktuella aktiva skrivaren/masternoden) eftersom loggar kommer att skrivas till tabellen wsrep_streaming_log i MySQL-databasen.
En annan sak att tillägga, eftersom du har att göra med stora transaktioner, är det avsevärt att din transaktion kan ta lite tid att slutföra, så inställningen av variabeln innodb_lock_wait_timeout hög måste tas med i beräkningen. Ställ in detta via session beroende på den tid du uppskattar men längre än den tid du beräknar att den ska avslutas, annars höj en timeout.
Vi rekommenderar att du läser den här tidigare bloggen om strömreplikering i praktiken.
Replicera GRANTs-uttalanden
Om du använder GRANTs och relaterade operationer, agera på MyISAM/Aria-tabellerna i databasen `mysql`. GRANT-satserna kommer att replikeras, men de underliggande tabellerna inte. Så det här betyder, INSERT INTO mysql.user ... inte kommer att replikeras eftersom tabellen är MyISAM.
Men ovanstående kanske inte stämmer längre eftersom Percona XtraDB Cluster(PXC) 8.0 (för närvarande experimentell) eftersom mysql-schematabeller har konverterats till InnoDB, medan i MariaDB 10.4 är några av tabellerna fortfarande i Aria-format men andra är i CSV eller InnoDB. Du bör bestämma vilken version och leverantör av Galera du har men bäst att undvika att använda DML-satser som refererar till mysql-schemat. Annars kan du få oväntade resultat om du inte är säker på att detta är PXC 8.0.
XA-transaktioner, LÅS/LÅS UPP TABELLER, GET_LOCK/RELEASE_LOCK stöds inte
Galera Cluster stöder inte XA Transactions eftersom XA Transactions hanterar återställning och åtar sig olika. LOCK/UNLOCK- eller GET_LOCK/RELEASE_LOCK-satser är farliga att tillämpa eller använda med Galera. Du kan råka ut för en krasch eller lås som inte går att döda och förblir låsta. Till exempel,
---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 5Den här transaktionen har redan låsts upp och till och med dödats men till ingen nytta. Vi föreslår att du måste designa om din applikationsklient och bli av med dessa funktioner när du migrerar till Galera Cluster.
Nätverksstabilitet är ett MÅSTE!!!
Galera Cluster kan fungera även med inter-WAN-topologi eller inter-geo-topologi utan några problem (kolla den här bloggen om att implementera inter-geo-topologi med Galera). Men om din nätverksanslutning mellan varje nod inte är stabil eller intermittent går ner under en oanad tid, kan det vara problematiskt för klustret. Det är bäst att du har ett kluster som körs i ett privat och lokalt nätverk där var och en av dessa noder är anslutna. När du designar en nod som en katastrofåterställning, planera då att skapa ett kluster om dessa är i en annan region eller geografi. Du kan börja läsa vår tidigare blogg, Använda MySQL Galera Cluster Replication för att skapa ett geodistribuerat kluster:Del ett eftersom detta kan hjälpa dig bäst att bestämma din Galera Cluster-topologi.
En annan sak att lägga till om att investera i din nätverkshårdvara, det skulle vara problematiskt om din nätverksöverföringshastighet ger dig en lägre hastighet under återuppbyggnad av en instans under IST eller värre vid SST, särskilt om din datauppsättning är massiv . Det kan ta långa timmar av nätverksöverföring och det kan påverka stabiliteten hos ditt kluster, särskilt om du har ett kluster med 3 noder medan 2 noder inte är tillgängliga där dessa 2 är en donator och en ansluter. Observera att under SST-fasen kan DONOR/JOINER-noderna inte användas förrän de äntligen kan synkroniseras med det primära klustret.
I tidigare version av Galera, när det gäller val av donatornod, valdes givaren till State Snapshot Transfer (SST) slumpmässigt. I Glera 4 har det förbättrats mycket mer och har förmågan att välja rätt givare inom klustret, 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. Alternativt kan du ställa in variabeln wsrep_sst_donor till rätt givare som du alltid vill välja.
Säkerhetskopiera dina data och gör rigida tester under migrering och före produktion
När du är klar och har bestämt dig för att försöka migrera dina data till Galera Cluster 4.0, se till att du alltid har din säkerhetskopia förberedd. Om du provade ClusterControl kommer det att vara lättare att ta säkerhetskopior.
Se till att du migrerar till rätt version av InnoDB och glöm inte att alltid använda och köra mysql_upgrade innan du gör testet. Se till att alla dina tester klarar det önskade resultatet som MySQL-replikeringen kan erbjuda dig. Troligtvis är det ingen skillnad med InnoDB-lagringsmotorn du använder i ett MySQL-replikeringskluster jämfört med MySQL Galera-klustret så länge som rekommendationerna och tipsen har tillämpats och förberetts i förväg.
Slutsats
Att migrera till Galera Cluster 4.0 kanske inte är din önskade databastekniklösning. Det hindrar dig dock inte att använda Galera Cluster 4.0 så länge dess specifika krav kan förberedas, ställas in och tillhandahålls. Galera Cluster 4.0 har nu blivit ett mycket kraftfullt genomförbart val och alternativ, särskilt på en mycket tillgänglig plattform och lösning. Vi föreslår också att du läser dessa externa bloggar om Galera Caveats eller Galera Clusters begränsningar eller den här manualen från MariaDB.