GTID eller Global Transaction Identifier introducerades i MySQL 5.6.5. Ett GTID är ett globalt unikt ID som ges till alla transaktioner som utförs på en GTID-aktiverad MySQL-värdserver. GTID är en kombination av UUID för servern där en viss transaktion har begåtts, och sekvensnumret för den transaktionen på den specifika servern. Detta gör GTID:erna globalt unika.
MySQL-replikering
GTID-baserad replikering är mycket mer flexibel jämfört med den äldre binlog-baserade replikeringen. I en GTID-baserad installation behöver inte slaven en master binlog-fil och position för att starta replikering. Läs mer om GTID-baserad replikering. I det här blogginlägget kommer vi att diskutera några vanliga MySQL-replikeringsproblem som orsakas när en GTID-baserad replikuppsättning distribueras.
Felaktiga transaktioner är transaktioner som tillämpas på en eller flera slavar som inte behöver replikeras på andra noder. Dessa kan vara intermittenta fixar som tillämpas på slaven eller oavsiktliga skrivningar till slaven av en applikation.
Problemet med dessa felaktiga transaktioner uppstår när slaven som innehåller en felaktig transaktion befordras till master. I fallet med GTID-baserad replikering skulle detta orsaka ett problem. Den nya mästaren inser nu att slavar inte har utfört den felaktiga transaktionen. En av två saker kan hända:
(1) Den felaktiga transaktionen finns fortfarande i masterns binlog och den kommer att skicka den till slavarna, detta kan korrumpera data eller orsaka ett fel.
(2) Transaktionen finns inte i binloggen, och därför kan inte skickas över till slaven, vilket orsakar ett replikeringsfel.
Förebyggande
Felaktiga transaktioner kan aktivt förhindras genom att följa dessa steg. Om du måste tillämpa en fix på en slav är ett sätt att mildra felaktiga transaktioner genom att tillfälligt stänga av binär inloggning på slaven. Att köra sql_bin_log =0 innan den felaktiga frågan körs borde göra susen. Du kan senare aktivera binlog genom att köra sql_bin_log =1. För att förhindra att applikationer skriver till slavar bör skrivskyddad vara aktiverad på en server när den är konfigurerad som en slav.
Detektering
Det är enkelt att upptäcka en felaktig transaktion i en GTID-baserad MySQL-replika. MySQL lagrar alla exekverade GTID i dess Performance Schema/Information Schema-tabell baserat på vilken version MySQL du använder. Om du tar den nuvarande slavens exekverade GTID och subtraherar dem från GTID:n som körs på den aktuella mastern bör du ge dig alla felaktiga transaktioner på just den slaven. Verktyg som mysqlfailover eller mysqlrpladmin kan också hjälpa till att upptäcka felaktiga transaktioner.
Lösning
När en felaktig transaktion har upptäckts finns det två sätt du kan åtgärda replikeringsfelen som orsakas efter en failover. Ett sätt är att ta bort GTID:t för den felaktiga transaktionen från den exekverade slavhistoriken för GTID. På detta sätt, när slaven blir befordrad till mastern, skulle den felaktiga transaktionen inte replikeras till alla noder. Ett annat sätt att hantera feltransaktioner är att säga åt alla andra slavar att hoppa över den felaktiga transaktionen. Det skulle inkludera att infoga en tom transaktion med samma GTID som den felaktiga transaktionen till alla andra noder i replikuppsättningen. Detta ska få alla andra noder att tro att de redan har tillämpat denna transaktion och därför hoppa över den. MySQL har ett verktyg som heter Mysqlslavetrx dedikerat för att göra detta. Detta verktyg kan användas för att infoga tomma transaktioner med det angivna GTID. Att lägga till tomma transaktioner kan också ha andra användningsområden, som diskuteras här.