I en MySQL 5.7 master-slave-opsætning, der bruger standardindstillingen for semisynkron replikering for rpl_semi_sync_master_wait_point , et nedbrud af masteren og failover til slaven anses for at være tabsfrit. Men når den styrtede master kommer tilbage, kan du opleve, at den har transaktioner, der ikke er til stede i den nuværende master (som tidligere var en slave). Denne adfærd kan være forvirrende, da semisynkron replikering formodes at være tabsfri, men dette er faktisk en forventet adfærd i MySQL. Hvorfor netop dette sker, er forklaret i detaljer i blogindlægget af Jean-François Gagné (JF).
I et sådant scenarie anbefaler MySQL-dokumentationen, at den nedbrudte master skal kasseres og ikke genstartes. Det er dog dyrt og ineffektivt at kassere en server som denne. I dette blogindlæg vil vi forklare en tilgang til at detektere og rette transaktioner på den nedbrudte MySQL-masterserver i en semisynkron replikeringsopsætning, og hvordan man gen-slaver den tilbage til din master-slave-opsætning.
Hvorfor er det vigtigt at registrere ekstra transaktioner på den gendannede master?
De ekstra transaktioner på den gendannede master kan manifestere sig på to måder:
1. MySQL-replikeringsfejl, når den gendannede master er gen-slavet
Dette sker typisk, når du har en primær nøgle med automatisk stigning. Når den nye MySQL-master indsætter en række i en sådan tabel, vil replikeringen mislykkes, fordi nøglen allerede findes på slaven.
Et andet scenario er, når din app forsøger at gentage transaktionen, der var mislykket under hovednedbrud. På den gendannede MySQL-master (som nu er en slave), ville denne transaktion faktisk eksistere, og igen resulterer det i en replikeringsfejl.
Typisk vil MySQL-replikeringsfejlen se sådan ud:
| [FEJL] Slave SQL for kanal '':Arbejder 5 kunne ikke udføre transaktionen 'fd1ba8f0-cbee-11e8- b27f-000d3a0df42d:5938858' på master log mysql-bin.000030, end_log_pos 10262184; Fejl 'Duplicate entry '5018' for nøgle 'PRIMARY'' ved forespørgsel. Standard database:'test'. Forespørgsel:'insert into test values(5018,2019,'item100')', Error_code:1062 |
2. Tavs inkonsistens i data mellem den nye MySQL-master og slave (gendannet master)
I tilfælde, hvor applikationen ikke forsøger den mislykkede transaktion igen, og der ikke er nogen primærnøglekollisioner i fremtiden, vil der muligvis ikke opstå en replikeringsfejl. Som følge heraf kan datainkonsistensen forblive uopdaget.
I begge ovenstående tilfælde påvirkes enten den høje tilgængelighed eller dataintegriteten af din MySQL-opsætning, hvorfor det er så vigtigt at opdage denne tilstand så tidligt som muligt.
Sådan registrerer du ekstra transaktioner på den gendannede MySQL-master
Vi kan registrere, om der er ekstra transaktioner på den gendannede master ved hjælp af funktionen MySQL GTID (global transaktions-id):
GTID_SUBSET(sæt1 ,sæt2 ):Givet to sæt globale transaktions-id'er sæt1 og sæt2 , returnerer sand, hvis alle GTID'er i sæt1 er også i set2 . Returnerer falsk ellers.
Lad os bruge et eksempel til at forstå dette.
- GTID indstillet på den gendannede master, hvis UUID er:'54a63bc3-d01d-11e7-bf52-000d3af93e52 ’ er:
- '54a63bc3-d01d-11e7-bf52-000d3af93e52:1-9700,57956099-d01d-11e7-80bc-000d3af97c09:1-810'
- GTID-sættet for den nye master, hvis UUID er:'57956099-d01d-11e7-80bc-000d3af97c09 ’ er:
- '54a63bc3-d01d-11e7-bf52-000d3af93e52:1-9690,57956099-d01d-11e7-80bc-0009d3af17c>
Nu, hvis vi kalder GTID_SUBSET-funktionen som GTID_SUBSET(GTID-sæt af gendannet master, GTID-sæt af ny master) , vil returværdien kun være sand, hvis den gendannede master ikke har nogen ekstra transaktioner. I vores eksempel ovenfor, da den gendannede master har ekstra transaktioner 9691 til 9700, er resultatet af ovenstående forespørgsel falsk.
Re-slaving af en crashet #MySQL-masterserver i semisynkron replikeringsopsætningKlik for at tweeteSådan genslaver du den gendannede MySQL-master, der har ekstra transaktioner
Baseret på ovenstående trin er det muligt at vide, om den gendannede master har ekstra transaktioner, og hvilke transaktioner der bruger GTID-funktionen:GTID_SUBTRACT(GTID sæt af gendannet master, GTID-sæt af ny master).
Det er også muligt at udtrække disse ekstra transaktioner fra de binære logfiler og gemme dem. Det kan være nyttigt for dit virksomhedsteam senere at gennemgå disse transaktioner for at sikre, at vi ikke ved et uheld mister vigtige forretningsoplysninger, selvom de ikke var forpligtet. Når dette er gjort, har vi brug for en måde at slippe af med disse ekstra transaktioner, så den genvundne mester kan gen-slaves uden problemer.
En af de enkleste måder at gøre dette på er at tage et backup-øjebliksbillede på den aktuelle master og gendanne dataene på din nuværende slave. Husk, at du skal beholde denne servers UUID som før. Når du har gendannet dataene, kan serveren gen-slaves, og den starter replikering fra punktet af det gendannede snapshot. Du vil snart have en sund slave kørende igen!
Trinnene ovenfor er meget kedelige, hvis du skal udføre dem manuelt, men ScaleGrids fuldt administrerede MySQL-hostingtjeneste kan automatisere hele processen for dig uden nogen form for indgriben. Sådan fungerer det:
Hvis din nuværende master går ned, automatiserer ScaleGrid failover-processen og promoverer en passende slave som den nye master. Den gamle master bliver så gendannet, og vi registrerer automatisk, hvis der er ekstra transaktioner på den. Hvis der findes nogen, sættes MySQL-implementeringen i en forringet tilstand, og vi bruger automatiserede værktøjer til at udtrække og gemme de ekstra transaktioner til din gennemgang. Vores supportteam kan derefter gendanne den gamle master til en god tilstand og gen-slave den tilbage til din master-slave-opsætning, så du får en sund implementering!
Vil du prøve det? Start en gratis 30-dages prøveperiode for at udforske alle MySQL-databasestyringsfunktionerne hos ScaleGrid.
