GTID lub Globalny identyfikator transakcji został wprowadzony w MySQL 5.6.5. GTID to globalnie unikalny identyfikator nadawany wszystkim transakcjom wykonywanym na serwerze hostingowym MySQL obsługującym GTID. GTID są kombinacją identyfikatora UUID serwera, na którym dana transakcja została zatwierdzona, oraz numeru sekwencyjnego tej transakcji na tym konkretnym serwerze. To sprawia, że ​​GTID jest globalnie wyjątkowy.

Replikacja MySQL

Replikacja oparta na GTID jest znacznie bardziej elastyczna w porównaniu do starszej replikacji opartej na dzienniku binlog. W konfiguracji opartej na GTID urządzenie podrzędne nie potrzebuje głównego pliku dziennika binarnego ani pozycji, aby rozpocząć replikację. Przeczytaj więcej o replikacji opartej na GTID. W tym poście na blogu omówimy niektóre typowe problemy z replikacją MySQL, które występują podczas wdrażania zestawu replik opartego na GTID.

Błędne transakcje to transakcje, które są stosowane do jednego lub więcej urządzeń podrzędnych, które nie muszą być replikowane na innych węzłach. Mogą to być sporadyczne poprawki zastosowane na urządzeniu podrzędnym lub przypadkowe zapisy do urządzenia podrzędnego przez aplikację.

Problem z tymi błędnymi transakcjami pojawia się, gdy urządzenie podrzędne, które zawiera błędną transakcję, jest promowane do statusu master. W przypadku replikacji opartej na GTID spowodowałoby to problem. Nowy pan zdaje sobie teraz sprawę, że niewolnicy nie wykonali błędnej transakcji. Może się zdarzyć jedna z dwóch rzeczy:

(1) Błędna transakcja jest nadal obecna w logu administratora i wyśle ​​ją do urządzeń podrzędnych, co może uszkodzić dane lub spowodować błąd.
(2) Transakcja nie jest obecna w logu binarnym, a co za tym idzie nie można przesłać do urządzenia podrzędnego, co powoduje błąd replikacji.

Zapobieganie

Błędnym transakcjom można aktywnie zapobiegać, wykonując te czynności. Jeśli musisz zastosować poprawkę do urządzenia podrzędnego, jednym ze sposobów złagodzenia błędnych transakcji jest tymczasowe wyłączenie logowania binarnego na urządzeniu podrzędnym. Wykonanie polecenia sql_bin_log =0 przed wykonaniem błędnego zapytania powinno załatwić sprawę. Możesz później włączyć binlog, uruchamiając sql_bin_log =1. Aby uniemożliwić jakiejkolwiek aplikacji zapis do urządzeń podrzędnych, opcja Tylko do odczytu powinna być włączona na serwerze skonfigurowanym jako podrzędny.

Wykrywanie

Wykrycie błędnej transakcji w zestawie replik MySQL opartych na GTID jest łatwe. MySQL przechowuje wszystkie wykonane identyfikatory GTID w swojej tabeli Performance Schema/Information Schema na podstawie używanej wersji MySQL. Odebranie identyfikatorów GTID bieżącego urządzenia podrzędnego i odjęcie ich od identyfikatorów GTID wykonanych na bieżącym urządzeniu głównym powinno dać wszystkie błędne transakcje na tym konkretnym urządzeniu podrzędnym. Narzędzia takie jak mysqlfailover lub mysqlrpladmin mogą również pomóc w wykrywaniu błędnych transakcji.

Rozwiązanie

Po wykryciu błędnej transakcji istnieją dwa sposoby naprawienia błędów replikacji spowodowanych przełączeniem awaryjnym. Jednym ze sposobów jest usunięcie identyfikatora GTID błędnej transakcji z historii wykonania identyfikatora GTID urządzenia podrzędnego. W ten sposób, gdy slave zostanie awansowany na mastera, błędna transakcja nie zostanie zreplikowana do wszystkich węzłów. Innym sposobem obsługi błędnych transakcji jest powiedzenie wszystkim innym niewolnikom, aby pominęli błędną transakcję. Obejmuje to wstawienie pustej transakcji z tym samym GTID, co błędna transakcja, do wszystkich innych węzłów w zestawie replik. To sprawi, że wszystkie inne węzły pomyślą, że już zastosowały tę transakcję i dlatego ją pominą. MySQL ma narzędzie o nazwie Mysqlslavetrx przeznaczone do tego celu. To narzędzie może służyć do wstawiania pustych transakcji o podanym GTID. Dodanie pustych transakcji może mieć również inne zastosowania, jak omówiono tutaj.