I en MySQL 5.7 master-slave-installation som använder standardinställningen för semisynkron replikering för rpl_semi_sync_master_wait_point , en krasch av mastern och failover till slaven anses vara förlustfri. Men när den kraschade mastern kommer tillbaka kan du upptäcka att den har transaktioner som inte finns i den nuvarande mastern (som tidigare var en slav). Detta beteende kan vara förbryllande, med tanke på att semisynkron replikering är tänkt att vara förlustfri, men detta är faktiskt ett förväntat beteende i MySQL. Varför just detta händer förklaras i detalj i blogginlägget av Jean-François Gagné (JF).
Med tanke på ett sådant scenario rekommenderar MySQL-dokumentationen att den kraschade mastern måste kasseras och inte bör startas om. Men att kassera en server som denna är dyrt och ineffektivt. I det här blogginlägget kommer vi att förklara ett tillvägagångssätt för att upptäcka och fixa transaktioner på den kraschade MySQL-masterservern i en semisynkron replikeringsinställning, och hur man omslavar den tillbaka till din master-slave-installation.
Varför är det viktigt att upptäcka extra transaktioner på den återställda mastern?
De extra transaktionerna på den återställda mastern kan visa sig på två sätt:
1. MySQL-replikeringsfel när den återställda mastern slavas igen
Det här händer vanligtvis när du har en primärnyckel med automatisk ökning. När den nya MySQL-mastern infogar en rad i en sådan tabell kommer replikeringen att misslyckas eftersom nyckeln redan finns på slaven.
Ett annat scenario är när din app försöker igen transaktionen som misslyckades under huvudkraschen. På den återställda MySQL-mastern (som nu är en slav) skulle denna transaktion faktiskt existera och återigen resultera i ett replikeringsfel.
Vanligtvis skulle MySQL-replikeringsfelet se ut så här:
| [FEL] Slav SQL för kanal '':Arbetare 5 misslyckades med att exekvera transaktionen 'fd1ba8f0-cbee-11e8- b27f-000d3a0df42d:5938858' vid master log mysql-bin.000030, end_log_pos 10262184; Felet 'Duplicera post '5018' för nyckel 'PRIMÄR'' vid fråga. Standarddatabas:'test'. Fråga:'insert into test values(5018,2019,'item100')', Error_code:1062 |
2. Tyst inkonsekvens i data mellan den nya MySQL-mastern och slaven (återställd master)
I de fall då programmet inte försöker igen den misslyckade transaktionen och det inte förekommer några primärnyckelkollisioner i framtiden, kanske ett replikeringsfel inte uppstår. Som ett resultat kan datainkonsekvensen förbli oupptäckt.
I båda fallen ovan påverkas antingen den höga tillgängligheten eller dataintegriteten för din MySQL-installation, varför det är så viktigt att upptäcka detta tillstånd så tidigt som möjligt.
Hur man upptäcker extra transaktioner på den återställda MySQL Master
Vi kan upptäcka om det finns några extra transaktioner på den återställda mastern med funktionen MySQL GTID (global transaktionsidentifierare):
GTID_SUBSET(uppsättning1 ,set2 ):Givet två uppsättningar globala transaktions-ID:n set1 och set2 , returnerar sant om alla GTID:n i set1 finns också i set2 . Returnerar falskt annars.
Låt oss använda ett exempel för att förstå detta.
- GTID inställt på den återställda master vars UUID är:'54a63bc3-d01d-11e7-bf52-000d3af93e52 ’ är:
- '54a63bc3-d01d-11e7-bf52-000d3af93e52:1-9700,57956099-d01d-11e7-80bc-000d3af97c09:1-810’
- GTID-uppsättningen för den nya master vars UUID är:'57956099-d01d-11e7-80bc-000d3af97c09 ’ är:
- '54a63bc3-d01d-11e7-bf52-000d3af93e52:1-9690,57956099-d01d-11e7-80bc-0000d3af17c>
Om vi nu anropar GTID_SUBSET-funktionen som GTID_SUBSET(GTID-uppsättning av återställd master, GTID-uppsättning av ny master) , kommer returvärdet att vara sant, endast om den återställda mastern inte har några extra transaktioner. I vårt exempel ovan, eftersom den återställda mastern har extra transaktioner 9691 till 9700, är resultatet av ovanstående fråga falskt.
Återslava en kraschad #MySQL-masterserver i semisynkron replikeringsinställningKlicka för att tweetaHur man omslavar den återställda MySQL-mästaren som har extra transaktioner
Baserat på steget ovan är det möjligt att veta om den återställda mastern har extra transaktioner och vilka dessa transaktioner använder GTID-funktionen:GTID_SUBTRACT(GTID uppsättning av återställd master, GTID-uppsättning av ny master).
Det är också möjligt att extrahera dessa extra transaktioner från de binära loggarna och spara dem. Det kan vara användbart för ditt företagsteam att senare granska dessa transaktioner för att försäkra oss om att vi inte oavsiktligt förlorar någon viktig affärsinformation, även om den var oengagerad. När detta är gjort behöver vi ett sätt att bli av med dessa extra transaktioner så att den återställda mastern kan återslavas utan problem.
Ett av de enklaste sätten att göra detta är att ta en säkerhetskopia av den nuvarande mastern och återställa data till din nuvarande slav. Kom ihåg att du måste behålla UUID för denna server som tidigare. Efter att du har återställt data kan servern återslavas och den kommer att starta replikering från punkten för den återställda ögonblicksbilden. Du kommer snart att ha en frisk slav igång igen!
Stegen ovan är mycket tråkiga om du måste utföra dem manuellt, men ScaleGrids fullt hanterade MySQL-värdtjänst kan automatisera hela processen åt dig utan att behöva ingripa. Så här fungerar det:
Om din nuvarande master kraschar, automatiserar ScaleGrid failover-processen och marknadsför en lämplig slav som ny master. Den gamla mastern återställs sedan och vi upptäcker automatiskt om det finns extra transaktioner på den. Om några hittas försätts MySQL-distributionen i ett försämrat tillstånd och vi använder automatiserade verktyg för att extrahera och spara de extra transaktionerna för din granskning. Vårt supportteam kan sedan återställa den gamla mastern till ett bra tillstånd och återslava den till din master-slave-inställning så att du får en sund utplacering!
Vill du prova? Starta en gratis 30-dagars provperiod för att utforska alla funktioner för MySQL-databashantering på ScaleGrid.
