GTID of Algemene transactie-ID werd geïntroduceerd in MySQL 5.6.5. Een GTID is een wereldwijd unieke id die wordt gegeven aan alle transacties die worden uitgevoerd op een voor GTID geschikte MySQL-hostingserver. GTID's zijn een combinatie van de UUID van de server waar een bepaalde transactie is uitgevoerd, en het volgnummer van die transactie op die bepaalde server. Dit maakt de GTID's wereldwijd uniek.

MySQL-replicatie

Op GTID gebaseerde replicatie is veel flexibeler in vergelijking met de oudere op binlog gebaseerde replicatie. In een op GTID gebaseerde setup heeft de slave geen master binlog-bestand en positie nodig om de replicatie te starten. Lees meer over op GTID gebaseerde replicatie. In deze blogpost bespreken we enkele veelvoorkomende MySQL-replicatieproblemen die worden veroorzaakt bij het implementeren van een op GTID gebaseerde replicaset.

Foutieve transacties zijn transacties die worden toegepast op een of meer slaves die niet hoeven te worden gerepliceerd op andere nodes. Dit kunnen intermitterende fixes zijn die op de slave worden toegepast, of onbedoelde schrijfacties naar de slave door een toepassing.

Het probleem met deze foutieve transacties ontstaat wanneer de slaaf die een foutieve transactie bevat, wordt gepromoveerd tot master. In het geval van op GTID gebaseerde replicatie zou dit een probleem veroorzaken. De nieuwe master realiseert zich nu dat slaves de foutieve transactie niet hebben uitgevoerd. Er kunnen twee dingen gebeuren:

(1) De foutieve transactie is nog steeds aanwezig in de binlog van de master en zal deze naar de slaves sturen, dit kan de data beschadigen of een fout veroorzaken.
(2) De transactie is niet aanwezig in de binlog, en daarom kan niet naar de slave worden verzonden, wat een replicatiefout veroorzaakt.

Preventie

Foutieve transacties kunnen actief worden voorkomen door deze stappen te volgen. Als u een oplossing moet toepassen op een slave, kunt u foutieve transacties ondervangen door tijdelijk binaire logboekregistratie op de slave uit te schakelen. Het uitvoeren van sql_bin_log =0 voordat de foutieve query wordt uitgevoerd, zou voldoende moeten zijn. U kunt binlog later inschakelen door sql_bin_log =1 uit te voeren. Om te voorkomen dat toepassingen naar slaves schrijven, moet alleen-lezen worden ingeschakeld op een server wanneer deze is geconfigureerd als een slave.

Detectie

Het detecteren van een foutieve transactie in een op GTID gebaseerde MySQL-replicaset is eenvoudig. MySQL slaat alle uitgevoerde GTID's op in de Performance Schema/Information Schema-tabel op basis van de versie van MySQL die u gebruikt. Door de door de huidige slave uitgevoerde GTID's te nemen en deze af te trekken van de GTID's die zijn uitgevoerd op de huidige master, zou u alle foutieve transacties op die specifieke slave moeten krijgen. Hulpprogramma's zoals mysqlfailover of mysqlrpladmin kunnen ook helpen bij het opsporen van foutieve transacties.

Oplossing

Zodra een foutieve transactie is gedetecteerd, zijn er twee manieren waarop u de replicatiefouten kunt herstellen die na een failover zijn veroorzaakt. Eén manier is om de GTID van de foutieve transactie te verwijderen uit de uitgevoerde slave-GTID-geschiedenis. Op deze manier, wanneer de slaaf wordt gepromoveerd tot de meester, wordt de foutieve transactie niet naar alle knooppunten gerepliceerd. Een andere manier om een ​​foutieve transactie af te handelen, is door alle andere slaven te vertellen dat ze de foutieve transactie moeten overslaan. Dat omvat het invoegen van een lege transactie met dezelfde GTID als de foutieve transactie naar alle andere knooppunten in de replicaset. Hierdoor zullen alle andere knooppunten denken dat ze deze transactie al hebben toegepast en deze daarom overslaan. MySQL heeft een hulpprogramma genaamd Mysqlslavetrx speciaal hiervoor. Dit hulpprogramma kan worden gebruikt om lege transacties in te voegen met de opgegeven GTID. Het toevoegen van lege transacties kan ook andere toepassingen hebben, zoals hier besproken.