GTID или Глобален идентификатор на транзакция беше въведен в MySQL 5.6.5. GTID е глобално уникален идентификатор, даден на всички транзакции, изпълнявани на MySQL хостинг сървър с активиран GTID. GTID са комбинация от UUID на сървъра, където е извършена конкретна транзакция, и поредния номер на тази транзакция на този конкретен сървър. Това прави GTID глобално уникален.

Репликация на MySQL

Репликацията, базирана на GTID, е много по-гъвкава в сравнение с по-старата репликация, базирана на binlog. При настройка, базирана на GTID, подчиненият не се нуждае от главен binlog файл и позиция, за да започне репликация. Прочетете повече за репликацията, базирана на GTID. В тази публикация в блога ще обсъдим някои често срещани проблеми с репликацията на MySQL, причинени при внедряване на набор от реплика, базиран на GTID.

Грешни транзакции са транзакции, които се прилагат към един или повече подчинени устройства, които не е необходимо да бъдат репликирани на други възли. Това може да са периодични корекции, приложени към подчинения, или случайни записвания към подчинения от приложение.

Проблемът с тези грешни транзакции възниква, когато подчинения, който съдържа грешна транзакция, бъде повишен в главен. В случай на репликация, базирана на GTID, това би причинило проблем. Новият господар сега осъзнава, че подчинените не са изпълнили грешната транзакция. Може да се случи едно от двете неща:

(1) Грешната транзакция все още присъства в binlog на главния и ще я изпрати на подчинените, това може да повреди данните или да причини грешка.
(2) Транзакцията не присъства в binlog и следователно не може да бъде изпратен на подчинения, което причинява грешка при репликация.

Превенция

Грешните транзакции могат активно да бъдат предотвратени, като се следват тези стъпки. Ако трябва да приложите корекция към подчинен, един от начините за смекчаване на грешните транзакции е чрез временно изключване на двоичното регистриране на подчинено устройство. Изпълнението на sql_bin_log =0 преди изпълнението на грешната заявка трябва да свърши работа. По-късно можете да активирате binlog, като изпълните sql_bin_log =1. За да предотвратите запис на приложения в подчинени устройства, на сървъра трябва да се активира само за четене, когато е конфигуриран като подчинен.

Откриване

Откриването на грешна транзакция в базиран на GTID набор от реплики на MySQL е лесно. MySQL съхранява всички изпълнени GTID в таблицата си със схема за ефективност/информационна схема въз основа на това каква версия MySQL използвате. Вземането на изпълнените GTID на текущото подчинено устройство и изваждането им от GTID, изпълнено на текущия главен, трябва да ви даде всички грешни транзакции на този конкретен подчинен. Помощни програми като mysqlfailover или mysqlrpladmin също могат да помогнат при откриването на грешни транзакции.

Решение

След като бъде открита грешна транзакция, има два начина да коригирате грешките при репликация, причинени след отказ. Един от начините е да изтриете GTID на грешната транзакция от извършената история на подчинения GTID. По този начин, когато робът бъде повишен до главен, грешната транзакция няма да бъде репликирана на всички възли. Друг начин за обработка на грешната транзакция е да кажете на всички други подчинени устройства да пропуснат грешната транзакция. Това би включвало вмъкване на празна транзакция със същия GTID като грешната транзакция към всички останали възли в набора от реплика. Това ще накара всички останали възли да мислят, че вече са приложили тази транзакция и следователно ще я пропуснат. MySQL има помощна програма, наречена Mysqlslavetrx , предназначена за това. Тази помощна програма може да се използва за вмъкване на празни транзакции с даден GTID. Добавянето на празни транзакции може да има и други приложения, както е обсъдено тук.