MariaDB MaxScale to zaawansowany, plug-in serwer proxy bazy danych dla serwerów baz danych MariaDB. Znajduje się między aplikacjami klienckimi a serwerami baz danych, kierując zapytania klientów i odpowiedzi serwera. MaxScale monitoruje również serwery, dzięki czemu szybko zauważy zmiany stanu serwerów lub topologii replikacji. To sprawia, że MaxScale jest naturalnym wyborem do kontrolowania przełączania awaryjnego i podobnych funkcji.
W tej dwuczęściowej serii blogów przedstawimy pełny przewodnik po tym, jak uruchomić MariaDB MaxScale w Dockerze. Ta część obejmuje wdrożenie jako samodzielny kontener Docker i klastrowanie MaxScale za pośrednictwem Docker Swarm w celu zapewnienia wysokiej dostępności.
MariaDB MaxScale w Dockerze
W Docker Hub dostępnych jest wiele obrazów platformy Docker MariaDB. W tym blogu użyjemy oficjalnego obrazu utrzymywanego i publikowanego przez MariaDB o nazwie „mariadb/maxscale” (tag:najnowszy). Obraz ma rozmiar około 71 MB. W chwili pisania tego tekstu obraz jest preinstalowany z MaxScale 2.3.4 jako część wymaganych pakietów.
Ogólnie rzecz biorąc, następujące kroki są wymagane do uruchomienia MaxScale z tym obrazem w środowisku kontenera:
- Uruchomiona replikacja MariaDB (master-slave lub master-master)/klaster Galera lub klaster NDB
- Utwórz i przyznaj użytkownika bazy danych przeznaczonego do monitorowania MaxScale
- Przygotuj plik konfiguracyjny MaxScale
- Zmapuj plik konfiguracyjny do kontenera lub załaduj do Kubernetes ConfigMap lub Docker Swarm Configs
- Uruchom kontener/pod/usługę/replikę
Zauważ, że MaxScale jest produktem MariaDB, co oznacza, że jest dostosowany do serwera MariaDB. Większość funkcji jest nadal zgodna z MySQL, z wyjątkiem niektórych części, takich jak obsługa GTID, konfiguracja klastra Galera i wewnętrzne pliki danych. Wersja, której będziemy używać, to 2.3.4, wydana na licencji Business Source License (BSL). Pozwala na otwarcie całego kodu, a korzystanie z TRZECH serwerów jest bezpłatne. Gdy użycie przekracza trzy serwery zaplecza, firma, która z niego korzysta, musi zapłacić za komercyjną subskrypcję. Po określonym czasie (2 lata w przypadku MaxScale) wydanie przechodzi na GPL, a korzystanie z niego jest bezpłatne.
Żeby było jasne, ponieważ jest to środowisko testowe, możemy mieć więcej niż 2 węzły. Jak podano na stronie FAQ MariaDB BSL:
P:Czy mogę używać produktów MariaDB licencjonowanych w ramach BSL w środowisku testowym i programistycznym?
O:Tak, w nieprodukcyjnym środowisku testowym i programistycznym można używać produktów licencjonowanych w ramach BSL bez konieczności posiadania subskrypcji od MariaDB
W tym przewodniku mamy już trzywęzłową replikację MariaDB wdrożoną przy użyciu ClusterControl. Poniższy diagram ilustruje konfigurację, którą zamierzamy wdrożyć:
Nasza architektura systemu składa się z:
- mariadb1 - 192.168.0.91 (master)
- mariadb2 — 192.168.0.92 (niewolnik)
- mariadb3 — 192.168.0.93 (niewolnik)
- docker1 – 192.168.0.200 (host platformy Docker dla kontenerów – maxscale, aplikacja)
Przygotowywanie użytkownika MaxScale
Najpierw utwórz użytkownika bazy danych MySQL dla MaxScale i zezwól na wszystkie hosty w sieci 192.168.0.0/24:
MariaDB> CREATE USER 'maxscale'@'192.168.0.%' IDENTIFIED BY 'my_s3cret';Następnie nadaj wymagane uprawnienia. Jeśli chcesz tylko monitorować serwery zaplecza za pomocą równoważenia obciążenia, wystarczą następujące granty:
MariaDB> GRANT SHOW DATABASES ON *.* TO 'maxscale'@'192.168.0.%';
MariaDB> GRANT SELECT ON `mysql`.* TO 'maxscale'@'192.168.0.%';Jednak MaxScale potrafi znacznie więcej niż tylko routing zapytań. Ma zdolność do przełączania awaryjnego i przełączania, na przykład promowania slave'a na nowego mastera. Wymaga to uprawnień SUPER i REPLICATION CLIENT. Jeśli chcesz skorzystać z tej funkcji, zamiast tego przypisz WSZYSTKIE UPRAWNIENIA użytkownikowi:
mysql> GRANT ALL PRIVILEGES ON *.* TO [email protected]'192.168.0.%';To tyle, jeśli chodzi o część użytkownika.
Przygotowywanie pliku konfiguracyjnego MaxScale
Obraz wymaga zmapowania działającego pliku konfiguracyjnego do kontenera przed jego uruchomieniem. Minimalny plik konfiguracyjny dostarczony w kontenerze nie pomoże nam zbudować odwrotnego proxy, którego potrzebujemy. Dlatego plik konfiguracyjny musi być przygotowany wcześniej.
Poniższa lista może nam pomóc w zebraniu podstawowych informacji niezbędnych do skonstruowania naszego pliku konfiguracyjnego:
- Typ klastra — MaxScale obsługuje replikację MariaDB (master-slave, master-master), Galera Cluster, Amazon Aurora, MariaDB ColumnStore i NDB Cluster (znany również jako MySQL Cluster).
- Adres IP zaplecza i/lub nazwa hosta — osiągalny adres IP lub nazwa hosta dla wszystkich serwerów zaplecza.
- Algorytm routingu — MaxScale obsługuje dwa typy routingu zapytań — dzielenie odczytu i zapisu oraz równoważenie obciążenia w trybie round-robin.
- Port do nasłuchiwania przez MaxScale — domyślnie MaxScale używa portu 4006 do połączeń okrężnych i 4008 do połączeń dzielonych do odczytu i zapisu. Możesz użyć gniazda UNIX, jeśli chcesz.
W bieżącym katalogu utwórz plik tekstowy o nazwie maxscale.cnf, abyśmy mogli zmapować go do kontenera podczas uruchamiania. Wklej następujące wiersze do pliku:
########################
## Server list
########################
[mariadb1]
type = server
address = 192.168.0.91
port = 3306
protocol = MariaDBBackend
serv_weight = 1
[mariadb2]
type = server
address = 192.168.0.92
port = 3306
protocol = MariaDBBackend
serv_weight = 1
[mariadb3]
type = server
address = 192.168.0.93
port = 3306
protocol = MariaDBBackend
serv_weight = 1
#########################
## MaxScale configuration
#########################
[maxscale]
threads = auto
log_augmentation = 1
ms_timestamp = 1
syslog = 1
#########################
# Monitor for the servers
#########################
[monitor]
type = monitor
module = mariadbmon
servers = mariadb1,mariadb2,mariadb3
user = maxscale
password = my_s3cret
auto_failover = true
auto_rejoin = true
enforce_read_only_slaves = 1
#########################
## Service definitions for read/write splitting and read-only services.
#########################
[rw-service]
type = service
router = readwritesplit
servers = mariadb1,mariadb2,mariadb3
user = maxscale
password = my_s3cret
max_slave_connections = 100%
max_sescmd_history = 1500
causal_reads = true
causal_reads_timeout = 10
transaction_replay = true
transaction_replay_max_size = 1Mi
delayed_retry = true
master_reconnection = true
master_failure_mode = fail_on_write
max_slave_replication_lag = 3
[rr-service]
type = service
router = readconnroute
servers = mariadb1,mariadb2,mariadb3
router_options = slave
user = maxscale
password = my_s3cret
##########################
## Listener definitions for the service
## Listeners represent the ports the service will listen on.
##########################
[rw-listener]
type = listener
service = rw-service
protocol = MariaDBClient
port = 4008
[ro-listener]
type = listener
service = rr-service
protocol = MariaDBClient
port = 4006Trochę wyjaśnień dla każdej sekcji:
- Lista serwerów — serwery zaplecza. Zdefiniuj każdy serwer MariaDB tego klastra we własnej sekcji. Nazwa sekcji zostanie użyta, gdy określimy definicję usługi w dalszej części. Typem komponentu musi być „serwer”.
- Konfiguracja MaxScale - Zdefiniuj tam wszystkie konfiguracje związane z MaxScale.
- Moduł Monitor — Jak MaxScale powinien monitorować serwery zaplecza. Typem komponentu musi być „monitor”, po którym następuje jeden z modułów monitorujących. Aby zapoznać się z listą obsługiwanych monitorów, zobacz Monitory MaxScale 2.3.
- Usługa — dokąd skierować zapytanie. Typem komponentu musi być „usługa”. Lista obsługiwanych routerów znajduje się w MaxScale 2.3 Routery.
- Listener - Jak MaxScale powinien nasłuchiwać połączeń przychodzących. Może to być plik portu lub gniazda. Typem komponentu musi być „odbiornik”. Zazwyczaj słuchacze są związani z usługami.
Zasadniczo chcielibyśmy, aby MaxScale nasłuchiwał na dwóch portach, 4006 i 4008. Port 4006 jest przeznaczony specjalnie do połączeń typu round-robin, odpowiedni dla obciążeń tylko do odczytu dla naszej replikacji MariaDB, podczas gdy port 4008 jest przeznaczony specjalnie do krytycznych obciążeń odczytu i zapisu. Chcemy również użyć MaxScale do wykonania akcji naszej replikacji w przypadku awarii, przełączenia lub ponownego dołączenia urządzenia podrzędnego, dlatego używamy modułu monitorującego o nazwie „mariadbmon”.
Uruchamianie kontenera
Jesteśmy teraz gotowi do uruchomienia naszego samodzielnego kontenera MaxScale. Zmapuj plik konfiguracyjny z -v i upewnij się, że publikujesz oba porty nasłuchiwania 4006 i 4008. Opcjonalnie możesz włączyć interfejs MaxScale REST API na porcie 8989:
$ docker run -d \
--name maxscale \
--restart always \
-p 4006:4006 \
-p 4008:4008 \
-p 8989:8989 \
-v $PWD/maxscale.cnf:/etc/maxscale.cnf \
mariadb/maxscaleZweryfikuj za pomocą:
$ docker logs -f maxscale
...
2019-06-14 07:15:41.060 notice : (main): Started REST API on [127.0.0.1]:8989
2019-06-14 07:15:41.060 notice : (main): MaxScale started with 8 worker threads, each with a stack size of 8388608 bytes.Upewnij się, że nie widzisz błędów podczas przeglądania powyższych dzienników. Sprawdź, czy procesy docker-proxy nasłuchują na opublikowanych portach - 4006, 4008 i 8989:
$ netstat -tulpn | grep docker-proxy
tcp6 0 0 :::8989 :::* LISTEN 4064/docker-proxy
tcp6 0 0 :::4006 :::* LISTEN 4092/docker-proxy
tcp6 0 0 :::4008 :::* LISTEN 4078/docker-proxyW tym momencie nasza MaxScale działa i może przetwarzać zapytania.
MaxCtrl
MaxCtrl to klient administracyjny wiersza poleceń dla MaxScale, który do komunikacji używa interfejsu API MaxScale REST. Jest to oprogramowanie zastępujące starszego klienta wiersza poleceń MaxAdmin.
Aby przejść do konsoli MaxCtrl, wykonaj polecenie „maxctrl” w kontenerze:
$ docker exec -it maxscale maxctrl
maxctrl: list servers
┌──────────┬──────────────┬──────┬─────────────┬─────────────────┬─────────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │
├──────────┼──────────────┼──────┼─────────────┼─────────────────┼─────────────┤
│ mariadb1 │ 192.168.0.91 │ 3306 │ 0 │ Master, Running │ 0-5001-1012 │
├──────────┼──────────────┼──────┼─────────────┼─────────────────┼─────────────┤
│ mariadb2 │ 192.168.0.92 │ 3306 │ 0 │ Slave, Running │ 0-5001-1012 │
├──────────┼──────────────┼──────┼─────────────┼─────────────────┼─────────────┤
│ mariadb3 │ 192.168.0.93 │ 3306 │ 0 │ Slave, Running │ 0-5001-1012 │
└──────────┴──────────────┴──────┴─────────────┴─────────────────┴─────────────┘Aby sprawdzić, czy wszystko jest w porządku, po prostu uruchom następujące polecenia:
maxctrl: list servers
maxctrl: list services
maxctrl: list filters
maxctrl: list sessionsAby uzyskać więcej informacji o każdym komponencie, zamiast tego poprzedź prefiks poleceniem „show”, na przykład:
maxctrl: show servers
┌──────────────────┬──────────────────────────────────────────┐
│ Server │ mariadb3 │
├──────────────────┼──────────────────────────────────────────┤
│ Address │ 192.168.0.93 │
├──────────────────┼──────────────────────────────────────────┤
│ Port │ 3306 │
├──────────────────┼──────────────────────────────────────────┤
│ State │ Slave, Running │
├──────────────────┼──────────────────────────────────────────┤
│ Last Event │ new_slave │
├──────────────────┼──────────────────────────────────────────┤
│ Triggered At │ Mon, 17 Jun 2019 08:57:59 GMT │
├──────────────────┼──────────────────────────────────────────┤
│ Services │ rw-service │
│ │ rr-service │
├──────────────────┼──────────────────────────────────────────┤
│ Monitors │ monitor │
├──────────────────┼──────────────────────────────────────────┤
│ Master ID │ 5001 │
├──────────────────┼──────────────────────────────────────────┤
│ Node ID │ 5003 │
├──────────────────┼──────────────────────────────────────────┤
│ Slave Server IDs │ │
├──────────────────┼──────────────────────────────────────────┤
│ Statistics │ { │
│ │ "connections": 0, │
│ │ "total_connections": 0, │
│ │ "persistent_connections": 0, │
│ │ "active_operations": 0, │
│ │ "routed_packets": 0, │
│ │ "adaptive_avg_select_time": "0ns" │
│ │ } │
├──────────────────┼──────────────────────────────────────────┤
│ Parameters │ { │
│ │ "address": "192.168.0.93", │
│ │ "protocol": "MariaDBBackend", │
│ │ "port": 3306, │
│ │ "extra_port": 0, │
│ │ "authenticator": null, │
│ │ "monitoruser": null, │
│ │ "monitorpw": null, │
│ │ "persistpoolmax": 0, │
│ │ "persistmaxtime": 0, │
│ │ "proxy_protocol": false, │
│ │ "ssl": "false", │
│ │ "ssl_cert": null, │
│ │ "ssl_key": null, │
│ │ "ssl_ca_cert": null, │
│ │ "ssl_version": "MAX", │
│ │ "ssl_cert_verify_depth": 9, │
│ │ "ssl_verify_peer_certificate": true, │
│ │ "disk_space_threshold": null, │
│ │ "type": "server", │
│ │ "serv_weight": "1" │
│ │ } │
└──────────────────┴──────────────────────────────────────────┘Łączenie z bazą danych
Użytkownik bazy danych aplikacji musi mieć przyznany host MaxScale, ponieważ z punktu widzenia serwera MariaDB widzi tylko hosta MaxScale. Rozważmy następujący przykład bez MaxScale na obrazku:
- Nazwa bazy danych:mojaaplikacja
- Użytkownik:myapp_user
- Host:192.168.0.133 (serwer aplikacji)
Aby umożliwić użytkownikowi dostęp do bazy danych na serwerze MariaDB, należy uruchomić następującą instrukcję:
MariaDB> CREATE USER 'myapp_user'@'192.168.0.133' IDENTIFIED BY 'mypassword';
MariaDB> GRANT ALL PRIVILEGES ON myapp.* to 'myapp_user'@'192.168.0.133';Mając MaxScale na obrazku, należy zamiast tego uruchomić następującą instrukcję (zamień adres IP serwera aplikacji na adres IP MaxScale, 192.168.0.200):
MariaDB> CREATE USER 'myapp_user'@'192.168.0.200' IDENTIFIED BY 'mypassword';
MariaDB> GRANT ALL PRIVILEGES ON myapp.* to 'myapp_user'@'192.168.0.200';Z aplikacji dostępne są dwa porty, których można użyć do połączenia z bazą danych:
- 4006 — Odbiornik okrężny, odpowiedni dla obciążeń tylko do odczytu.
- 4008 — Odbiornik z podziałem odczytu i zapisu, odpowiedni do zadań związanych z zapisem.
Jeśli Twoja aplikacja może określić tylko jeden port MySQL (np. Wordpress, Joomla, itp.), zamiast tego wybierz port RW 4008. Jest to najbezpieczniejsze połączenie z punktem końcowym, niezależnie od typu klastra. Jeśli jednak Twoja aplikacja może obsługiwać połączenia z wieloma portami MySQL, możesz wysyłać odczyty do odbiornika round-robin. Ten odbiornik ma mniej narzutów i jest znacznie szybszy w porównaniu z odbiornikiem dzielonym do odczytu i zapisu.
W przypadku naszej konfiguracji replikacji MariaDB połącz się z jednym z tych punktów końcowych jako kombinacją host/port bazy danych:
- 192.168.0.200 port 4008 — MaxScale — tylko do odczytu/zapisu lub tylko do zapisu
- 192.168.0.200 port 4006 — MaxScale — zrównoważony tylko do odczytu
- 192.168.0.91 port 3306 — serwer MariaDB (master) — odczyt/zapis
- 192.168.0.92 port 3306 — MariaDB Server (slave) — tylko do odczytu
- 192.168.0.93 port 3306 — MariaDB Server (slave) — tylko do odczytu
Uwaga w przypadku klastrów z wieloma masterami, takich jak klaster Galera i klaster NDB, port 4006 może być używany zamiast połączeń symetrycznych z wieloma zapisami. Dzięki MaxScale masz wiele opcji do wyboru podczas łączenia się z bazą danych, a każda z nich zapewnia własny zestaw zalet.
Klastrowanie MaxScale z Docker Swarm
Dzięki Docker Swarm możemy stworzyć grupę instancji MaxScale za pośrednictwem usługi Swarm z więcej niż jedną repliką wraz z Swarm Configs. Najpierw zaimportuj plik konfiguracyjny do Swarm:
$ cat maxscale.conf | docker config create maxscale_config -Zweryfikuj za pomocą:
$ docker config inspect --pretty maxscale_configNastępnie zezwól użytkownikowi bazy danych MaxScale na łączenie się z dowolnego hosta Swarm w sieci:
MariaDB> CREATE USER 'maxscale'@'192.168.0.%' IDENTIFIED BY 'my_s3cret';
MariaDB> GRANT ALL PRIVILEGES ON *.* TO [email protected]'192.168.0.%';Podczas uruchamiania usługi Swarm dla MaxScale możemy utworzyć wiele kontenerów (zwanych replikami) mapujących do tego samego pliku konfiguracyjnego, jak poniżej:
$ docker service create \
--name maxscale-cluster \
--replicas=3 \
--publish published=4008,target=4008 \
--publish published=4006,target=4006 \
--config source=maxscale_config,target=/etc/maxscale.cnf \
mariadb/maxscalePowyższe spowoduje utworzenie trzech kontenerów MaxScale rozmieszczonych w węzłach Swarm. Zweryfikuj za pomocą:
$ docker service ls
ID NAME MODE REPLICAS IMAGE PORTS
yj6u2xcdj7lo maxscale-cluster replicated 3/3 mariadb/maxscale:latest *:4006->4006/tcp, *:4008->4008/tcpJeśli aplikacje działają w sieci Swarm, możesz po prostu użyć nazwy usługi „maxscale-cluster” jako hosta bazy danych dla aplikacji. Zewnętrznie możesz połączyć się z dowolnym hostem platformy Docker na opublikowanych portach, a sieć Swarm będzie kierować i równoważyć połączenia z odpowiednimi kontenerami w sposób okrężny. W tym momencie naszą architekturę można zilustrować jak poniżej:
W drugiej części przyjrzymy się zaawansowanym przypadkom użycia MaxScale na platformie Docker, takich jak kontrola usług, zarządzanie konfiguracją, przetwarzanie zapytań, bezpieczeństwo i uzgadnianie klastrów.
