Aktualizacja bazy danych dla klastrów Galera, takich jak Percona XtraDB Cluster (PXC) lub MariaDB Galera Cluster, może być wyzwaniem, szczególnie w środowisku produkcyjnym. Nie możesz sobie pozwolić na utratę stanu wysokiej dostępności i narażanie go na ryzyko.
Procedura aktualizacji musi być dobrze udokumentowana, a najlepiej przed aktualizacją należy wykonać dokumentację, rygorystyczne testy i testy porównawcze. Co najważniejsze, bezpieczeństwo i ulepszenia również muszą być zidentyfikowane na podstawie dziennika zmian aktualizacji wersji bazy danych.
We wszystkich obawach automatyzacja pomaga osiągnąć bardziej wydajny proces aktualizacji, pomaga uniknąć błędów ludzkich i poprawia RTO.
Jak zarządzać procesem aktualizacji klastra PXC/MariaDB Galera
Aktualizacja klastra PXC/MariaDB Galera wymaga odpowiedniej dokumentacji i przepływu procesów, która zawiera listę rzeczy do zrobienia oraz czynności do wykonania na wypadek, gdyby coś poszło nie tak. Oznacza to, że należy opracować plan ciągłości działania, który obejmuje również plan odzyskiwania po awarii. Nie możesz sobie pozwolić na utratę biznesu w razie kłopotów.
Zwykle należy zacząć od środowiska testowego. Środowisko testowe powinno mieć dokładnie takie same ustawienia i konfigurację jak środowisko produkcyjne. Nie możesz przejść bezpośrednio do aktualizacji środowiska produkcyjnego, ponieważ nie masz pewności, jaki efekt i jaki będzie miał wpływ, jeśli coś nie będzie zgodne z planem.
Praca w środowisku produkcyjnym jest bardzo wrażliwa, dlatego w większości przypadków zawsze istnieje przestój i przerwa na konserwację, aby uniknąć drastycznych skutków.
Istnieją dwa rodzaje aktualizacji dla klastra PCX lub MariaDB Galera, o których należy pamiętać. Są to uaktualnienie wersji głównej i uaktualnienie wersji drugorzędnej lub często określane jako uaktualnienie w miejscu. Uaktualnienie w miejscu polega na uaktualnieniu wersji bazy danych do jej najnowszej wersji pomocniczej przy użyciu tych samych danych binarnych bazy danych. Nie nastąpią żadne fizyczne zmiany w samych danych, ale tylko w binarnej bazie danych lub podstawowych pakietach oprogramowania.
Aktualizacja klastra PCX lub MariaDB Galera do wersji głównej
Aktualizacja do wersji głównej może być trudna, szczególnie w środowisku produkcyjnym. Obejmuje złożony rodzaj konfiguracji bazy danych i specjalne wbudowane funkcje klastra PXC lub MariaDB Galera. Dane przestrzenno-czasowe, ze znacznikiem czasu, dane maszynowe lub wszelkie dane wieloaspektowe są bardzo konserwatywne i wrażliwe na aktualizacje. Nie można zastosować uaktualnienia w miejscu dla tego procesu, ponieważ zostałoby wprowadzonych wiele poważnych zmian. O ile nie masz bardzo małych danych lub danych składających się z idempotentów lub danych, które można łatwo wygenerować, możesz to zrobić bezpiecznie, o ile wiesz, że wpływ nie wpłynie na twoje dane.
Jeśli ilość danych jest duża, najlepiej zautomatyzować proces aktualizacji. Jednak może nie być idealnym rozwiązaniem, aby zautomatyzować całą sekwencję w procesie aktualizacji, ponieważ mogą pojawić się nieoczekiwane problemy podczas głównej fazy aktualizacji. Najlepiej jest zautomatyzować powtarzające się kroki i procesy ze znanymi wynikami w dużej aktualizacji. W dowolnym momencie wymagane są zasoby do oceny, czy proces automatyzacji jest bezpieczny, aby uniknąć jakichkolwiek przerw w procesie aktualizacji. Zautomatyzowane testowanie po aktualizacji jest równie ważne i powinno być uwzględnione jako część procesu po aktualizacji.
Aktualizacja klastra PCX lub MariaDB Galera do wersji mniejszej
Uaktualnienie wersji drugorzędnej, zwane uaktualnieniem w miejscu, jest zwykle bezpieczniejszym podejściem do przeprowadzenia procesu uaktualniania. Dzieje się tak dlatego, że najczęstszymi zmianami w tym wydaniu są poprawki lub ulepszenia dotyczące bezpieczeństwa i wykorzystania, błędy (zwykle poważne) lub problemy ze zgodnością wymagające poprawek, zwłaszcza jeśli w bieżącym sprzęcie lub systemie operacyjnym zastosowano zmiany, które mogą również spowodować, że baza danych nie będzie działać prawidłowo. Chociaż wpływ może być zwykle odzyskany przy minimalnym efekcie, nadal konieczne jest przejrzenie i przeczytanie dziennika zmian, który został przesłany do określonej aktualizacji wersji pomocniczej.
Wdrożenie zadania w celu wykonania procesu aktualizacji jest idealnym przykładem automatyzacji. Zwykły przepływ jest bardzo powtarzalny i w większości nie powoduje szkód dla istniejącego klastra PXC lub MariaDB Galera. Najważniejsze jest to, że po aktualizacji nastąpi automatyczne testowanie w celu ustalenia, czy konfiguracja, konfiguracja, wydajność i funkcjonalność nie są uszkodzone.
Unikaj niepowodzeń! Przygotuj się, zautomatyzuj to!
Nasz klient skontaktował się z nami, prosząc o pomoc, ponieważ po niewielkiej aktualizacji bazy danych funkcja, z której korzysta w bazie danych, nie działa prawidłowo. Poprosili o kroki i procesy, jak obniżyć i jak bezpieczne będzie. Ich klienci narzekali, że ich aplikacja zupełnie nie działa, generalizując, że jest nieprzydatna.
Nawet w przypadku tak małej usterki, wkurzony klient może źle skomentować Twój produkt. Lekcja wyciągnięta z tego scenariusza jest taka, że niepowodzenie testowania po aktualizacji prowadzi do założenia, że wszystkie funkcje w bazie danych działają zgodnie z oczekiwaniami.
Załóżmy, że planujesz zautomatyzować proces aktualizacji, a następnie zwróć uwagę, że typ procesu automatyzacji różni się w zależności od typu aktualizacji, które musisz wykonać. Jak wspomniano wcześniej, duże ulepszenie w porównaniu z niewielkim ulepszeniem ma różne podejścia. Dlatego konfiguracja automatu może nie dotyczyć obu aktualizacji oprogramowania bazy danych.
Automatyzacja po procesie aktualizacji
W tym momencie oczekuje się, że proces aktualizacji zostanie zakończony, najlepiej poprzez automatyzację. Teraz, gdy Twoja baza danych jest gotowa do odbierania połączeń od klientów, musi nastąpić faza rygorystycznych testów.
Uruchom mysql_upgrade
Bardzo ważne i bardzo zalecane jest wykonanie mysql_upgrade po zakończeniu procesu aktualizacji. mysql_upgrade szuka niezgodności z uaktualnionym serwerem MySQL, wykonując następujące czynności:
-
Aktualizuje tabele systemowe w schemacie mysql, dzięki czemu możesz korzystać z nowych uprawnień lub możliwości, które mogą zostały dodane.
-
Aktualizuje schemat wydajności i schemat sys.
-
Sprawdza schematy użytkowników.
Mysql_upgrade określa, czy tabela ma problemy, takie jak niezgodności spowodowane zmianami w najnowszej wersji po aktualizacji, i próbuje rozwiązać ten problem poprzez naprawę tabeli. W przeciwnym razie, jeśli się nie powiedzie, twój test automatyzacji będzie musiał zakończyć się niepowodzeniem i nie może przejść do czegoś innego. Należy to najpierw zbadać i wykonać ręczną naprawę.
Sprawdź dzienniki błędów
Po zakończeniu mysql_upgrade musisz sprawdzić i zweryfikować błędy, które wystąpiły. Możesz umieścić to w skrypcie i sprawdzić, czy w dziennikach błędów nie występują etykiety „błędu” lub „ostrzeżenia”. Bardzo ważne jest, aby ustalić, czy tak jest. Twój automatyczny test musi mieć możliwość wychwytywania pułapek błędów albo może czekać na kontynuację danych wejściowych użytkownika, jeśli błąd jest bardzo minimalny lub oczekiwany, w przeciwnym razie zatrzymaj proces aktualizacji.
Przeprowadź test jednostkowy
Środowisko bazy danych TDD (Test Driven Development) to podejście do tworzenia oprogramowania, w którym istnieje szereg przypadków testowych, które należy zweryfikować i określić, czy walidacja jest prawdziwa (zaliczona) czy fałszywa (niepowodzenie). Coś takiego jak na poniższym zrzucie ekranu:
Zdjęcie dzięki uprzejmości guru99.com
Ten rodzaj testów jednostkowych pomaga uniknąć niechcianych błędów lub błędów logicznych w aplikacji i bazie danych. Pamiętaj, że jeśli w bazie danych znajdują się nieprawidłowe dane, zaszkodziłoby to wszystkim analizom biznesowym i transakcjom, zwłaszcza jeśli wiąże się to ze złożonymi obliczeniami finansowymi lub równaniami matematycznymi.
Jeśli pytasz, czy naprawdę konieczne jest wykonanie testu jednostkowego po aktualizacji? Oczywiście, że jest! Nie musisz koniecznie uruchamiać tego w środowisku produkcyjnym. Podczas faz testowych, tj. uaktualniania najpierw swoich QA, środowiska programistycznego/stagingowego, należy to zastosować w tym obszarze. Dane muszą być dokładną kopią co najmniej lub prawie taką samą jak środowisko produkcyjne. Twoim celem jest uniknięcie niepożądanych wyników i zdecydowanie błędnych wyników logicznych. Musisz oczywiście zadbać o swoje dane i określić, czy wyniki przejdą test weryfikacyjny.
Jeśli zamierzasz pracować ze swoją produkcją, zrób to. Jednak nie bądź tak sztywny, jak faza testowania stosowana w środowisku QA, programistycznym lub pomostowym. Dzieje się tak, ponieważ musisz planować swój czas w oparciu o dostępne okno serwisowe i unikać opóźnień i dłuższego RTO.
Z mojego doświadczenia wynika, że podczas fazy aktualizacji klienci wybierają szybsze podejście, które jest ważne dla ustalenia, czy taka funkcja zapewnia poprawny wynik. Co więcej, możesz mieć skrypt automatyzujący test, zestaw biznesowych funkcji logicznych lub procedur składowanych, ponieważ pomaga to buforować zapytania i ogrzewać bazę danych.
Przygotowując się do testu jednostkowego swojej bazy danych, unikaj wymyślania koła na nowo. Zamiast tego spójrz na dostępne narzędzia, które możesz wybrać, jeśli są dobre dla Twoich wymagań i potrzeb. Sprawdź Selenium lub sprawdź tego bloga.
Zweryfikuj tożsamość zapytań
Najczęstszym narzędziem, którego możesz użyć, jest pt-upgrade firmy Percona. Sprawdza, czy wyniki zapytania są identyczne na różnych serwerach. Wykonuje zapytania na podstawie podanych dzienników i dostarczonego połączenia (lub nazywanego DSN), a następnie porównuje wyniki i zgłasza wszelkie istotne różnice. Oferuje więcej niż opcje zbierania lub analizowania zapytań, na przykład poprzez tcpdump.
Korzystanie z pt-upgrade jest łatwe. Na przykład możesz uruchomić za pomocą następującego polecenia:
## Comparing via slow log for the given hosts
pt-upgrade h=host1 h=host2 slow.log
## or use fingerprints, useful for debugging purposes
pt-upgrade --fingerprints --run-time=1h mysqld-slow.log h=127.0.0.1,P=5091 h=127.0.0.1,P=5517
## or with tcpdump,
tcpdump -i eth0 port 3306 -s 65535 -x -n -q -tttt \
| pt-query-digest --type tcpdump --no-report --print \
| pt-upgrade h=host1 h=host2Dobrą praktyką jest to, że po wykonaniu uaktualnienia, zwłaszcza uaktualnienia wersji głównej, pt-upgrade jest używany do kontynuowania i wykonywania analizy zapytań, identyfikującej różnice w oparciu o wyniki. Dobrą praktyką jest robienie tego w fazie testowania podczas wykonywania tego w swoich kontrolach jakości lub środowisku przejściowym i programistycznym, aby można było zdecydować, czy bezpieczniej jest kontynuować. Możesz dodać to do swojego narzędzia automatyzacji i uruchomić to jako podręcznik, gdy będzie gotowe do wykonywania swoich obowiązków.
Jak zautomatyzować proces testowania?
W naszych poprzednich blogach przedstawialiśmy różne sposoby automatyzacji baz danych. Najpopularniejszymi narzędziami, które są modne, są te narzędzia oprogramowania do wdrażania IaC (Infrastructure as Code). Możesz użyć Puppet, Chef, SaltStack lub Ansible, aby wykonać tę pracę.
Moją preferencją zawsze było Ansible, aby wykonywać moje automatyczne testy, pozwala mi to tworzyć podręczniki według jego roli zawodowej. Oczywiście nie mogę stworzyć jednego automatu, który zrobi wszystko, ponieważ sytuacja i środowisko są różne. Opierając się na podanych wcześniej typach uaktualnień (duże i drobne uaktualnienie), należy rozróżnić jego proces. Nawet jeśli jest to tylko uaktualnienie na miejscu, nadal musisz upewnić się, że Twoje podręczniki będą wykonywać prawidłową pracę.
ClusterControl to Twój przyjaciel w zakresie automatyzacji baz danych!
ClusterControl to dobra opcja do wykonywania podstawowych i automatycznych testów. ClusterControl nie jest strukturą do testowania; nie jest to narzędzie do przeprowadzania testów jednostkowych. Jest to jednak narzędzie do zarządzania i monitorowania baz danych, które zawiera wiele zautomatyzowanych wdrożeń opartych na żądanych wyzwalaczach od użytkownika lub administratora oprogramowania.
ClusterControl oferuje drobne aktualizacje wersji, co zapewnia wygodę administratorom podczas przeprowadzania aktualizacji. Wykonuje również mysql_upgrade w locie. Nie musisz więc wykonywać tego ręcznie. ClusterControl wykrywa również nowe wersje do aktualizacji i zaleca kolejne kroki do wykonania. W przypadku wystąpienia awarii aktualizacja nie będzie kontynuowana.
Oto przykład drobnej aktualizacji:
Jeśli przyjrzysz się uważnie, mysql_upgrade działa pomyślnie. Chociaż nie zaleca i wykonuje automatyczną aktualizację mastera, dzieje się tak, ponieważ nie jest to właściwe podejście do kontynuowania. W takim przypadku musisz wypromować nowe urządzenie podrzędne, a następnie zdegradować urządzenie nadrzędne jako podrzędne, aby przeprowadzić aktualizację.
Wnioski
Wspaniałą rzeczą w ClusterControl jest to, że możesz włączyć sprawdzanie dzienników błędów, przeprowadzać test jednostkowy, weryfikować tożsamość zapytań poprzez tworzenie Doradców. Nie jest to trudne. Możesz zapoznać się z naszym poprzednim blogiem Używanie ClusterControl Advisor do tworzenia sprawdzeń dla SELinux i Meltdown/Spectre:część pierwsza. To ilustruje, w jaki sposób możesz skorzystać i uruchomić następne zadanie do wykonania po wykonaniu uaktualnienia. ClusterControl ma wbudowane alerty lub alarmy, które można zintegrować z ulubionymi systemami alertów innych firm, aby powiadomić Cię o bieżącym stanie automatycznego testowania.
