MySQL Galera Cluster 4.0 to nowe dziecko w bloku bazy danych z bardzo interesującymi nowymi funkcjami. Obecnie jest dostępny tylko jako część MariaDB 10.4, ale w przyszłości będzie działał również z MySQL 5.6, 5.7 i 8.0. W tym poście na blogu chcielibyśmy omówić niektóre z nowych funkcji, które pojawiły się wraz z Galera Cluster 4.0.
Replikacja strumieniowania klastra Galera
Najważniejszą nową funkcją w tej wersji jest replikacja strumieniowa. Dotychczas proces certyfikacji Klastra Galera działał w taki sposób, że całe transakcje po ich zakończeniu musiały być certyfikowane.
Ten proces nie był idealny w kilku scenariuszach...
- Punkty aktywne w tabelach, wiersze, które są bardzo często aktualizowane w wielu węzłach - setki szybkich transakcji działających na wielu węzłach, modyfikacja tego samego zestawu wierszy skutkuje częstymi zakleszczeniami i wycofywaniem transakcji
- Długotrwałe transakcje - jeśli transakcja zajmuje dużo czasu, to poważnie zwiększa szanse, że jakaś inna transakcja w międzyczasie na innym węźle może zmodyfikować niektóre wiersze, które również zostały zaktualizowane przez długą transakcję. Spowodowało to impas podczas certyfikacji i konieczność wycofania jednej z transakcji.
- Duże transakcje - jeśli transakcja modyfikuje znaczną liczbę wierszy, jest prawdopodobne, że inna transakcja w tym samym czasie na innym węźle zmodyfikuje jeden z wierszy już zmodyfikowanych przez dużą transakcję. Powoduje to zakleszczenie podczas certyfikacji i konieczność wycofania jednej z transakcji. Oprócz tego przetwarzanie dużych transakcji, wysyłanie ich do wszystkich węzłów w klastrze i certyfikowanie zajmie dodatkowy czas. To nie jest idealna sytuacja, ponieważ dodaje opóźnienia do zatwierdzeń i spowalnia cały klaster.
Na szczęście replikacja strumieniowa może rozwiązać te problemy. Główna różnica polega na tym, że certyfikacja odbywa się w partiach, w których nie ma potrzeby czekania na zakończenie całej transakcji. W rezultacie, nawet jeśli transakcja jest duża lub długa, większość (lub wszystkie, w zależności od ustawień, które za chwilę omówimy) wierszy jest zablokowana na wszystkich węzłach, uniemożliwiając innym zapytaniom ich modyfikację.
Opcje replikacji strumieniowania strumieniowego MySQL Galera Cluster
Istnieją dwie opcje konfiguracji replikacji strumieniowej:
wsrep_trx_fragment_size
Określa, jak duży powinien być fragment (domyślnie jest to ustawione na 0, co oznacza, że replikacja strumieniowa jest wyłączona)
wsrep_trx_fragment_unit
To mówi, czym naprawdę jest fragment. Domyślnie są to bajty, ale mogą to być również „wyciągi” lub „wiersze”.
Te zmienne mogą (i powinny) być ustawiane na poziomie sesji, dzięki czemu użytkownik może zdecydować, które konkretne zapytanie powinno być replikowane przy użyciu 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.
Możesz skonfigurować Galerę 4.0 tak, aby certyfikowała każdy zmodyfikowany wiersz i chwytała blokady na wszystkich węzłach, robiąc to. To sprawia, że replikacja strumieniowa świetnie radzi sobie z rozwiązywaniem problemów z częstymi zakleszczeniami, które przed Galerą 4.0 można było rozwiązać tylko poprzez przekierowanie wszystkich zapisów do jednego węzła.
Tabele WSREP
Galera 4.0 wprowadza kilka tabel, które pomogą monitorować stan klastra:
- wsrep_cluster
- wsrep_cluster_members
- wsrep_streaming_log
Wszystkie znajdują się w schemacie „mysql”. wsrep_cluster zapewni wgląd w stan klastra. wsrep_cluster_members poda informacje o węzłach, które są częścią klastra. wsrep_streaming_log pomaga śledzić stan replikacji strumieniowej.
Nadchodzące funkcje klastra Galera
Codership, firma stojąca za Galerą, jeszcze nie skończyła. Udało nam się uzyskać podgląd mapy drogowej od CEO, Seppo Jaakoli, który został przedstawiony na Percona Live na początku tego roku. Najwyraźniej zobaczymy takie funkcje, jak obsługa transakcji XA i szyfrowanie gcache. To naprawdę dobra wiadomość.
Obsługa transakcji XA będzie możliwa dzięki replikacji strumieniowej. Krótko mówiąc, transakcje XA to transakcje rozproszone, które mogą działać w wielu węzłach. Wykorzystują zatwierdzanie dwufazowe, które wymaga najpierw uzyskania wszystkich wymaganych blokad, aby uruchomić transakcję na wszystkich węzłach, a następnie, po zakończeniu, zatwierdzenia zmian. W poprzednich wersjach Galera nie miała możliwości blokowania zasobów na zdalnych węzłach, w przypadku replikacji strumieniowej uległo to zmianie.
Gcache to plik przechowujący zestawy zapisu. Jego zawartość jest przesyłana do węzłów dołączających, które proszą o transfer danych. Jeśli wszystkie dane są przechowywane w gcache, dołączający otrzyma tylko brakujące transakcje w procesie zwanym Incremental State Transfer (IST). Jeśli gcache nie zawiera wszystkich wymaganych danych, wymagany będzie State Snapshot Transfer (SST), a cały zestaw danych będzie musiał zostać przesłany do łączącego się węzła.
Gcache zawiera informacje o ostatnich zmianach, dlatego dobrze jest widzieć jego zawartość zaszyfrowaną dla lepszego bezpieczeństwa. Wraz z wprowadzaniem lepszych standardów bezpieczeństwa poprzez coraz więcej przepisów, kluczowe jest, aby oprogramowanie lepiej spełniało wymagania.
Wnioski
Nie możemy się doczekać, jak Galera Cluster 4.0 sprawdzi się na bazach danych niż MariaDB. Możliwość wdrożenia MySQL 5.7 lub 8.0 z Galera Cluster będzie naprawdę świetna. W końcu Galera jest jednym z najczęściej testowanych rozwiązań replikacji synchronicznej dostępnych na rynku.
