Replikering i MySQL har eksisteret i lang tid og er blevet støt forbedret gennem årene. Det har mere lignet evolution end revolution. Dette er helt forståeligt, da replikering er en vigtig egenskab, som mange er afhængige af - den skal virke.
I de sidste MySQL-versioner har vi set forbedringer i replikeringsydeevne gennem understøttelse af parallelanvendelse af transaktioner. I MySQL 5.6 blev parallelisering udført på skemaniveau - alle transaktioner, der er blevet udført i separate skemaer, kunne udføres på én gang. Dette var en god forbedring for de arbejdsbelastninger, der havde flere skemaer på en enkelt server, og belastningen blev fordelt mere eller mindre jævnt på tværs af skemaerne.
I MySQL 5.7 blev der tilføjet en anden paralleliseringsmetode, såkaldt "logisk ur". Det gjorde det muligt at få en vis grad af samtidighed på en slave, selvom alle dine data er blevet gemt i et enkelt skema. Det var kort sagt baseret på det faktum, at nogle transaktioner ville forpligte sig sammen på grund af en forsinkelse tilføjet af hardware. Du kan endda tilføje denne latency manuelt for at opnå bedre parallelisering på slaverne ved hjælp af binlog_group_commit_sync_delay.
Denne løsning var rigtig fin, men ikke uden ulemper. Enhver forsinkelse i udførelsen af en transaktion kan i sidste ende påvirke brugervendte dele af applikationen. Selvfølgelig kan du indstille forsinkelser inden for et interval på adskillige millisekunder, men selv da er det ekstra forsinkelse, der bremser appen.
Forbedringer af replikeringsydelse i MySQL 8.0
MySQL 8.0, som fra nu af (august 2017) stadig er i betatilstand, bringer nogle gode forbedringer til replikering. Oprindeligt blev det udviklet til gruppereplikering (GR), men da GR bruger almindelig replikering under hætten, havde "normal" MySQL-replikering fordel af det. Den forbedring, vi nævnte, er afhængighedssporingsoplysninger gemt i den binære log. Hvad der sker er, at MySQL 8.0 nu har en måde at gemme information om, hvilke rækker der blev påvirket af en given transaktion (såkaldt skrivesæt), og den sammenligner skrivesæt fra forskellige transaktioner. Dette gør det muligt at identificere de transaktioner, der ikke fungerede på den samme delmængde af rækker, og disse kan derfor anvendes parallelt. Dette kan give mulighed for at øge paralleliseringsniveauet flere gange sammenlignet med implementeringen fra MySQL 5.7. Hvad du skal huske på er, at en slave i sidste ende vil se en anden visning af dataene, en som aldrig dukkede op på masteren. Dette skyldes, at transaktioner kan blive anvendt i en anden rækkefølge end på masteren. Dette burde dog ikke være et problem. Den aktuelle implementering af multithreaded-replikering i MySQL 5.7 kan også forårsage dette problem, medmindre du udtrykkeligt aktiverer slave-preserve-commit-order.
For at kontrollere denne nye adfærd, en variabel binlog_transaction_dependency_tracking er blevet indført. Det kan tage tre værdier:
- COMMIT_ORDER:dette er standarden, den bruger standardmekanismen, der er tilgængelig i MySQL 5.7.
- WRITESET:Det muliggør bedre parallelisering, og masteren begynder at gemme skrivesætdata i binær log.
- WRITESET_SESSION:Dette sikrer, at transaktioner vil blive udført på slaven i rækkefølge, og problemet med en slave, der ser en databasetilstand, som aldrig er set på masteren, er elimineret. Det reducerer parallelisering, men det kan stadig give bedre gennemløb end standardindstillingerne.
Benchmark
I juli skrev Vitor Oliveira på mysqlhighavailability.com et indlæg, hvor han forsøgte at måle ydeevnen af nye tilstande. Han brugte det bedste scenario - ingen holdbarhed overhovedet, for at vise forskellen mellem gamle og nye tilstande. Vi besluttede at bruge den samme tilgang, denne gang i en mere virkelighedsnær opsætning:binær log aktiveret med log_slave_updates. Holdbarhedsindstillinger blev overladt til standard (så sync_binlog=1 - det er ny standard i MySQL 8.0, dobbeltskrivningsbuffer aktiveret, InnoDB kontrolsummer aktiveret osv.) Eneste undtagelse i holdbarhed var innodb_flush_log_at_trx_commit sat til 2.
Vi brugte m4.2xl-instanser, 32G, 8 kerner (så slave_parallel_workers blev sat til 8). Vi brugte også sysbench, oltp_read_write.lua script. 16 millioner rækker i 32 tabeller blev gemt på 1000 GB gp2-volumen (det er 3000 IOPS). Vi testede ydeevnen af alle tilstande for 1, 2, 4, 8, 16 og 32 samtidige sysbench-forbindelser. Processen var som følger:stop slave, udfør 100.000 transaktioner, start slave og beregn, hvor lang tid det tager at rydde slaveforsinkelsen.
Først og fremmest ved vi ikke rigtig, hvad der skete, da sysbench kun blev udført med 1 tråd. Hver test blev udført fem gange efter et opvarmningsløb. Denne særlige konfiguration blev testet to gange - resultaterne er stabile:enkelttrådet arbejdsbelastning var den hurtigste. Vi vil undersøge det nærmere for at forstå, hvad der skete.
Bortset fra det er resten af resultaterne på linje med det, vi forventede. COMMIT_ORDER er den langsomste, især for lav trafik, 2-8 tråde. WRITESET_SESSION klarer sig typisk bedre end COMMIT_ORDER, men den er langsommere end WRITESET for lav samtidig trafik.
Hvordan kan det hjælpe mig?
Den første fordel er indlysende:Hvis din arbejdsbyrde er på den langsomme side, men alligevel har dine slaver en tendens til at falde tilbage i replikering, kan de drage fordel af forbedret replikeringsydeevne, så snart masteren vil blive opgraderet til 8.0. To bemærkninger her:For det første - denne funktion er bagudkompatibel, og 5.7-slaver kan også drage fordel af den. For det andet - en påmindelse om, at 8.0 stadig er i beta-tilstand, vi opfordrer dig ikke til at bruge beta-software i produktionen, selvom det er et hårdt behov, er dette en mulighed for at teste. Denne funktion kan hjælpe dig, ikke kun når dine slaver halter. De kan være helt indhentet, men når du opretter en ny slave eller omproviserer eksisterende, vil den slave halte. At have mulighed for at bruge "WRITESET"-tilstand vil gøre processen med at klargøre en ny vært meget hurtigere.
Alt i alt vil denne funktion have meget større effekt, end du måske tror. I betragtning af alle de benchmarks, der viser regressioner i ydeevne, når MySQL håndterer trafik med lav samtidighed, er alt, hvad der kan hjælpe med at fremskynde replikeringen i sådanne miljøer, en enorm forbedring.
Hvis du bruger mellemmastere, er dette også en funktion, du skal kigge efter. Enhver mellemliggende master tilføjer en vis serialisering til, hvordan transaktioner håndteres og udføres - i den virkelige verden vil arbejdsbyrden på en mellemliggende master næsten altid være mindre parallel end på masteren. Brug af skrivesæt til at tillade bedre parallelisering forbedrer ikke kun parallelisering på den mellemliggende master, men det kan også forbedre parallelisering på alle dens slaver. Det er endda muligt (selvom det ville kræve seriøs test for at verificere, at alle dele passer korrekt) at bruge en 8.0 mellemmaster til at forbedre replikeringsydelsen af dine slaver (husk venligst, at MySQL 5.7-slave kan forstå skrivesætdata og bruge det, selvom det kan ikke generere det på egen hånd). Selvfølgelig lyder det ret vanskeligt at replikere fra 8.0 til 5.7 (og det er ikke kun fordi 8.0 stadig er beta). Under nogle omstændigheder kan dette virke og kan fremskynde CPU-udnyttelsen på dine 5.7-slaver.
Andre ændringer i MySQL-replikering
Introduktion af skrivesæt, selvom det er det mest interessante, er det ikke den eneste ændring, der skete med MySQL-replikering i MySQL 8.0. Lad os gennemgå nogle andre, også vigtige ændringer. Hvis du tilfældigvis bruger en master, der er ældre end MySQL 5.0, understøtter 8.0 ikke dets binære logformat. Vi forventer ikke at se mange sådanne opsætninger, men hvis du bruger en meget gammel MySQL med replikering, er det bestemt tid til at opgradere.
Standardværdierne er ændret for at sikre, at replikering er så nedbrudssikker som muligt:master_info_repository og relay_log_info_repository er sat til TABEL. Udløbslog_dage er også blevet ændret - nu er standardværdien 30. Ud over expire_log_days , en ny variabel er blevet tilføjet, binlog_expire_log_seconds , som giver mulighed for en mere finmasket binlog-rotationspolitik. Nogle ekstra tidsstempler er blevet tilføjet til den binære log for at forbedre observerbarheden af replikationsforsinkelse, hvilket introducerer mikrosekundgranularitet.
Dette er i hvert fald ikke en komplet liste over ændringer og funktioner relateret til MySQL-replikering. Hvis du gerne vil vide mere, kan du tjekke MySQL changelogs. Sørg for, at du har gennemgået dem alle - indtil videre er funktioner blevet tilføjet i alle 8.0-versioner.
Som du kan se, ændrer MySQL-replikering sig stadig og bliver bedre. Som vi sagde i begyndelsen, skal det være en langsommelig proces, men det er virkelig fantastisk at se, hvad der er forude. Det er også rart at se arbejdet med gruppereplikering sive ned og genbruges i den "almindelige" MySQL-replikering.