Tips til migrering fra MySQL-replikering til MySQL Galera Cluster 4.0

Vi har tidligere blogget om Hvad er nyt i MySQL Galera Cluster 4.0, Håndtering af store transaktioner med streamingreplikering og MariaDB 10.4 og præsenteret nogle vejledninger om brug af den nye streamingreplikeringsfunktion i en del 1 og del 2-serie.

At flytte din databaseteknologi fra MySQL-replikering til MySQL Galera Cluster kræver, at du har de rigtige færdigheder og en forståelse af, hvad du gør for at få succes. I denne blog vil vi dele nogle tips til migrering fra en MySQL-replikeringsopsætning til MySQL Galera Cluster 4.0 one.

Forskellene mellem MySQL-replikering og Galera-klynge

Hvis du endnu ikke er bekendt med Galera, foreslår vi, at du gennemgår vores Galera Cluster til MySQL Tutorial. Galera Cluster bruger et helt andet niveau af replikering baseret på synkron replikering, i modsætning til MySQL-replikeringen, der bruger asynkron replikering (men kan også konfigureres til at opnå en semi-synkron replikation).

Galera Cluster understøtter også multi-master replikering. Den er i stand til ubegrænset parallel anvendelse (dvs. "parallel replikering"), multicast-replikering og automatisk node-provisionering.

Det primære fokus for Galera Cluster er datakonsistens, hvorimod det med MySQL-replikering er tilbøjeligt til datainkonsistens (som kan undgås med bedste praksis og korrekt konfiguration, såsom at håndhæve skrivebeskyttet på slaverne for at undgå uønskede skriverier i slaverne).

Selvom transaktioner modtaget af Galera enten anvendes på hver knude eller slet ikke, certificerer hver af disse knudepunkter det replikerede skrivesæt i applikationskøen (transaktionsbekræftelser), som også indeholder oplysninger om alle de låse, der blev holdt af databasen under transaktionen. Disse skrivesæt, når der ikke er identificeret nogen modstridende låse, anvendes. Indtil dette tidspunkt betragtes transaktioner som forpligtede og fortsætter med at anvende dem på tablespacet. I modsætning til asynkron replikering kaldes denne tilgang også praktisk talt synkron replikering, da skrivning og commit sker i en logisk synkron tilstand, men den faktiske skrivning og commit til tablespacet sker uafhængigt og går asynkront på hver node.

I modsætning til MySQL-replikering er en Galera Cluster en ægte multi-master, multi-threaded slave, en ren hot-standby, uden behov for master-failover eller læse-skrive-opdeling. At migrere til Galera Cluster betyder dog ikke et automatisk svar på dine problemer. Galera Cluster understøtter kun InnoDB, så der kan være designændringer, hvis du bruger MyISAM eller Memory storage engines.

Konvertering af ikke-InnoDB-tabeller til InnoDB

Galera Cluster tillader dig at bruge MyISAM, men det er ikke det, Galera Cluster er designet til. Galera Cluster er designet til strengt at implementere datakonsistens i alle noderne i Clusteren, og dette kræver en stærk ACID-kompatibel databasemotor. InnoDB er en motor, der har så stærke muligheder på dette område, og det anbefales, at du bruger InnoDB; især når det drejer sig om transaktioner.

Hvis du bruger ClusterControl, kan du nemt finde ud af dine databaseforekomster for alle MyISAM-tabeller, som leveres af Performance Advisors. Du kan finde dette under Performance → Advisors fanen. For eksempel,

Hvis du har brug for MyISAM- og MEMORY-tabeller, kan du stadig bruge det, men laver sikker på dine data, der ikke skal replikeres. Du kan bruge dine data, der er gemt til skrivebeskyttet, og bruge "START TRANSAKTION KUN" hvor det er relevant.

Tilføjelse af primære nøgler til dine InnoDB-tabeller

Da Galera Cluster kun understøtter InnoDB, er det meget vigtigt, at alle dine tabeller skal have et klynget indeks (også kaldet primær nøgle eller unik nøgle). For at få den bedste ydeevne fra forespørgsler, indsættelser og andre databaseoperationer er det meget vigtigt, at du skal definere hver tabel med en eller flere unikke nøgler, da InnoDB bruger det klyngede indeks til at optimere de mest almindelige opslag og DML-operationer for hver tabel . Dette hjælper med at undgå langvarige forespørgsler i klyngen og kan muligvis bremse skrive-/læseoperationer i klyngen.

I ClusterControl er der rådgivere, som kan give dig besked om dette. For eksempel vil du i din MySQL-replikeringsmaster/slave-klynge afgive en alarm fra eller se fra listen over rådgivere. Eksempelskærmbilledet nedenfor afslører, at du ikke har nogen tabeller, der ikke har nogen primær nøgle:

Identificer en master- (eller Active-Writer) node

Galera Cluster er udelukkende en ægte multi-master replikering. Det betyder dog ikke, at I alle er frie til at skrive den node, I gerne vil målrette mod. En ting at identificere er, når du skriver på en anden node, og en modstridende transaktion vil blive opdaget, vil du komme ind i et dødvande problem ligesom nedenfor:

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 at flere noder skriver uden at identificere en aktuel aktiv-skriver-node, du vil ende med disse problemer, som er meget almindelige problemer, jeg har set, når jeg bruger Galera Cluster, når jeg skriver på flere noder på den samme tid. For at undgå dette kan du bruge single-master opsætningsmetode:

Fra dokumentationen,

For at slappe af flowkontrol kan du bruge indstillingerne nedenfor:

wsrep_provider_options = "gcs.fc_limit = 256; gcs.fc_factor = 0.99; gcs.fc_master_slave = YES" 

Ovenstående kræver genstart af serveren, da fc_master_slave ikke er dynamisk.

Aktiver fejlretningstilstand for logningskonflikter eller dødvande

Fejlretning eller sporing af problemer med din Galera Cluster er meget vigtig. Låse i Galera er implementeret anderledes sammenlignet med MySQL-replikering. Den bruger optimistisk låsning, når den håndterer transaktioner i hele klyngen. I modsætning til MySQL-replikeringen har den kun pessimistisk låsning, som ikke ved, om der er en sådan samme eller modstridende transaktion, der udføres i en co-master på en multi-master opsætning. Galera bruger stadig pessimistisk låsning, men på den lokale node, da den administreres af InnoDB, som er den understøttede lagermotor. Galera bruger optimistisk låsning, når den går til andre noder. Det betyder, at der ikke foretages kontrol med andre noder på klyngen, når lokale låse er opnået (pessimistisk låsning). Galera antager, at når transaktionen passerer commit-fasen i lagermotoren, og de andre noder er informeret, vil alt være okay, og der vil ikke opstå konflikter.

I praksis er det bedst at aktivere wsrep_logs_conflicts. Dette vil logge detaljerne om modstridende MDL samt InnoDB-låse i klyngen. Aktivering af denne variabel kan indstilles dynamisk, men tag forbehold, når dette er aktiveret. Det vil udfylde din fejllogfil og kan fylde din disk, når din fejllogfil er for stor.

Vær forsigtig med dine DDL-forespørgsler

I modsætning til MySQL-replikering kan kørsel af en ALTER-sætning kun påvirke indgående forbindelser, der kræver adgang til eller reference til den tabel, som din ALTER-sætning er målrettet mod. Det kan også påvirke slaver, hvis bordet er stort og kan bringe slavelag. Skrivninger til din master vil dog ikke blive blokeret, så længe dine forespørgsler ikke er i konflikt med den aktuelle ALTER. Dette er dog slet ikke tilfældet, når du kører dine DDL-sætninger såsom ALTER med Galera Cluster. ALTER-sætninger kan medføre problemer, som f.eks. Galera Cluster, der sidder fast på grund af klyngedækkende låsning, eller flowkontrol begynder at lempe replikationen, mens nogle noder er ved at komme sig efter store skrivninger.

I nogle situationer kan du ende med at have nedetid til din Galera Cluster, hvis denne tabel er for stor og er en primær og vital tabel for din applikation. Det kan dog opnås uden nedetid. Som Rick James påpegede i sin blog, kan du følge anbefalingerne nedenfor:

RSU vs TOI

• Opgradering af rullende skema =lav manuelt én node (offline) ad gangen
• Total Order Isolation =Galera synkroniserer, så det udføres på samme tid (i replikeringssekvensen) på alle noder. RSU og TOI

Forsigtig:Da der ikke er nogen måde at synkronisere klienterne med DDL, skal du sikre dig, at klienterne er tilfredse med enten det gamle eller det nye skema. Ellers bliver du sandsynligvis nødt til at fjerne hele klyngen, mens du samtidig skifter over både skemaet og klientkoden.

En "hurtig" DDL kan lige så godt udføres via TOI. Dette er en foreløbig liste over sådanne:

• OPRET/SLIP/OMDØV DATABASE/TABEL
• ÆNDRING for at ændre STANDARD
• ÆNDRING for at ændre definitionen af ​​ENUM eller SET (se forbehold i manualen)
• Visse PARTITIONSÆNDRINGER, der er hurtige.
• DROP INDEX (bortset fra PRIMÆR NØGLE)
• TILFØJ INDEKS?
• Andre ÆNDRINGER på 'små' tabeller.
• Med 5.6 og især 5.7, der har mange ALTER ALGORITHM=INPLACE-sager, skal du kontrollere, hvilke ALTERs der skal udføres på hvilken måde.

Ellers brug RSU. Gør følgende separat for hver node:

SET GLOBAL wsrep_OSU_method='RSU'; 

Dette tager også noden ud af klyngen.

ALTER TABLE
SET GLOBAL wsrep_OSU_method='TOI'; 

Sættes ind igen, hvilket fører til resynkronisering (forhåbentlig en hurtig IST, ikke en langsom SST)

Bevar din klynges konsistens

Galera Cluster understøtter ikke replikeringsfiltre såsom binlog_do_db eller binlog_ignore_db, da Galera ikke er afhængig af binær logning. Den er afhængig af ringbufferfilen også kaldet GCache, som gemmer skrivesæt, der replikeres langs klyngen. Du kan ikke anvende nogen inkonsekvent adfærd eller tilstand af sådanne databasenoder.

Galera implementerer på den anden side strengt datakonsistens i klyngen. Det er stadig muligt, at der kan være inkonsekvens, hvor rækker eller poster ikke kan findes. For eksempel kan indstilling af din variabel wsrep_OSU_method enten RSU eller TOI for dine DDL ALTER-sætninger medføre inkonsekvent adfærd. Tjek denne eksterne blog fra Percona, der diskuterer inkonsekvens med Galera med TOI vs RSU.

Indstilling af wsrep_on=OFF og efterfølgende kørsel af DML- eller DDL-forespørgsler kan være farligt for din klynge. Du skal også gennemgå dine lagrede procedurer, triggere, funktioner, hændelser eller visninger, hvis resultaterne ikke er afhængige af en nodes tilstand eller miljø. Når en eller flere bestemte noder kan være inkonsekvente, kan det potentielt få hele klyngen til at gå ned. Når Galera opdager en inkonsekvent adfærd, vil Galera forsøge at forlade klyngen og afslutte den node. Derfor er det muligt, at alle noderne kan være inkonsekvente, hvilket efterlader dig i en tilstand af dilemma.

Hvis en Galera Cluster-node også oplever et nedbrud, især i en periode med høj trafik, er det bedre ikke at starte noden med det samme. Udfør i stedet en fuld SST eller medbring en ny instans så hurtigt som muligt, eller når trafikken er lav. Det kan være muligt, at node kan bringe inkonsekvent adfærd, som kan have beskadiget data.

Segreger store transaktioner, og afgør, om der skal bruges streamingreplikering 

Lad os tage fat på denne. En af de største ændringer, især på Galera Cluster 4.0, er streaming-replikeringen. Tidligere versioner af Galera Cluster 4.0 begrænser transaktioner <2GiB, som typisk styres af variablerne wsrep_max_ws_rows og wsrep_max_ws_size. Siden Galera Cluster 4.0 kan du sende> 2GiB af transaktioner, men du skal bestemme, hvor store fragmenterne skal behandles under replikering. Det skal indstilles efter session, og de eneste variabler, du skal passe på, er wsrep_trx_fragment_unit og wsrep_trx_fragment_size. Det er nemt at deaktivere streamingreplikeringen, da indstilling af wsrep_trx_fragment_size = 0 vil gøre det. Vær opmærksom på, at replikering af en stor transaktion også har overhead på slaveknuderne (noder, der replikerer mod den aktuelle aktive-skriver/master-knude), da logfiler vil blive skrevet til wsrep_streaming_log-tabellen i MySQL-databasen.

En anden ting at tilføje, da du har at gøre med store transaktioner, er det betydeligt, at din transaktion kan tage noget tid at afslutte, så indstilling af variablen innodb_lock_wait_timeout høj skal tages i betragtning. Indstil dette via session afhængigt af den tid, du estimerer, men længere end den tid, du estimerer, at den er færdig, ellers hæver en timeout.

Vi anbefaler, at du læser denne tidligere blog om streamingreplikering i aktion.

Replikere GRANTs-erklæringer

Hvis du bruger GRANTs og relaterede operationer, skal du handle på MyISAM/Aria-tabellerne i databasen `mysql`. GRANT-udsagn bliver replikeret, men de underliggende tabeller vil ikke. Så det betyder, INSERT INTO mysql.user ... ikke vil blive replikeret, fordi tabellen er MyISAM.

Ovenstående er dog muligvis ikke sandt længere, eftersom Percona XtraDB Cluster(PXC) 8.0 (aktuelt eksperimentelt), da mysql-skematabeller er blevet konverteret til InnoDB, mens nogle af tabellerne i MariaDB 10.4 stadig er i Aria-format, men andre er i CSV eller InnoDB. Du bør bestemme, hvilken version og udbyder af Galera du har, men bedst at undgå at bruge DML-sætninger, der refererer til mysql-skemaet. Ellers kan du ende med uventede resultater, medmindre du er sikker på, at dette er PXC 8.0.

XA-transaktioner, LÅS/OPLÅS TABELLER, GET_LOCK/RELEASE_LOCK understøttes ikke

Galera Cluster understøtter ikke XA-transaktioner, da XA-transaktioner håndterer tilbagerulning og forpligter sig anderledes. LOCK/UNLOCK- eller GET_LOCK/RELEASE_LOCK-sætninger er farlige at blive anvendt eller brugt med Galera. Du kan opleve et styrt eller låse, der ikke kan dræbes og forbliver låst. For eksempel,