MariaDB Server oferuje replikację asynchroniczną i synchroniczną. Można go skonfigurować tak, aby miał replikację z wieloma źródłami lub konfigurację z wieloma wzorcami.
W przypadku aplikacji intensywnie korzystających z odczytu i zapisu konfiguracja master-slave jest powszechna, ale może się różnić w zależności od stosu bazowego potrzebnego do zbudowania środowiska bazy danych o wysokiej dostępności.
Posiadanie konfiguracji replikacji master-slave może nie spełniać Twoich potrzeb, szczególnie w środowisku produkcyjnym. Sam serwer MariaDB (konfiguracja master-slave) nie wystarcza do zapewnienia wysokiej dostępności, ponieważ nadal ma pojedynczy punkt awarii (SPOF).
MariaDB wprowadziła produkt dla przedsiębiorstw (platforma MariaDB), aby rozwiązać ten problem z wysoką dostępnością. Zawiera różne składniki:wersję korporacyjną MariaDB, MariaDB ColumnStore, MaxScale i lekkie łączniki MariaDB. W porównaniu z innymi dostawcami oferującymi tę samą ofertę rozwiązań dla przedsiębiorstw może to być opłacalna opcja, jednak nie każdy potrzebuje takiego poziomu złożoności.
W tym blogu pokażemy, jak korzystać z MariaDB Server przy użyciu replikacji w wysoce dostępnym środowisku z opcją korzystania ze wszystkich bezpłatnych narzędzi lub naszego ekonomicznego oprogramowania do zarządzania do uruchamiania i monitorować infrastrukturę serwera MariaDB.
Konfiguracja topologii wysokiej dostępności MariaDB
Zwykła konfiguracja topologii master-slave z MariaDB Server wykorzystuje podejście asynchroniczne lub synchroniczne z tylko jednym masterem odbierającym zapisy, a następnie replikuje swoje zmiany do slave'ów, tak jak na poniższym diagramie:
Ale z drugiej strony to nie zapewnia wysokiej dostępności i ma pojedynczy punkt awarii. Jeśli master umrze, klient aplikacji przestanie działać. Teraz musimy dodać do stosu mechanizm automatycznego przełączania awaryjnego, aby uniknąć SPOF, a także oferuje równoważenie obciążenia w celu dzielenia odczytu i zapisu oraz w trybie round-robin. Na razie więc otrzymamy typ topologii,
Teraz ta topologia zapewnia większe bezpieczeństwo pod względem SPOF. MaxScale dokona podziału odczytu i zapisu w węzłach bazy danych z urządzenia głównego na urządzenia podrzędne. MaxScale doskonale podchodzi do tego typu konfiguracji. MaxScale ma również wbudowaną funkcję automatycznego wykrywania. Więc bez względu na to, jakie zmiany zajdą w stanie węzłów bazy danych, wykryje ona i odpowiednio zareaguje. MaxScale umożliwia przełączenie awaryjne, a nawet przełączenie. Aby dowiedzieć się więcej o mechanizmie przełączania awaryjnego, przeczytaj nasz poprzedni blog, który omawia mechanizm przełączania awaryjnego MariaDB MaxScale.
Zwróć uwagę, że mechanizm przełączania awaryjnego MaxScale w MariaDB Monitor ma również swoje ograniczenia. Najlepiej stosować go tylko w konfiguracji master-slave bez zbyt skomplikowanej konfiguracji. Oznacza to, że konfiguracja master-master nie jest obsługiwana. Jednak MaxScale ma więcej do zaoferowania. Nie tylko wykonuje pewne równoważenie obciążenia, ponieważ wykonuje podziały odczytu i zapisu, ale ma wbudowany SmartRouter, który wysyła zapytanie do najbardziej wydajnego węzła. Chociaż nie dodaje to funkcji wysokiej dostępności, ale pomaga węzłom utknąć w ruchu i uniknąć słabszej wydajności niektórych węzłów bazy danych, co może powodować przekroczenie limitu czasu lub całkowicie niedostępny serwer z powodu ciągłej aktywności wymagającej dużej ilości zasobów .
Jednym z zastrzeżeń przy korzystaniu z MaxScale jest użycie BSL (Business Source LIcense). Może być konieczne zapoznanie się z najczęściej zadawanymi pytaniami przed przyjęciem tego oprogramowania.
Inną opcją do wyboru jest wygodniejsze podejście. Wybór ClusterControl może być opłacalny i posiadanie serwerów proxy w środku przy użyciu HaProxy, MaxScale lub ProxySQL, dla których ten ostatni może być skonfigurowany z konfiguracji lekkiej do bardziej produkcyjnej, która obsługuje routing zapytań, filtrowanie zapytań, zapora lub zabezpieczenia. Zobacz poniższą ilustrację:
Teraz nad nimi znajduje się ClusterControl. ClusterControl jest skonfigurowany z wysoką dostępnością, tj. CMON HA. Alternatywnie, warstwę proxy można wybrać z HaProxy — bardzo lekka opcja do wyboru, MaxScale, jak wspomniano wcześniej, lub ProxySQL, który ma bardziej wyrafinowany zestaw parametrów, jeśli potrzebujesz większej elastyczności i konfiguracji idealnej dla konfiguracja produkcji. ClusterControl obsłuży automatyczne wykrywanie pod kątem stanu kondycji węzłów, zwłaszcza węzła głównego, który jest głównym węzłem, aby określić, czy wymaga przełączenia awaryjnego, czy nie. Teraz może to być bardziej samowystarczalne, ale zwiększa koszty ze względu na liczbę węzłów wymaganych do zaimplementowania tej konfiguracji, a także korzystanie z automatycznego przełączania awaryjnego ClusterControl, które ma zastosowanie do naszej zaawansowanej i korporacyjnej licencji. Ale z drugiej strony zapewnia pełne bezpieczeństwo, ochronę i obserwowalność infrastruktury bazy danych. W rzeczywistości jest to bardziej tanie wdrożenie w przedsiębiorstwie w porównaniu z dostępnymi rozwiązaniami na rynku globalnym.
Wdrażanie replikacji MariaDB typu master-slave w celu zapewnienia wysokiej dostępności
Załóżmy, że masz istniejącą konfigurację master-slave MariaDB. W tym przykładzie użyjemy ClusterControl, korzystając z bezpłatnej wersji Community, którą możesz zainstalować i używać bezpłatnie. To po prostu sprawia, że Twoja praca jest łatwa i szybka w konfiguracji. Aby to zrobić, wystarczy zaimportować istniejący klaster replikacji MariaDB. Sprawdź nasz poprzedni blog na temat zarządzania MariaDB za pomocą ClusterControl. W tym blogu mam początkowo następującą konfigurację jako klaster replikacji MariaDB, jak widać poniżej:
Teraz użyjmy tutaj MaxScale jako alternatywnego rozwiązania z platformy MariaDB, która również oferuje wysoką dostępność. Aby to zrobić, jest to bardzo łatwe w użyciu z ClusterControl za pomocą zaledwie kilku kliknięć, możesz wtedy skonfigurować MaxScale, który działa na istniejącym klastrze MariaDB Replication. Aby to zrobić, po prostu przejdź do Zarządzaj → Load Balancer → MaxScale, a będziesz mógł skonfigurować i podać odpowiednie wartości, jak pokazano poniżej,
Następnie po prostu włącz lub kliknij pole wyboru, aby wybrać, które serwery mają być dodane w ramach monitorowania MaxScale. Zobacz poniżej,
Zakładając, że masz więcej niż jeden węzeł MaxScale do dodania, po prostu powtórz te same kroki.
Na koniec skonfigurujemy Keepalived, aby nasze węzły MaxScale były zawsze dostępne w razie potrzeby. Jest to bardzo szybkie dzięki prostym krokom przy użyciu ClusterControl. Ponownie musisz przejść do Zarządzaj → Load Balancer, ale zamiast tego wybierz Keepalved,
Jak zauważyłeś, umieściłem moje Keepalived razem z MaxScale na tym samym węźle mojego niewolnika (192.168.10.30). Z drugiej strony, drugi (2.) Keepalived działa na 192.168.10.40 wraz z Maxscale na tym samym hoście.
Wynikiem topologii jest gotowość produkcyjna, która może zapewnić routing zapytań, wysoką dostępność i automatyczne przełączanie awaryjne wyposażone w rozległe monitorowanie i obserwowalność przy użyciu ClusterControl. Zobacz poniżej,
Wnioski
Korzystanie z samej replikacji MariaDB Server nie zapewnia wysokiej dostępności. Rozszerzanie i używanie narzędzi innych firm zapewni wysoką dostępność stosu bazy danych, nie tylko opierając się na produktach MariaDB, czy nawet korzystając z platformy MariaDB.
Są sposoby na osiągnięcie tego celu i zarządzanie nim, aby było bardziej opłacalne. Jednak istnieje ogromna różnica w korzystaniu z tych rozwiązań dostępnych na rynku, takich jak ClusterControl, ponieważ zapewniają one szybkość, mniej kłopotów i oczywiście najwyższą obserwowalność dzięki bieżącym i aktualnym wydarzeniom, nie tylko ale także zdarzenia występujące w klastrze bazy danych.
