MariaDB
 sql >> Baza danych >  >> RDS >> MariaDB

Przewodnik po replikacji strumieniowej MySQL Galera Cluster:część pierwsza

Replikacja strumieniowa to nowa funkcja wprowadzona w wersji 4.0 Galera Cluster. Galera używa replikacji synchronicznie w całym klastrze, ale przed tą wersją zestawy zapisu większe niż 2 GB nie były obsługiwane. Replikacja strumieniowa umożliwia teraz replikację dużych zestawów zapisu, co jest idealne do masowego wstawiania lub ładowania danych do bazy danych.

W poprzednim blogu pisaliśmy o obsłudze dużych transakcji za pomocą replikacji strumieniowej i MariaDB 10.4, ale w chwili pisania tego bloga Codership nie wydało jeszcze swojej wersji nowego klastra Galera. Percona wydała jednak swoją eksperymentalną binarną wersję Percona XtraDB Cluster 8.0, która podkreśla następujące funkcje...

  • Replikacja strumieniowa obsługująca duże transakcje

  • Funkcje synchronizacji umożliwiają koordynację działań (wsrep_last_seen_gtid, wsrep_last_written_gtid, wsrep_sync_wait_upto_gtid)

  • Bardziej szczegółowe i ulepszone rejestrowanie błędów. wsrep_debug jest teraz zmienną wielowartościową, która pomaga w kontrolowaniu rejestrowania, a komunikaty rejestrowania zostały znacznie ulepszone.

  • Niektóre błędy DML i DDL w węźle replikującym można zignorować lub pominąć. Do konfiguracji użyj zmiennej wsrep_ignore_apply_errors.

  • Wiele tabel systemowych pomaga dowiedzieć się więcej o stanie klastra.

  • Infrastruktura wsrep w Galera 4 jest bardziej niezawodna niż w Galera 3. Oferuje szybsze wykonywanie kodu z lepszą obsługą stanów, lepszą przewidywalnością i obsługą błędów.

Co nowego w Galera Cluster 4.0?

Nowa funkcja replikacji strumieniowej

Dzięki replikacji strumieniowej transakcje są replikowane stopniowo w małych fragmentach podczas przetwarzania transakcji (tj. przed faktycznym zatwierdzeniem replikujemy pewną liczbę fragmentów o małym rozmiarze). Replikowane fragmenty są następnie stosowane w wątkach podrzędnych, zachowując stan transakcji we wszystkich węzłach klastra. Fragmenty blokują blokady we wszystkich węzłach i nie mogą być później w konflikcie.

Tabele systemowe Galera

Administratorzy bazy danych i klienci z dostępem do bazy danych MySQL mogą czytać te tabele, ale nie mogą ich modyfikować, ponieważ sama baza danych dokona wszelkich niezbędnych modyfikacji. Jeśli Twój serwer nie ma tych tabel, może to oznaczać, że używa on starszej wersji Galera Cluster.

#> show tables from mysql like 'wsrep%';

+--------------------------+

| Tables_in_mysql (wsrep%) |

+--------------------------+

| wsrep_cluster            |

| wsrep_cluster_members    |

| wsrep_streaming_log      |

+--------------------------+

3 rows in set (0.12 sec)

Nowe funkcje synchronizacji 

W tej wersji wprowadzono szereg funkcji SQL do użycia w operacjach synchronizacji wsrep. Możesz ich użyć do uzyskania globalnego identyfikatora transakcji, który jest oparty na ostatnim zapisie lub ostatniej widzianej transakcji. Możesz także ustawić węzeł, aby czekał na replikację i zastosowanie określonego GTID przed zainicjowaniem kolejnej transakcji.

Inteligentny wybór dawców

Niektóre niedoceniane funkcje, które pojawiły się od wersji Galera 3.x, obejmują inteligentny wybór dawców i odzyskiwanie po awarii klastra. Były one pierwotnie planowane dla Galery 4, ale trafiły do ​​wcześniejszych wersji głównie ze względu na wymagania klientów. Jeśli chodzi o wybór węzła dawcy w Galera 3, dawca State Snapshot Transfer (SST) został wybrany losowo. Jednak dzięki Galera 4 masz znacznie bardziej inteligentny wybór, jeśli chodzi o wybór dawcy, ponieważ będzie faworyzować dawcę, który może zapewnić przyrostowy transfer stanu (IST) lub wybrać dawcę w tym samym segmencie. Jako administrator bazy danych możesz to wymusić, ustawiając wsrep_sst_donor.

Dlaczego warto korzystać z replikacji strumieniowej MySQL Galera Cluster?

Długotrwałe transakcje

Problemy i ograniczenia Galery zawsze dotyczyły sposobu obsługi długotrwałych transakcji i często powodowały spowolnienie całego klastra z powodu replikacji dużych zestawów zapisu. Jego kontrola przepływu często staje się wysoka, powodując spowolnienie lub nawet zakończenie procesu zapisu w celu przywrócenia klastra do normalnego stanu. Jest to dość powszechny problem w poprzednich wersjach Galera Cluster.

Codership zaleca korzystanie z replikacji strumieniowej w przypadku długotrwałych transakcji, aby złagodzić takie sytuacje. Gdy węzeł zreplikuje i poświadczy fragment, nie jest już możliwe przerwanie go przez inne transakcje.

Duże transakcje

Jest to bardzo przydatne podczas ładowania danych do raportu lub analiz. Tworzenie zbiorczych wstawek, usunięć, aktualizacji lub użycie instrukcji LOAD DATA do załadowania dużej ilości danych może należeć do tej kategorii. Chociaż zależy to od tego, jak zarządzasz danymi w celu ich pobierania lub przechowywania. Należy wziąć pod uwagę, że replikacja strumieniowa ma swoje ograniczenia, polegające na tym, że klucze certyfikacji są generowane z blokad rekordów.

Bez replikacji strumieniowej aktualizacja dużej liczby rekordów spowodowałaby konflikt i cała transakcja musiałaby zostać wycofana. Urządzenia podrzędne, które również replikują duże transakcje, podlegają kontroli przepływu, gdy osiągają próg i zaczynają spowalniać cały klaster w celu przetwarzania wszelkich zapisów, ponieważ mają tendencję do rozluźniania otrzymywania transakcji przychodzących z replikacji synchronicznej. Galera zrelaksuje replikację, dopóki zestaw zapisów nie będzie możliwy do opanowania, ponieważ pozwala na ponowne kontynuowanie replikacji. Sprawdź ten zewnętrzny blog Percony, aby dowiedzieć się więcej o kontroli przepływu w Galera.

Dzięki replikacji strumieniowej węzeł zaczyna replikować dane z każdym fragmentem transakcji, zamiast czekać na zatwierdzenie. Oznacza to, że nie ma możliwości przerwania jakichkolwiek konfliktowych transakcji działających w innych węzłach, ponieważ to po prostu potwierdza, że ​​klaster certyfikował zestaw zapisu dla tego konkretnego fragmentu. Stosowanie i zatwierdzanie innych jednoczesnych transakcji jest bezpłatne bez blokowania i przetwarzania dużych transakcji przy minimalnym wpływie na klaster.

Najpopularniejsze rekordy/Najpopularniejsze miejsca

Najważniejsze rekordy lub wiersze to te wiersze w tabeli, które są stale aktualizowane. Dane te mogą być najczęściej odwiedzane i generować ruch w całej Twojej bazie danych (np. kanały informacyjne, licznik, taki jak liczba odwiedzin lub logi). Dzięki replikacji strumieniowej możesz wymusić krytyczne aktualizacje w całym klastrze.

Jak zauważył zespół Galera w Codership

„Uruchomienie transakcji w ten sposób skutecznie blokuje gorący rekord we wszystkich węzłach, uniemożliwiając innym transakcjom modyfikację wiersza. Zwiększa również szanse, że transakcja zostanie pomyślnie zatwierdzona, a klient z kolei otrzyma pożądany wynik”.

Wiąże się to z ograniczeniami, ponieważ może nie być trwałe i konsekwentne, że będziesz mieć udane zatwierdzenia. Bez korzystania z replikacji strumieniowej będziesz miał duże szanse na wycofywanie się, co może zwiększyć obciążenie użytkownika końcowego, gdy wystąpi ten problem z perspektywy aplikacji.

Rzeczy do rozważenia podczas korzystania z replikacji strumieniowej

  • Klucze certyfikacyjne są generowane z zamków rekordów, dlatego nie obejmują zamków typu gap ani kolejnych zamków na klucz. Jeśli transakcja przyjmuje blokadę luki, możliwe jest, że transakcja, która jest wykonywana na innym węźle, zastosuje zestaw zapisu, który napotka dziennik luk i przerwie transakcję strumieniową.
  • Po włączeniu replikacji strumieniowej dzienniki zestawu zapisu są zapisywane w tabeli wsrep_streaming_log znajdującej się w bazie danych systemu mysql, aby zachować trwałość w przypadku awarii, więc ta tabela jest używana podczas odzyskiwania. W przypadku nadmiernego rejestrowania i podwyższonego obciążenia replikacji, replikacja strumieniowa spowoduje obniżenie przepustowości transakcji. Może to stanowić wąskie gardło wydajności w przypadku osiągnięcia wysokiego obciążenia szczytowego. W związku z tym zaleca się włączanie replikacji strumieniowej tylko na poziomie sesji, a następnie tylko dla transakcji, które bez tego nie działałyby poprawnie.
  • Najlepszym przypadkiem użycia jest użycie replikacji strumieniowej do cięcia dużych transakcji
  • Ustaw rozmiar fragmentu na ~10 tys. wierszy
  • Zmienne fragmentów są zmiennymi sesji i można je ustawiać dynamicznie
  • Inteligentna aplikacja może w razie potrzeby włączać/wyłączać replikację strumieniową

Wnioski

Dziękujemy za przeczytanie, w drugiej części omówimy, jak włączyć Galera Cluster Streaming Replication i jak mogą wyglądać wyniki dla Twojej konfiguracji.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Jak uzyskać skróconą nazwę miesiąca z daty w MariaDB?

  2. Migracja Amazon RDS (MySQL lub MariaDB) na serwer lokalny

  3. Jak SUBSTRING() działa w MariaDB

  4. MariaDB ROUND() kontra PODŁOGA()

  5. MariaDB JSON_REMOVE() Objaśnienie