Wskazówki dotyczące migracji z MySQL Replication do MySQL Galera Cluster 4.0

Wcześniej pisaliśmy na blogu o nowościach w MySQL Galera Cluster 4.0, obsłudze dużych transakcji za pomocą replikacji strumieniowej i MariaDB 10.4, a także przedstawiliśmy kilka przewodników na temat korzystania z nowej funkcji replikacji strumieniowej w części 1 i 2.

Przeniesienie technologii baz danych z MySQL Replication do MySQL Galera Cluster wymaga posiadania odpowiednich umiejętności i zrozumienia tego, co robisz, aby odnieść sukces. W tym blogu podzielimy się kilkoma wskazówkami dotyczącymi migracji z konfiguracji MySQL Replication do MySQL Galera Cluster 4.0.

Różnice między replikacją MySQL a klastrem Galera

Jeśli nie znasz jeszcze Galera, zalecamy zapoznanie się z naszym samouczkiem Galera Cluster for MySQL. Galera Cluster wykorzystuje zupełnie inny poziom replikacji opartej na replikacji synchronicznej, w przeciwieństwie do replikacji MySQL, która wykorzystuje replikację asynchroniczną (ale może być skonfigurowana również do uzyskania replikacji półsynchronicznej).

Galera Cluster obsługuje również replikację z wieloma wzorcami. Jest zdolny do nieograniczonego stosowania równoległego (tj. „replikacji równoległej”), replikacji multiemisji i automatycznego udostępniania węzłów.

Głównym celem Galera Cluster jest spójność danych, podczas gdy w przypadku replikacji MySQL jest podatna na niespójność danych (której można uniknąć dzięki najlepszym praktykom i odpowiedniej konfiguracji, takiej jak wymuszenie tylko odczytu na urządzeniach podrzędnych, aby uniknąć niechciane zapisy w niewolnikach).

Chociaż transakcje otrzymane przez Galera są albo stosowane do każdego węzła, albo wcale, każdy z tych węzłów poświadcza zreplikowany zestaw zapisu w kolejce aplikacji (zatwierdzenia transakcji), który zawiera również informacje o wszystkich blokady, które były utrzymywane przez bazę danych podczas transakcji. Te zestawy zapisu są stosowane, gdy nie zostaną zidentyfikowane sprzeczne blokady. Do tego momentu transakcje są uważane za zatwierdzone i nadal stosują je do obszaru tabel. W przeciwieństwie do replikacji asynchronicznej, to podejście jest również nazywane replikacją wirtualnie synchroniczną, ponieważ zapisy i zatwierdzenia odbywają się w logicznym trybie synchronicznym, ale faktyczne zapisywanie i zatwierdzanie w przestrzeni tabel odbywa się niezależnie i przechodzi asynchronicznie w każdym węźle.

W przeciwieństwie do MySQL Replication, Galera Cluster jest prawdziwym multi-masterem, wielowątkowym slave'em, czystym hot-standby, bez potrzeby przełączania master-failover lub dzielenia odczytu i zapisu. Jednak migracja do Galera Cluster nie oznacza automatycznej odpowiedzi na Twoje problemy. Galera Cluster obsługuje tylko InnoDB, więc mogą wystąpić modyfikacje projektu, jeśli używasz silników pamięci masowej MyISAM lub Memory.

Konwertowanie tabel spoza InnoDB na InnoDB

Galera Cluster umożliwia korzystanie z MyISAM, ale nie do tego zaprojektowano Galera Cluster. Galera Cluster jest przeznaczony do ścisłej implementacji spójności danych we wszystkich węzłach klastra, a to wymaga silnego silnika bazy danych zgodnego z ACID. InnoDB to silnik, który ma tak duże możliwości w tym obszarze i zaleca się korzystanie z InnoDB; zwłaszcza w przypadku transakcji.

Jeśli używasz ClusterControl, możesz łatwo określić instancje bazy danych dla dowolnych tabel MyISAM, które są dostarczane przez Performance Advisors. Znajdziesz to w zakładce Performance → Advisors. Na przykład

Jeśli potrzebujesz tabel MyISAM i MEMORY, nadal możesz ich używać, ale upewnij się, że Twoje dane nie wymagają replikacji. Możesz użyć swoich danych przechowywanych tylko do odczytu i użyć opcji „ROZPOCZNIJ TRANSAKCJĘ TYLKO DO ODCZYTU” w stosownych przypadkach.

Dodawanie kluczy podstawowych do tabel InnoDB

Ponieważ Galera Cluster obsługuje tylko InnoDB, bardzo ważne jest, aby wszystkie tabele miały indeks klastrowy (zwany również kluczem podstawowym lub kluczem unikalnym). Aby uzyskać najlepszą wydajność zapytań, wstawek i innych operacji na bazie danych, bardzo ważne jest zdefiniowanie każdej tabeli za pomocą unikalnych kluczy, ponieważ InnoDB używa indeksu klastrowego do optymalizacji najczęstszych operacji wyszukiwania i DML dla każdej tabeli . Pomaga to uniknąć długotrwałych zapytań w klastrze i może spowolnić operacje zapisu/odczytu w klastrze.

W ClusterControl znajdują się doradcy, którzy mogą Cię o tym powiadomić. Na przykład w klastrze master/slave MySQL Replication otrzymasz alarm z widoku lub z listy doradców. Poniższy przykładowy zrzut ekranu pokazuje, że nie masz tabel, które nie mają klucza podstawowego:

Zidentyfikuj węzeł główny (lub aktywny zapisujący)

Galera Cluster to po prostu prawdziwa replikacja z wieloma wzorcami. Nie oznacza to jednak, że możesz swobodnie napisać dowolny węzeł, na który chcesz kierować. Jedną rzeczą do zidentyfikowania jest to, że gdy zapisujesz w innym węźle i zostanie wykryta transakcja powodująca konflikt, pojawi się problem z impasem, tak jak poniżej:

2019-11-14T21:14:03.797546Z 12 [Note] [MY-011825] [InnoDB] *** Priority TRANSACTION:

TRANSACTION 728431, ACTIVE 0 sec starting index read

mysql tables in use 1, locked 1

MySQL thread id 12, OS thread handle 140504401893120, query id 1414279 Applying batch of row changes (update)

2019-11-14T21:14:03.797696Z 12 [Note] [MY-011825] [InnoDB] *** Victim TRANSACTION:

TRANSACTION 728426, ACTIVE 3 sec updating or deleting

mysql tables in use 1, locked 1

, undo log entries 11409

MySQL thread id 57, OS thread handle 140504353195776, query id 1414228 localhost root updating

update sbtest1_success set k=k+1 where id > 1000 and id < 100000

2019-11-14T21:14:03.797709Z 12 [Note] [MY-011825] [InnoDB] *** WAITING FOR THIS LOCK TO BE GRANTED:

RECORD LOCKS space id 1663 page no 11 n bits 144 index PRIMARY of table `sbtest`.`sbtest1_success` trx id 728426 lock_mode X

Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0

 0: len 8; hex 73757072656d756d; asc supremum;;

Problem z pisaniem wielu węzłów bez zidentyfikowania bieżącego węzła aktywnego zapisu, skończysz z tymi problemami, które są bardzo powszechnymi problemami, które widziałem podczas korzystania z Galera Cluster podczas pisania na wielu węzłach w o tym samym czasie. Aby tego uniknąć, możesz zastosować metodę konfiguracji z jednym wzorcem:

Z dokumentacji

Aby rozluźnić kontrolę przepływu, możesz użyć poniższych ustawień:

wsrep_provider_options = "gcs.fc_limit = 256; gcs.fc_factor = 0.99; gcs.fc_master_slave = YES"

Powyższe wymaga ponownego uruchomienia serwera, ponieważ fc_master_slave nie jest dynamiczny.

Włącz tryb debugowania do rejestrowania konfliktów lub zakleszczeń

Debugowanie lub śledzenie problemów z klastrem Galera jest bardzo ważne. Blokady w Galera są zaimplementowane inaczej niż w przypadku replikacji MySQL. Wykorzystuje optymistyczne blokowanie, gdy zajmuje się transakcjami w całym klastrze. W przeciwieństwie do replikacji MySQL, ma tylko pesymistyczne blokowanie, które nie wie, czy taka sama lub sprzeczna transakcja jest wykonywana w co-master w konfiguracji z wieloma wzorcami. Galera nadal używa pesymistycznego blokowania, ale w węźle lokalnym, ponieważ jest zarządzany przez InnoDB, który jest obsługiwanym silnikiem pamięci masowej. Galera używa optymistycznego blokowania, gdy trafia do innych węzłów. Oznacza to, że po osiągnięciu lokalnych blokad nie są wykonywane żadne kontrole z innymi węzłami w klastrze (blokowanie pesymistyczne). Galera zakłada, że gdy transakcja przejdzie fazę zatwierdzania w silniku pamięci masowej i inne węzły zostaną poinformowane, wszystko będzie w porządku i nie pojawią się żadne konflikty.

W praktyce najlepiej jest włączyć wsrep_logs_conflicts. Spowoduje to zarejestrowanie szczegółów konfliktu MDL oraz blokad InnoDB w klastrze. Włączenie tej zmiennej można ustawić dynamicznie, ale należy zachować ostrożność, gdy jest to włączone. Szczegółowo zapełni twój plik dziennika błędów i może zapełnić dysk, gdy rozmiar pliku dziennika błędów będzie zbyt duży.

Uważaj na zapytania DDL

W przeciwieństwie do replikacji MySQL, uruchomienie instrukcji ALTER może mieć wpływ tylko na połączenia przychodzące, które wymagają dostępu lub odwołania się do tej tabeli, na którą wskazuje instrukcja ALTER. Może również wpływać na niewolników, jeśli stół jest duży i może powodować opóźnienie niewolników. Jednak zapisy do twojego mastera nie będą blokowane, o ile twoje zapytania nie kolidują z bieżącym ALTER. Jednak nie jest tak w przypadku uruchamiania instrukcji DDL, takich jak ALTER z Galera Cluster. Instrukcje ALTER mogą powodować problemy, takie jak zatrzymanie się klastra Galera z powodu blokady całego klastra lub kontrola przepływu zaczyna rozluźniać replikację, podczas gdy niektóre węzły odzyskują dane po dużych zapisach.

W niektórych sytuacjach może wystąpić przestój w klastrze Galera, jeśli ta tabela jest zbyt duża i stanowi podstawową i kluczową tabelę dla aplikacji. Można to jednak osiągnąć bez przestojów. Jak zauważył Rick James na swoim blogu, możesz postępować zgodnie z poniższymi zaleceniami:

RSU a TOI

Rolling Schema Upgrade =ręcznie wykonaj jeden węzeł (offline) na raz
Całkowita izolacja zamówienia =Galera synchronizuje się tak, że jest wykonywana w tym samym czasie (w sekwencji replikacji) na wszystkich węzłach. RSU i TOI

Przestroga:Ponieważ nie ma możliwości zsynchronizowania klientów z DDL, należy upewnić się, że klienci są zadowoleni ze starego lub nowego schematu. W przeciwnym razie prawdopodobnie będziesz musiał wyłączyć cały klaster, jednocześnie przełączając zarówno schemat, jak i kod klienta.

Szybki DDL można równie dobrze wykonać przez TOI. Oto wstępna lista takich:

UTWÓRZ/UPUŚĆ/ZMIEŃ NAZWĘ BAZY DANYCH/TABELI
ZMIEŃ, aby zmienić DOMYŚLNE
ALTER, aby zmienić definicję ENUM lub SET (patrz zastrzeżenia w podręczniku)
Niektóre ZMIANY PARTYCJI, które są szybkie.
DROP INDEX (inny niż KLUCZ PODSTAWOWY)
DODAJ INDEKS?
Inne ALTER na „małych” stołach.
W 5.6, a zwłaszcza 5.7, które mają wiele przypadków ALTER ALGORITHM=INPLACE, sprawdź, które ALTER należy wykonać w jaki sposób.

W przeciwnym razie użyj RSU. Wykonaj następujące czynności osobno dla każdego węzła:

SET GLOBAL wsrep_OSU_method='RSU';

To również usuwa węzeł z klastra.

ALTER TABLE
SET GLOBAL wsrep_OSU_method='TOI';

Wkłada się z powrotem, prowadząc do ponownej synchronizacji (miejmy nadzieję, że szybki IST, a nie wolny SST)

Zachowaj spójność swojego klastra

Galera Cluster nie obsługuje filtrów replikacji, takich jak binlog_do_db lub binlog_ignore_db, ponieważ Galera nie korzysta z rejestrowania binarnego. Opiera się na pliku bufora pierścieniowego, zwanym również GCache, który przechowuje zestawy zapisu replikowane w klastrze. Nie można zastosować żadnego niespójnego zachowania ani stanu takich węzłów bazy danych.

Z drugiej strony

Galera ściśle implementuje spójność danych w ramach klastra. Nadal istnieje możliwość wystąpienia niespójności, w której nie można znaleźć wierszy lub rekordów. Na przykład ustawienie zmiennej wsrep_OSU_method RSU lub TOI dla instrukcji DDL ALTER może spowodować niespójne zachowanie. Sprawdź ten zewnętrzny blog firmy Percona omawiający niezgodności z Galera z TOI vs RSU.

Ustawienie wsrep_on=OFF, a następnie uruchamianie zapytań DML lub DDL może być niebezpieczne dla klastra. Należy również przejrzeć procedury składowane, wyzwalacze, funkcje, zdarzenia lub widoki, jeśli wyniki nie są zależne od stanu lub środowiska węzła. Gdy niektóre węzły mogą być niespójne, może to potencjalnie spowodować awarię całego klastra. Gdy Galera wykryje niespójne zachowanie, Galera spróbuje opuścić klaster i zakończyć ten węzeł. Dlatego możliwe jest, że wszystkie węzły mogą być niespójne, pozostawiając cię w stanie dylematu.

Jeśli węzeł Galera Cluster również ulega awarii, zwłaszcza w okresie dużego ruchu, lepiej nie uruchamiać węzła od razu. Zamiast tego wykonaj pełne SST lub jak najszybciej przynieś nową instancję lub gdy ruch się zmniejszy. Możliwe, że węzeł może spowodować niespójne zachowanie, które może spowodować uszkodzenie danych.

Segreguj duże transakcje i określ, czy użyć replikacji strumieniowej

Zajmijmy się tym od razu. Jedną z największych zmian, szczególnie w Galera Cluster 4.0, jest replikacja strumieniowa. Poprzednie wersje Galera Cluster 4.0 ograniczają transakcje <2GiB, które zazwyczaj są kontrolowane przez zmienne wsrep_max_ws_rows i wsrep_max_ws_size. Od Galera Cluster 4.0 możesz wysyłać> 2GiB transakcji, ale musisz określić, jak duże fragmenty mają zostać przetworzone podczas replikacji. Musi być ustawiony przez sesję, a jedyne zmienne, o które musisz zadbać, to wsrep_trx_fragment_unit i wsrep_trx_fragment_size. Wyłączenie replikacji strumieniowej jest proste — wystarczy ustawić wsrep_trx_fragment_size = 0. Zwróć uwagę, że replikacja dużej transakcji wiąże się również z obciążeniem węzłów podrzędnych (węzły, które replikują się z bieżącym węzłem active-writer/master), ponieważ logi będą zapisywane w tabeli wsrep_streaming_log w bazie danych MySQL.

Kolejna rzecz do dodania, ponieważ masz do czynienia z dużą transakcją, ważne jest, że Twoja transakcja może zająć trochę czasu, więc należy wziąć pod uwagę ustawienie zmiennej innodb_lock_wait_timeout na wysoką. Ustaw to za pośrednictwem sesji w zależności od szacowanego czasu, ale dłuższego niż szacowany czas zakończenia, w przeciwnym razie zwiększ limit czasu.

Zalecamy przeczytanie tego poprzedniego bloga na temat replikacji strumieniowej w akcji.

Replikowanie oświadczeń GRANT

Jeśli używasz GRANTów i powiązanych operacji, działaj na tabelach MyISAM/Aria w bazie danych `mysql`. Wyrażenia GRANT zostaną zreplikowane, ale tabele bazowe nie. Oznacza to, że INSERT INTO mysql.user ... nie zostanie zreplikowane, ponieważ tabela to MyISAM.

Jednak powyższe może już nie być prawdziwe, ponieważ Percona XtraDB Cluster(PXC) 8.0 (obecnie eksperymentalny) jako tabele schematu mysql zostały przekonwertowane na InnoDB, podczas gdy w MariaDB 10.4 niektóre tabele są nadal w formacie Aria, ale inne są w formacie CSV lub InnoDB. Powinieneś określić, jaką masz wersję i dostawcę Galera, ale najlepiej unikać używania instrukcji DML odwołujących się do schematu mysql. W przeciwnym razie możesz uzyskać nieoczekiwane wyniki, chyba że masz pewność, że jest to PXC 8.0.

Transakcje XA, ZABLOKOWANIE/ODBLOKOWANIE TABEL, GET_LOCK/RELEASE_LOCK nie są obsługiwane

Galera Cluster nie obsługuje transakcji XA, ponieważ transakcje XA inaczej obsługują wycofywanie i zatwierdzanie. Instrukcje LOCK/UNLOCK lub GET_LOCK/RELEASE_LOCK są niebezpieczne podczas stosowania lub używania z Galera. Może wystąpić awaria lub blokady, których nie można zabić i które pozostają zablokowane. Na przykład

---TRANSACTION 728448, ACTIVE (PREPARED) 13356 sec

mysql tables in use 2, locked 2

3 lock struct(s), heap size 1136, 5 row lock(s), undo log entries 5

MySQL thread id 67, OS thread handle 140504353195776, query id 1798932 localhost root wsrep: write set replicated and certified (13)

insert into sbtest1(k,c,pad) select k,c,pad from sbtest1_success limit 5

Ta transakcja została już odblokowana, a nawet zabita, ale bezskutecznie. Sugerujemy przeprojektowanie klienta aplikacji i pozbycie się tych funkcji podczas migracji do Galera Cluster.

Stabilność sieci to KONIECZNOŚĆ!!!

Galera Cluster może bez problemu pracować nawet z topologią między-WAN lub między geografią (sprawdź ten blog na temat implementacji topologii międzygeologicznej w Galera). Jeśli jednak łączność sieciowa między poszczególnymi węzłami nie jest stabilna lub przerywana przez nieoczekiwany czas, może to być problematyczne dla klastra. Najlepiej, jeśli masz klaster działający w sieci prywatnej i lokalnej, w której każdy z tych węzłów jest połączony. Projektując węzeł jako odzyskiwanie po awarii, zaplanuj utworzenie klastra, jeśli znajdują się one w innym regionie lub geografii. Możesz zacząć czytać nasz poprzedni blog, Używanie replikacji klastra MySQL Galera do tworzenia klastra rozproszonego geograficznie:część pierwsza, ponieważ może to pomóc w wyborze topologii klastra Galera.

Kolejną rzeczą do dodania w kwestii inwestowania w sprzęt sieciowy, byłoby problematyczne, gdyby szybkość przesyłania danych w sieci zapewniała niższą prędkość podczas odbudowy instancji podczas IST lub gorszą podczas SST, zwłaszcza jeśli zestaw danych jest ogromny . Transfer sieciowy może zająć wiele godzin, co może wpłynąć na stabilność klastra, zwłaszcza jeśli masz klaster z 3 węzłami, podczas gdy 2 węzły nie są dostępne, gdy te 2 są dawcą i dołączającym. Zwróć uwagę, że w fazie SST węzły DONOR/JOINER nie mogą być używane, dopóki nie będą w stanie zsynchronizować się z klastrem podstawowym.

W poprzedniej wersji Galera, jeśli chodzi o wybór węzła dawcy, dawca State Snapshot Transfer (SST) był wybierany losowo. W Glerze 4 jest znacznie bardziej ulepszony i ma możliwość wyboru odpowiedniego dawcy w ramach klastra, ponieważ będzie faworyzować dawcę, który może zapewnić przyrostowy transfer stanu (IST) lub wybrać dawcę w tym samym segmencie. Alternatywnie możesz ustawić zmienną wsrep_sst_donor na właściwego dawcę, którego chcesz zawsze wybrać.

Tworzenie kopii zapasowych danych i przeprowadzanie sztywnych testów podczas migracji i przed produkcją

Gdy już się dopasujesz i zdecydujesz się na migrację danych do Galera Cluster 4.0, upewnij się, że zawsze masz przygotowaną kopię zapasową. Jeśli wypróbowałeś ClusterControl, tworzenie kopii zapasowych powinno być łatwiejsze.

Upewnij się, że migrujesz do właściwej wersji InnoDB i nie zapomnij zawsze zastosować i uruchomić mysql_upgrade przed wykonaniem testu. Upewnij się, że wszystkie twoje testy pomyślnie przeszły pożądany wynik, z którego replikacja MySQL może ci zaoferować. Najprawdopodobniej nie ma różnicy między silnikiem pamięci masowej InnoDB, którego używasz w klastrze replikacji MySQL, a klastrem MySQL Galera, o ile zalecenia i wskazówki zostały wcześniej zastosowane i przygotowane.

Wnioski

Migracja do Galera Cluster 4.0 może nie być pożądanym rozwiązaniem w zakresie technologii baz danych. Jednak nie odciąga Cię to od korzystania z Galera Cluster 4.0, o ile można przygotować, skonfigurować i zapewnić jego specyficzne wymagania. Galera Cluster 4.0 stał się teraz bardzo potężnym, realnym wyborem i opcją, zwłaszcza na wysoce dostępnej platformie i rozwiązaniu. Sugerujemy również przeczytanie tych zewnętrznych blogów na temat Zastrzeżeń Galera lub Ograniczeń klastra Galera lub tego podręcznika z MariaDB.