Co nowego w MariaDB MaxScale 2.4

MaxScale 2.4 został wydany 21 grudnia 2019 r., a ClusterControl 1.7.6 obsługuje monitorowanie i zarządzanie aż do tej wersji. Jednak w przypadku wdrożenia ClusterControl obsługuje tylko do wersji 2.3. Trzeba ręcznie zaktualizować instancję ręcznie i na szczęście kroki aktualizacji są bardzo proste. Wystarczy pobrać najnowszą wersję ze strony pobierania MariaDB MaxScale i wykonać polecenie instalacji pakietu.

Poniższe polecenia pokazują, jak zaktualizować istniejący MaxScale 2.3 do MaxScale 2.4 na komputerze CentOS 7:

$ wget https://dlm.mariadb.com/1067184/MaxScale/2.4.10/centos/7/x86_64/maxscale-2.4.10-1.centos.7.x86_64.rpm
$ systemctl stop maxscale
$ yum localinstall -y maxscale-2.4.10-1.centos.7.x86_64.rpm
$ systemctl start maxscale
$ maxscale --version
MaxScale 2.4.10

W tym poście na blogu przedstawimy niektóre z godnych uwagi ulepszeń i nowych funkcji tej wersji oraz sposób, w jaki wygląda ona w działaniu. Pełną listę zmian w MariaDB MaxScale 2.4 znajdziesz w jej dzienniku zmian.

Historia poleceń trybu interaktywnego

Jest to w zasadzie niewielka poprawa, która ma duży wpływ na administrację MaxScale i wydajność zadań monitorowania. Tryb interaktywny dla MaxCtrl ma teraz swoją historię poleceń. Historia poleceń pozwala łatwo powtórzyć wykonane polecenie, naciskając klawisz strzałki w górę lub w dół. Jednak funkcja Ctrl+R (przywołaj ostatnie polecenie pasujące do podanych znaków) nadal nie istnieje.

W poprzednich wersjach trzeba było używać standardowego trybu powłoki, aby upewnić się, że polecenia są przechwytywane przez plik .bash_history.

Monitorowanie GTID dla galeramonu

Jest to dobre ulepszenie dla tych, którzy korzystają z Galera Cluster z geograficzną redundancją za pośrednictwem replikacji asynchronicznej, znanej również jako replikacja klastrów do klastrów lub replikacja MariaDB Galera Cluster przez replikację MariaDB.

W MaxScale 2.3 i starszych wygląda to tak, jeśli włączyłeś replikację master-slave między klastrami MariaDB:

W przypadku MaxScale 2.4 wygląda to teraz tak (zwróć uwagę na wiersz):

Teraz łatwiej jest zobaczyć stan replikacji dla wszystkich węzłów z MaxScale, bez konieczność wielokrotnego sprawdzania poszczególnych węzłów.

SmartRouter

Jest to jedna z nowych głównych funkcji w MaxScale 2.4, w której MaxScale jest teraz wystarczająco inteligentny, aby dowiedzieć się, który serwer zaplecza MariaDB najlepiej przetwarza zapytanie. SmartRouter śledzi wydajność lub czas wykonywania zapytań do klastrów. Pomiary są przechowywane, a kluczem jest kanon zapytania. Kanon zapytania to SQL ze wszystkimi stałymi zdefiniowanymi przez użytkownika zastąpionymi znakami zapytania, na przykład:

UPDATE `money_in` SET `accountholdername` = ? , `modifiedon` = ? , `status` = ? , `modifiedby` = ? WHERE `id` = ?

Jest to bardzo przydatna funkcja, jeśli używasz MariaDB w wielolokacyjnej replikacji geograficznej lub kombinacji silników pamięci masowej MariaDB w jednym łańcuchu replikacji, na przykład dedykowane urządzenie podrzędne do obsługi obciążeń transakcyjnych (OLTP ) z silnikiem pamięci masowej InnoDB i innym dedykowanym urządzeniem podrzędnym do obsługi obciążeń analitycznych (OLAP) za pomocą silnika pamięci masowej Columnstore.

Załóżmy, że mamy dwie witryny — Sydney i Singapur, jak pokazano na poniższym diagramie:

Główna witryna znajduje się w Singapurze i ma serwer główny MariaDB i element podrzędny , podczas gdy inny niewolnik tylko do odczytu znajduje się w Sydney. Aplikacja łączy się z instancją MaxScale znajdującą się w odpowiednim kraju z następującymi ustawieniami portu:

Podział odczytu i zapisu:3306
Okrągłe:3307
Inteligentny router:3308

Nasza usługa SmarRouter i definicje słuchaczy to:

[SmartQuery]
type=service
router=smartrouter
servers=DB_1,DB_2,DB_5
master=DB_1
user=maxscale
password=******

[SmartQuery-Listener]
type = listener
service = SmartQuery
protocol = mariadbclient
port = 3308

Zrestartuj MaxScale i zacznij wysyłać zapytanie tylko do odczytu do obu węzłów MaxScale znajdujących się w Singapurze i Sydney. Jeśli zapytanie jest przetwarzane przez router round-robin (port 3307), zobaczymy, że zapytanie jest kierowane na podstawie algorytmu round-robin:

(app)$ mysql -usbtest -p -h maxscale_sydney -P3307 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+--------------------+
| count(id) | @@hostname         |
+-----------+--------------------+
|   1000000 | mariadb_singapore2 |
+-----------+--------------------+

Na podstawie powyższego możemy stwierdzić, że firma MaxScale firmy Sydney przesłała powyższe zapytanie do naszego singapurskiego urządzenia podrzędnego, co nie jest najlepszą opcją routingu per se.

Gdy SmartRouter nasłuchuje na porcie 3308, zobaczymy, że zapytanie jest kierowane do najbliższego urządzenia podrzędnego w Sydney:

(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+-----------------+
| count(id) | @@hostname      |
+-----------+-----------------+
|   1000000 | mariadb_sydney1 |
+-----------+-----------------+

Jeśli to samo zapytanie zostanie wykonane w naszej witrynie w Singapurze, zostanie skierowane do urządzenia podrzędnego MariaDB znajdującego się w Singapurze:

(app)$ mysql -usbtest -p -h maxscale_singapore -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+--------------------+
| count(id) | @@hostname         |
+-----------+--------------------+
|   1000000 | mariadb_singapore2 |
+-----------+--------------------+

Jest jednak pewien haczyk. Gdy SmartRouter zobaczy zapytanie odczytu, którego kanoniczny nie był wcześniej widziany, wyśle zapytanie do wszystkich klastrów. Pierwsza odpowiedź z klastra wskaże ten klaster jako najlepszy dla tego kanonicznego. Również po otrzymaniu pierwszej odpowiedzi pozostałe zapytania są anulowane. Odpowiedź jest wysyłana do klienta, gdy wszystkie klastry odpowiedzą na zapytanie lub anulują.

Oznacza to, że aby śledzić zapytanie kanoniczne (zapytanie znormalizowane) i mierzyć jego wydajność, prawdopodobnie zobaczysz, że pierwsze zapytanie kończy się niepowodzeniem przy pierwszym wykonaniu, na przykład:

(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
ERROR 2013 (HY000) at line 1: Lost connection to MySQL server during query

Z dziennika ogólnego w MariaDB Sydney możemy stwierdzić, że pierwsze zapytanie (ID 74) zostało wykonane pomyślnie (połącz, zapytanie i zakończ), pomimo błędu „Utracono połączenie” z MaxScale:

  74 Connect  [email protected] as anonymous on 
  74 Query    SELECT COUNT(id),@@hostname FROM sbtest.sbtest1
  74 Quit

Podczas gdy identyczne kolejne zapytanie zostało poprawnie przetworzone i zwrócone z poprawną odpowiedzią:

(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+------------------------+
| count(id) | @@hostname             |
+-----------+------------------------+
|   1000000 | mariadb_sydney.cluster |
+-----------+------------------------+

Patrząc ponownie na dziennik ogólny w MariaDB Sydney (ID 75), te same zdarzenia przetwarzania miały miejsce, tak jak w przypadku pierwszego zapytania:

  75 Connect  [email protected] as anonymous on 
  75 Query    SELECT COUNT(id),@@hostname FROM sbtest.sbtest1
  75 Quit

Z tej obserwacji możemy wywnioskować, że czasami MaxScale musi zawieść pierwsze zapytanie, aby zmierzyć wydajność i stać się mądrzejszy w przypadku kolejnych identycznych zapytań. Twoja aplikacja musi być w stanie prawidłowo obsłużyć ten „pierwszy błąd” przed powrotem do klienta lub ponowną próbę transakcji.

Gniazdo UNIX dla serwera

Istnieje wiele sposobów łączenia się z działającym serwerem MySQL lub MariaDB. Można użyć standardowego sieciowego protokołu TCP/IP z adresem IP hosta i portem (połączenie zdalne), nazwanymi potokami/pamięcią współdzieloną w systemach Windows lub plikami typu socket Unix w systemach opartych na systemie Unix. Plik gniazda UNIX to specjalny rodzaj pliku, który ułatwia komunikację między różnymi procesami, czyli w tym przypadku klientem MySQL i serwerem. Plik gniazda jest komunikacją opartą na plikach i nie można uzyskać dostępu do gniazda z innego komputera. Zapewnia szybsze połączenie niż TCP/IP (brak obciążenia sieciowego) i bezpieczniejsze podejście do połączenia, ponieważ może być używane tylko podczas łączenia się z usługą lub procesem na tym samym komputerze.

Zakładając, że serwer MaxScale jest również zainstalowany na samym serwerze MariaDB, możemy zamiast tego użyć pliku gniazda typu socket UNIX. W sekcji Serwer usuń lub skomentuj wiersz „adres” i dodaj parametr gniazda z lokalizacją pliku gniazda:

[DB_2]
type=server
protocol=mariadbbackend
#address=54.255.133.39
socket=/var/lib/mysql/mysql.sock

Przed zastosowaniem powyższych zmian musimy utworzyć użytkownika MaxScale axscale z localhost. Na serwerze głównym:

MariaDB> CREATE USER 'maxscale'@'localhost' IDENTIFIED BY 'maxscalep4ss';
MariaDB> GRANT SELECT ON mysql.user TO 'maxscale'@'localhost';
MariaDB> GRANT SELECT ON mysql.db TO 'maxscale'@'localhost';
MariaDB> GRANT SELECT ON mysql.tables_priv TO 'maxscale'@'localhost';
MariaDB> GRANT SHOW DATABASES ON *.* TO 'maxscale'@'localhost';

Po restarcie MaxScale pokaże ścieżkę gniazda UNIX zamiast faktycznego adresu, a lista serwerów będzie pokazana w następujący sposób:

Jak widać, informacje o stanie i GTID są pobierane poprawnie przez połączenie z gniazdem. Zauważ, że ten DB_2 nadal nasłuchuje na porcie 3306 dla połączeń zdalnych. Pokazuje tylko, że MaxScale używa gniazda do łączenia się z tym serwerem w celu monitorowania.

Korzystanie z gniazda jest zawsze lepsze ze względu na to, że umożliwia tylko połączenia lokalne i jest bezpieczniejsze. Możesz także zamknąć serwer MariaDB z sieci (np. --skip-networking) i pozwolić MaxScale obsługiwać połączenia „zewnętrzne” i przekazywać je do serwera MariaDB za pośrednictwem pliku gniazda UNIX.

Opróżnianie serwera

W MaxScale 2.4 serwery zaplecza mogą zostać opróżnione, co oznacza, że istniejące połączenia mogą być nadal używane, ale żadne nowe połączenia nie zostaną utworzone z serwerem. Dzięki funkcji drenażu możemy wykonać wdzięczną czynność konserwacyjną bez wpływu na wrażenia użytkownika od strony aplikacji. Zwróć uwagę, że opróżnianie serwera może zająć więcej czasu, w zależności od uruchomionych zapytań, które muszą zostać bezpiecznie zamknięte.

Aby opróżnić serwer, użyj następującego polecenia:

Efekt wtórny może mieć jeden z następujących stanów:

Opróżnianie — serwer jest opróżniany.
Opróżniony — Serwer został opróżniony. Serwer był opróżniany i teraz liczba połączeń z serwerem spadła do 0.
Konserwacja — Serwer jest w trakcie konserwacji.

Po opróżnieniu serwera stan serwera MariaDB z punktu widzenia MaxScale to „Konserwacja”:

Gdy serwer jest w trybie konserwacji, żadne połączenia nie zostaną z nim utworzone, a istniejące połączenia zostaną zamknięte.

Wnioski

MaxScale 2.4 wprowadza wiele ulepszeń i zmian w stosunku do poprzedniej wersji i jest najlepszym serwerem proxy bazy danych do obsługi serwerów MariaDB i wszystkich jego komponentów.