Zagadnienia dotyczące integralności danych i wydajności w półsynchronicznej replikacji MySQL

Półsynchroniczna replikacja MySQL zapewnia lepszą integralność danych, ponieważ gdy zatwierdzenie powraca pomyślnie, wiadomo, że dane znajdują się w co najmniej dwóch miejscach – głównym i podrzędnym. W tym poście na blogu omówimy niektóre konfiguracje hostingu MySQL, które wpływają na integralność danych i aspekty wydajności replikacji półsynchronicznej. Będziemy używać silnika pamięci masowej InnoDB i replikacji opartej na GTID w zestawie replik składającym się z 3 węzłów (główne i 2 podrzędne), co zapewni nadmiarowość w podrzędnych. Oznacza to, że jeśli wystąpią problemy z jednym niewolnikiem, możemy skorzystać z drugiego.

Konfiguracje mające zastosowanie do węzłów nadrzędnych i podrzędnych

• innodb_flust_log_at_trx_commit =1
• sync_binlog =1

Konfiguracje te gwarantują wysoką trwałość i spójność ustawień danych. Oznacza to, że każda zatwierdzona transakcja ma gwarancję obecności w dziennikach binarnych, a także dzienniki są opróżniane na dysk. Dlatego w przypadku awarii zasilania lub awarii systemu operacyjnego spójność danych MySQL jest zawsze zachowana.

Konfiguracje w węźle głównym.

• rpl_semi_sync_master_wait_for_slave_count:

Ta opcja jest używana do konfiguracji liczby urządzeń podrzędnych, które muszą wysłać potwierdzenie, zanim semisynchroniczny master będzie mógł zatwierdzić transakcję. W zestawie replik z 3 węzłami zalecamy ustawienie tej wartości na 1, aby zawsze mieć pewność, że dane są dostępne w co najmniej jednym urządzeniu podrzędnym, unikając jednocześnie wpływu na wydajność związanego z oczekiwaniem na potwierdzenie od obu urządzeń podrzędnych.

• rpl_semi_sync_master_timeout:

Ta opcja jest używana do konfiguracji czasu, przez który półsynchroniczny master czeka na potwierdzenie urządzenia slave przed przełączeniem z powrotem do trybu asynchronicznego. Zalecamy ustawienie dużej liczby, aby nie było powrotu do trybu asynchronicznego, który następnie narusza nasz cel integralności danych. Ponieważ pracujemy z 2 urządzeniami podrzędnymi, a rpl_semi_sync_master_wait_for_slave_count jest ustawione na 1, możemy założyć, że co najmniej jedno urządzenie podrzędne potwierdza w rozsądnym czasie, minimalizując w ten sposób wpływ tego ustawienia na wydajność.

Konfiguracje na węzłach podrzędnych

W urządzeniach podrzędnych zawsze ważne jest bardzo dokładne śledzenie dwóch pozycji:aktualnej pozycji wykonywanego wątku SQL w dzienniku przekaźnika oraz aktualnej pozycji wątku we/wy, która wskazuje, jak daleko plik binarny mater jest odczytywany i kopiowany do slave'a. Konsekwencje nieutrzymania tych pozycji są dość oczywiste. Jeśli nastąpi awaria urządzenia podrzędnego i ponowne uruchomienie, wątek SQL może rozpocząć przetwarzanie transakcji od niewłaściwego przesunięcia lub wątek IO może zacząć pobierać dane z niewłaściwej pozycji w głównych dziennikach binarnych. Oba te przypadki doprowadzą do uszkodzenia danych.

ważne jest zapewnienie bezpieczeństwa w przypadku awarii urządzeń podrzędnych poprzez następujące konfiguracje:

• relay_log_info_repository =TABELA
• relay_log_recovery =WŁ

Ustawienie relay_log_info_repository na TABLE zapewni, że pozycja wątku SQL będzie aktualizowana wraz z każdym zatwierdzeniem transakcji na urządzeniu podrzędnym. Jednak trudno jest utrzymać dokładną pozycję wątku IO i zrównać się z dyskiem. Dzieje się tak, ponieważ odczytywanie głównego dziennika binarnego i zapisywanie do dziennika przekaźnika podrzędnego nie jest oparte na transakcjach. Wpływ na wydajność jest bardzo duży, jeśli pozycja wątku we/wy musi zostać zaktualizowana i opróżniona na dysk po każdym zapisie w dziennikach przekaźnika podrzędnego. Bardziej eleganckim rozwiązaniem byłoby ustawienie relay_log_recovery =ON, w którym to przypadku, jeśli nastąpi restart MySQL, bieżące logi przekaźnika zostaną uznane za uszkodzone i zostaną świeżo ściągnięte z mastera na podstawie pozycji wątku SQL.

Ostatnie, ale nie mniej ważne, należy zauważyć, że replikacja półsynchroniczna zapewnia, że ​​dane właśnie „dotarły” do jednego z urządzeń podrzędnych przed zatwierdzeniem transakcji przez mastera i nie oznacza, że transakcje są dokonywane na niewolniku. Dlatego dobrze będzie upewnić się, że wątek SQL działa z dobrą wydajnością. W idealnym przypadku wątek SQL porusza się w parze z wątkiem IO, dzięki czemu możemy czerpać korzyść z tego, że slave nie tylko otrzymuje transakcje, ale także je zatwierdza. Zaleca się korzystanie z wielowątkowej konfiguracji podrzędnej, dzięki czemu możemy uzyskać zwiększoną wydajność wątków podrzędnych SQL. Ważne konfiguracje dla wielowątkowych urządzeń podrzędnych to:

• slave_parallel_workers : ustaw to na> 1, aby włączyć wiele podrzędnych procesów roboczych wątków SQL. W oparciu o liczbę wątków piszących na masterze, możemy określić optymalną liczbę, aby slave nie pozostawał w tyle.
• slave-parallel-type =ZEGAR_LOGICZNY
• zachowanie-zachowania-zachowania-niewolnika =1

Powyższe konfiguracje obiecują równoległość w urządzeniu podrzędnym, jednocześnie zachowując kolejność transakcji widzianą na urządzeniu głównym.

Podsumowując, używając powyższych konfiguracji w naszym zestawie replik MySQL, jesteśmy w stanie utrzymać wysoką integralność danych wraz z optymalną wydajnością.

Jak zawsze, jeśli masz jakieś pytania, zostaw nam komentarz, skontaktuj się z nami pod adresem @scalegridio na Twitterze lub wyślij nam e-mail na support @scalegrid.io.