GTID eller Global Transaction Identifier blev introduceret i MySQL 5.6.5. Et GTID er et globalt unikt id givet til alle transaktioner, der udføres på en GTID-aktiveret MySQL-hostingserver. GTID'er er en kombination af UUID'et på den server, hvor en bestemt transaktion er blevet begået, og sekvensnummeret for den transaktion på den pågældende server. Dette gør GTID'erne globalt unikke.
MySQL-replikering
GTID-baseret replikering er meget mere fleksibel sammenlignet med den ældre binlog-baserede replikering. I en GTID-baseret opsætning behøver slaven ikke en master binlog-fil og position for at starte replikering. Læs mere om GTID-baseret replikering. I dette blogindlæg vil vi diskutere nogle almindelige MySQL-replikeringsproblemer, der forårsages ved implementering af et GTID-baseret replikasæt.
Fejlgående transaktioner er transaktioner, der anvendes på en eller flere slaver, som ikke behøver at blive replikeret på andre knudepunkter. Disse kan være intermitterende rettelser, der anvendes på slaven, eller utilsigtede skrivninger til slaven af en applikation.
Problemet med disse fejlagtige transaktioner opstår, når slaven, der indeholder en fejltransaktion, forfremmes til master. I tilfælde af GTID-baseret replikering ville dette forårsage et problem. Den nye mester indser nu, at slaver ikke har udført den fejlagtige transaktion. En af to ting kan ske:
(1) Den fejlagtige transaktion er stadig til stede i masterens binlog, og den vil sende den til slaverne, dette kan ødelægge dataene eller forårsage en fejl.
(2) Transaktionen er ikke til stede i binlogen, og derfor kan ikke sendes over til slaven, hvilket forårsager en replikeringsfejl.
Forebyggelse
Fejlgående transaktioner kan aktivt forhindres ved at følge disse trin. Hvis du skal anvende en rettelse til en slave, er en måde at afbøde fejltransaktioner ved midlertidigt at deaktivere binær logning på slaven. Udførelse af sql_bin_log =0 før udførelse af den fejlagtige forespørgsel burde gøre det trick. Du kan senere aktivere binlog ved at køre sql_bin_log =1. For at forhindre enhver applikation, der skriver til slaver, bør Read-Only være aktiveret på en server, når den er konfigureret som en slave.
Detektering
Det er nemt at opdage en fejlagtig transaktion i et GTID-baseret MySQL-replikasæt. MySQL gemmer alle udførte GTID'er i sin Performance Schema/Information Schema-tabel baseret på hvilken version MySQL du bruger. Hvis du tager den nuværende slaves udførte GTID'er og trækker dem fra de GTID'er, der udføres på den aktuelle master, burde du give dig alle fejlagtige transaktioner på den pågældende slave. Hjælpeprogrammer såsom mysqlfailover eller mysqlrpladmin kan også hjælpe med at opdage fejlagtige transaktioner.
Løsning
Når en fejltransaktion er blevet opdaget, er der to måder, hvorpå du kan rette replikeringsfejl, der er forårsaget efter en failover. En måde er at slette GTID'et for den fejlagtige transaktion fra den udførte historik for slave-GTID. På denne måde, når slaven bliver forfremmet til masteren, vil den fejlagtige transaktion ikke blive replikeret til alle noder. En anden måde at håndtere fejltransaktioner på er at fortælle alle de andre slaver om at springe den fejlagtige transaktion over. Det vil omfatte indsættelse af en tom transaktion med samme GTID som den fejlagtige transaktion til alle de andre knudepunkter i replikasættet. Dette vil få alle de andre knudepunkter til at tro, at de allerede har anvendt denne transaktion, og derfor springer den over. MySQL har et hjælpeprogram kaldet Mysqlslavetrx dedikeret til at gøre dette. Dette værktøj kan bruges til at indsætte tomme transaktioner med det givne GTID. Tilføjelse af tomme transaktioner kan også have andre formål, som diskuteret her.