W jednym z poprzednich blogów omówiliśmy nowe funkcje, które pojawią się w MariaDB 10.4. Wspomnieliśmy tam, że w tej wersji będzie nowe wydanie Galera Cluster. W tym poście na blogu omówimy funkcje Galera Cluster 26.4.0 (lub Galera 4), przyjrzymy się im szybko i zbadamy, jak wpłyną one na konfigurację podczas pracy z MariaDB Galera Cluster.
Replikacja strumieniowa
Galera Cluster w żadnym wypadku nie zastępuje samodzielnego MySQL. Sposób, w jaki działa certyfikacja zbioru zapisu, wprowadził kilka ograniczeń i przypadków brzegowych, które mogą poważnie ograniczyć możliwość migracji do Galera Cluster. Trzy najczęstsze ograniczenia to...
- Problemy z długimi transakcjami
- Problemy z dużymi transakcjami
- Problemy z punktami aktywnymi w tabelach
Wspaniale jest zobaczyć, że Galera 4 wprowadza replikację strumieniową, która może pomóc w zmniejszeniu tych ograniczeń. Przyjrzyjmy się bliżej aktualnemu stanowi.
Długotrwałe transakcje
W tym przypadku mówimy o czasie, co w Galerze jest zdecydowanie problematyczne. Najważniejszą rzeczą do zrozumienia jest to, że Galera replikuje transakcje jako zbiory zapisu. Te zestawy zapisu są certyfikowane na członkach klastra, zapewniając, że wszystkie węzły mogą zastosować dany zestaw zapisu. Problem polega na tym, że blokady są tworzone na węźle lokalnym, nie są replikowane w całym klastrze, dlatego jeśli Twoja transakcja trwa kilka minut i jeśli piszesz do więcej niż jednego węzła Galera, z czasem coraz bardziej prawdopodobne jest, że na jeden z pozostałych węzłów niektóre transakcje zmodyfikują niektóre wiersze zaktualizowane w Twojej długotrwałej transakcji. Spowoduje to niepowodzenie certyfikacji i konieczność wycofania długotrwałej transakcji. Krótko mówiąc, biorąc pod uwagę, że wysyłasz zapisy do więcej niż jednego węzła w klastrze, im dłuższa transakcja, tym większe prawdopodobieństwo niepowodzenia certyfikacji z powodu jakiegoś konfliktu.
Hotspoty
Rozumiemy przez to wiersze, które są często aktualizowane. Zazwyczaj jest to jakiś licznik, który jest ciągle aktualizowany. Problem jest taki sam jak w przypadku długich transakcji - wiersze są blokowane tylko lokalnie. Ponownie, jeśli wyślesz zapisy do więcej niż jednego węzła, prawdopodobnie ten sam licznik zostanie zmodyfikowany w więcej niż jednym węźle, powodując konflikty i niepowodzenie certyfikacji.
Dla obu tych problemów istnieje jedno rozwiązanie — możesz wysyłać swoje zapisy tylko do jednego węzła zamiast dystrybuować je w całym klastrze. Możesz użyć do tego serwerów proxy — ClusterControl wdraża HAProxy i ProxySQL, oba można skonfigurować tak, aby zapisy były wysyłane tylko do jednego węzła. Jeśli nie możesz wysłać zapisów tylko do jednego węzła, musisz zaakceptować, że od czasu do czasu będą występować konflikty certyfikacji i wycofywanie. Ogólnie rzecz biorąc, aplikacja musi być w stanie obsłużyć cofanie zmian z bazy danych - nie da się tego obejść, ale jest to jeszcze ważniejsze, gdy aplikacja współpracuje z Galera Cluster.
Jednak wysłanie ruchu do jednego węzła nie wystarczy do rozwiązania trzeciego problemu.
Duże transakcje
Należy pamiętać, że zapis jest wysyłany do poświadczenia dopiero po zakończeniu transakcji. Następnie zestaw zapisów jest wysyłany do wszystkich węzłów i następuje proces certyfikacji. Powoduje to ograniczenie wielkości pojedynczej transakcji, ponieważ Galera, przygotowując zestaw zapisów, przechowuje go w buforze w pamięci. Zbyt duże transakcje zmniejszą wydajność klastra. Dlatego wprowadzono dwie zmienne:wsrep_max_ws_rows, która ogranicza liczbę wierszy na transakcję (choć można ją ustawić na 0 - nieograniczoną) oraz, co ważniejsze:wsrep_max_ws_size, którą można ustawić do 2 GB. Tak więc największa transakcja, którą możesz uruchomić w Galera Cluster, ma rozmiar do 2 GB. Należy również pamiętać, że certyfikacja i zastosowanie dużej transakcji również wymaga czasu, tworzenie „lagu” - odczyt po zapisie, który trafi węzeł inny niż ten, w którym pierwotnie zatwierdziłeś transakcję, najprawdopodobniej spowoduje nieprawidłowe dane, ponieważ transakcja jest nadal stosowana.
Galera 4 jest dostarczana z funkcją Streaming Replication, której można użyć do złagodzenia wszystkich tych problemów. Główna różnica polega na tym, że zapisy można teraz podzielić na części — nie trzeba już czekać na zakończenie całej transakcji, zanim dane zostaną zreplikowane. To może sprawić, że będziesz się zastanawiać - jak wygląda certyfikacja w takim przypadku? Krótko mówiąc, certyfikacja odbywa się w locie — każdy fragment jest certyfikowany, a wszystkie zaangażowane wiersze są zablokowane na wszystkich węzłach w klastrze. To poważna zmiana w sposobie działania Galery - do tej pory blokady były tworzone lokalnie, a na wszystkich węzłach będą tworzone blokady replikacji strumieniowej. Pomaga to w przypadkach, które omówiliśmy powyżej - blokowanie wierszy, gdy pojawiają się fragmenty transakcji, pomaga zmniejszyć prawdopodobieństwo, że transakcja będzie musiała zostać wycofana. Transakcje powodujące konflikt, wykonywane lokalnie, nie będą w stanie uzyskać potrzebnych blokad i będą musiały poczekać na zakończenie replikacji transakcji i zwolnienie blokad wierszy.
W przypadku hotspotów dzięki replikacji strumieniowej możliwe jest uzyskanie blokad na wszystkich węzłach podczas aktualizacji wiersza. Inne zapytania, które chcą zaktualizować ten sam wiersz, będą musiały poczekać na zwolnienie blokady, zanim wykonają swoje zmiany.
Duże transakcje skorzystają na replikacji strumieniowej, ponieważ nie będzie już konieczne czekanie na zakończenie całej transakcji ani nie będą ograniczone wielkością transakcji - duża transakcja zostanie podzielona na fragmenty. Pomaga również lepiej wykorzystać sieć - zamiast wysyłać 2 GB danych jednocześnie, te same 2 GB danych można podzielić na fragmenty i wysłać przez dłuższy czas.
Istnieją dwie opcje konfiguracji replikacji strumieniowej:wsrep_trx_fragment_size, która mówi, jak duży powinien być fragment (domyślnie jest ustawiona na 0, co oznacza, że replikacja strumieniowa jest wyłączona) i wsrep_trx_fragment_unit, która mówi, czym naprawdę jest fragment. Domyślnie są to bajty, ale mogą to być również „wyciągi” lub „wiersze”. Zmienne te mogą (i powinny) być ustawiane na poziomie sesji, dzięki czemu użytkownik może zdecydować, które konkretne zapytanie ma być replikowane za pomocą replikacji strumieniowej. Ustawienie jednostki na „instrukcje” i rozmiar na 1 pozwala na przykład na użycie replikacji strumieniowej tylko dla pojedynczego zapytania, które na przykład aktualizuje hotspot.
Oczywiście istnieją wady uruchamiania replikacji strumieniowej, głównie ze względu na fakt, że blokady są teraz brane na wszystkie węzły w klastrze. Jeśli widziałeś dużą transakcję wycofującą się przez wieki, teraz taka transakcja będzie musiała zostać wycofana na wszystkich węzłach. Oczywiście najlepszą praktyką jest maksymalne zmniejszenie rozmiaru transakcji, aby uniknąć wycofywania, które zajmuje wiele godzin. Inną wadą jest to, że z powodu odzyskiwania po awarii zestawy zapisu utworzone z każdego fragmentu są przechowywane w tabeli wsrep_schema.SR we wszystkich węzłach, co poniekąd implementuje bufor podwójnego zapisu, zwiększając obciążenie klastra. Dlatego powinieneś ostrożnie zdecydować, która transakcja powinna zostać zreplikowana przy użyciu replikacji strumieniowej i, o ile jest to wykonalne, powinieneś nadal trzymać się najlepszych praktyk polegających na przeprowadzaniu małych, krótkich transakcji lub dzieleniu dużej transakcji na mniejsze partie.
Blokady kopii zapasowych
Wreszcie, użytkownicy MariaDB będą mogli korzystać z blokad zapasowych dla SST. Ideą SST wykonywanego przy użyciu (dla MariaDB) mariabackup jest to, że cały zestaw danych musi być przesyłany w locie, a logi przeróbek są gromadzone w tle. Następnie należy uzyskać globalną blokadę, zapewniającą, że nie nastąpi zapis, należy zebrać i zapisać ostateczną pozycję dziennika przeróbek. Historycznie, w przypadku MariaDB, część blokująca była wykonywana przy użyciu STOŁÓW FLUSH Z BLOKADĄ ODCZYTU, która spełniała swoje zadanie, ale przy dużym obciążeniu była dość trudna do zdobycia. Jest też dość ciężki - nie tylko transakcje muszą czekać na zwolnienie blokady, ale także dane muszą zostać wyrzucone na dysk. Teraz, dzięki MariaDB 10.4, będzie można użyć mniej inwazyjnej BLOKADA ZAPASOWA, która nie będzie wymagała opróżniania danych, tylko zatwierdzenia będą blokowane na czas trwania blokady. Powinno to oznaczać mniej inwazyjne operacje KST, co z pewnością dobrze jest usłyszeć. Każdy, kto musiał uruchomić swój klaster Galera w trybie awaryjnym, na jednym węźle, trzymając kciuki, że SST nie wpłynie na działanie klastra, powinien być bardziej niż szczęśliwy, słysząc o tym ulepszeniu.
Przyczynowe odczyty z aplikacji
Galera 4 wprowadziła trzy nowe funkcje, które mają pomóc w dodaniu obsługi odczytów przyczynowych w aplikacjach - WSREP_LAST_WRITTEN_GTID(), która zwraca GTID ostatniego zapisu dokonanego przez klienta, WSREP_LAST_SEEN_GTID(), która zwraca GTID ostatniej zaobserwowanej transakcji zapisu przez klienta i WSREP_SYNC_WAIT_UPTO_GTID(), które zablokują klienta, dopóki identyfikator GTID przekazany do funkcji zostanie zatwierdzony w węźle. Oczywiście, możesz wymusić odczyty przyczynowe w Galerze już teraz, ale dzięki wykorzystaniu tych funkcji możliwe będzie zaimplementowanie bezpiecznego odczytu po zapisie w tych częściach aplikacji, w których jest to potrzebne, bez konieczności wprowadzania zmian w konfiguracji Galery.
Aktualizacja do MariaDB Galera 10.4
Jeśli chcesz wypróbować Galerę 4, jest ona dostępna w najnowszym kandydacie do wydania dla MariaDB 10.4. Zgodnie z dokumentacją MariaDB, w tej chwili nie ma możliwości przeprowadzenia aktualizacji na żywo 10.3 Galera do 10.4. Musisz zatrzymać cały klaster 10.3, zaktualizować go do wersji 10.4, a następnie uruchomić go z powrotem. To poważna blokada i mamy nadzieję, że to ograniczenie zostanie usunięte w jednej z następnych wersji. Niezwykle ważna jest opcja aktualizacji na żywo, a do tego zarówno MariaDB 10.3, jak i MariaDB 10.4 będą musiały współistnieć w tym samym klastrze Galera. Inną opcją, która również może być odpowiednia, jest skonfigurowanie replikacji asynchronicznej między starym i nowym klastrem Galera.
Mamy nadzieję, że spodobał Ci się ten krótki przegląd funkcji MariaDB 10.4 Galera Cluster. Nie możemy się doczekać, aż zobaczymy replikację strumieniową w rzeczywistych środowiskach produkcyjnych. Mamy również nadzieję, że te zmiany pomogą jeszcze bardziej zwiększyć popularność Galery. W końcu replikacja strumieniowa rozwiązuje wiele problemów, które mogą uniemożliwić ludziom migrację do Galera.
