Uruchamianie klastra MariaDB Galera bez narzędzi do orkiestracji — Zarządzanie kontenerami DB:część druga

Jak widzieliśmy w pierwszej części tego bloga, silnie spójny klaster baz danych, taki jak Galera, nie współpracuje dobrze z narzędziami do orkiestracji kontenerów, takimi jak Kubernetes czy Swarm. Pokazaliśmy, jak wdrożyć Galerę i skonfigurować zarządzanie procesami dla Dockera, aby zachować pełną kontrolę nad zachowaniem. Ten wpis na blogu jest kontynuacją tego, przyjrzymy się działaniu i utrzymaniu klastra.

Aby podsumować niektóre z głównych punktów z części 1 tego bloga, wdrożyliśmy trzywęzłowy klaster Galera z ProxySQL i Keepalived na trzech różnych hostach platformy Docker, gdzie wszystkie instancje MariaDB działają jako kontenery platformy Docker. Poniższy diagram ilustruje ostateczne wdrożenie:

Prawne zamknięcie

Aby wykonać bezpieczne zamknięcie MySQL, najlepszym sposobem jest wysłanie SIGTERM (sygnał 15) do kontenera:

$ docker kill -s 15 {db_container_name}

Jeśli chcesz zamknąć klaster, powtórz powyższe polecenie dla wszystkich kontenerów bazy danych, po jednym węźle na raz. Powyższe jest podobne do wykonywania "systemctl stop mysql" w usłudze systemd dla MariaDB. Użycie polecenia „docker stop” jest dość ryzykowne dla usługi bazy danych, ponieważ czeka ona przez 10 sekund limitu czasu, a Docker wymusi SIGKILL, jeśli ten czas zostanie przekroczony (chyba że użyjesz prawidłowego --timeout wartość).

Ostatni węzeł, który zostanie poprawnie zamknięty, będzie miał seqno nie równa -1 i safe_to_bootstrap flaga jest ustawiona na 1 w /{datadir volume}/grastate.dat hosta Docker, na przykład na hoście2:

$ cat /containers/mariadb2/datadir/grastate.dat
# GALERA saved state
version: 2.1
uuid:    e70b7437-645f-11e8-9f44-5b204e58220b
seqno:   7099
safe_to_bootstrap: 1

Wykrywanie najbardziej zaawansowanego węzła

Jeśli klaster nie został poprawnie zamknięty lub węzeł, który próbujesz załadować, nie był ostatnim węzłem, który opuścił klaster, prawdopodobnie nie będziesz w stanie załadować jednego z węzłów Galera i może wystąpić następujący błąd :

2016-11-07 01:49:19 5572 [ERROR] WSREP: It may not be safe to bootstrap the cluster from this node.
It was not the last one to leave the cluster and may not contain all the updates.
To force cluster bootstrap with this node, edit the grastate.dat file manually and set safe_to_bootstrap to 1 .

Galera honoruje węzeł, który ma safe_to_bootstrap flaga ustawiona na 1 jako pierwszy węzeł odniesienia. Jest to najbezpieczniejszy sposób na uniknięcie utraty danych i zapewnienie, że prawidłowy węzeł zawsze zostanie załadowany.

Jeśli pojawił się błąd, musimy najpierw znaleźć najbardziej zaawansowany węzeł, zanim wybierzemy go jako pierwszego do załadowania. Utwórz przejściowy kontener (za pomocą --rm flaga), zmapuj go na ten sam katalog danych i katalog konfiguracyjny rzeczywistego kontenera bazy danych za pomocą dwóch flag poleceń MySQL, --wsrep_recover i --wsrep_cluster_address . Na przykład, jeśli chcemy poznać ostatnią zadeklarowaną liczbę mariadb1, musimy uruchomić:

$ docker run --rm --name mariadb-recover \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --volume /containers/mariadb1/datadir:/var/lib/mysql \
        --volume /containers/mariadb1/conf.d:/etc/mysql/conf.d \
        mariadb:10.2.15 \
        --wsrep_recover \
        --wsrep_cluster_address=gcomm://
2018-06-12  4:46:35 139993094592384 [Note] mysqld (mysqld 10.2.15-MariaDB-10.2.15+maria~jessie) starting as process 1 ...
2018-06-12  4:46:35 139993094592384 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
...
2018-06-12  4:46:35 139993094592384 [Note] Plugin 'FEEDBACK' is disabled.
2018-06-12  4:46:35 139993094592384 [Note] Server socket created on IP: '::'.
2018-06-12  4:46:35 139993094592384 [Note] WSREP: Recovered position: e70b7437-645f-11e8-9f44-5b204e58220b:7099

Ostatnia linijka jest tym, czego szukamy. MariaDB drukuje identyfikator UUID klastra i numer sekwencyjny ostatniej zatwierdzonej transakcji. Węzeł, który posiada najwyższy numer, jest uważany za najbardziej zaawansowany węzeł. Ponieważ określiliśmy --rm , kontener zostanie automatycznie usunięty po wyjściu. Powtórz powyższy krok na każdym hoście platformy Docker, zastępując --volume ścieżka do odpowiednich woluminów kontenera bazy danych.

Po porównaniu wartości zgłaszanych przez wszystkie kontenery bazy danych i podjęciu decyzji, który kontener jest najbardziej aktualnym węzłem, zmień safe_to_bootstrap flaga na 1 wewnątrz /{datadir volume}/grastate.dat ręcznie. Załóżmy, że wszystkie węzły zgłaszają ten sam dokładny numer sekwencji, możemy po prostu wybrać mariadb3 do załadowania, zmieniając safe_to_bootstrap wartość do 1:

$ vim /containers/mariadb3/datadir/grasate.dat
...
safe_to_bootstrap: 1

Zapisz plik i rozpocznij ładowanie klastra z tego węzła, jak opisano w następnym rozdziale.

Rozruch klastra

Uruchamianie klastra jest podobne do pierwszego polecenia uruchomienia platformy docker, którego użyliśmy podczas pierwszego uruchamiania klastra. Jeśli mariadb1 jest wybranym węzłem ładowania początkowego, możemy po prostu ponownie uruchomić utworzony kontener ładowania początkowego:

$ docker start mariadb0 # on host1

W przeciwnym razie, jeśli kontener ładowania początkowego nie istnieje w wybranym węźle, powiedzmy na hoście2, uruchom polecenie kontenera ładowania początkowego i zmapuj istniejące woluminy mariadb2. Używamy mariadb0 jako nazwy kontenera na hoście 2, aby wskazać, że jest to kontener ładowania początkowego:

$ docker run -d \
        --name mariadb0 \
        --hostname mariadb0.weave.local \
        --net weave \
        --publish "3306" \
        --publish "4444" \
        --publish "4567" \
        --publish "4568" \
        $(weave dns-args) \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --volume /containers/mariadb2/datadir:/var/lib/mysql \
        --volume /containers/mariadb2/conf.d:/etc/mysql/mariadb.conf.d \
        mariadb:10.2.15 \
        --wsrep_cluster_address=gcomm:// \
        --wsrep_sst_auth="root:PM7%[email protected]^1" \
        --wsrep_node_address=mariadb0.weave.local

Możesz zauważyć, że to polecenie jest nieco krótsze w porównaniu do poprzedniego polecenia ładowania początkowego opisanego w tym przewodniku. Ponieważ mamy już użytkownika proxysql utworzonego w naszym pierwszym poleceniu ładowania początkowego, możemy pominąć te dwie zmienne środowiskowe:

• --env MYSQL_USER=proxysql
• --env MYSQL_PASSWORD=hasło proxy

Następnie uruchom pozostałe kontenery MariaDB, usuń kontener ładowania początkowego i uruchom istniejący kontener MariaDB na hoście ładowanym. Zasadniczo kolejność poleceń byłaby:

$ docker start mariadb1 # on host1
$ docker start mariadb3 # on host3
$ docker stop mariadb0 # on host2
$ docker start mariadb2 # on host2

W tym momencie klaster jest uruchamiany i działa z pełną wydajnością.

Kontrola zasobów

Pamięć jest bardzo ważnym zasobem w MySQL. To tutaj przechowywane są bufory i pamięci podręczne, a dla MySQL kluczowe jest zmniejszenie wpływu zbyt częstego uderzania w dysk. Z drugiej strony zamiana jest zła dla wydajności MySQL. Domyślnie działające kontenery nie będą ograniczać zasobów. Kontenery wykorzystują tyle danego zasobu, na ile pozwala jądro hosta. Kolejną ważną rzeczą jest ograniczenie deskryptorów plików. Możesz zwiększyć limit deskryptorów otwartych plików lub "nofile" do czegoś wyższego, aby zaspokoić liczbę plików, które serwer MySQL może otworzyć jednocześnie. Ustawienie wysokiej wartości nie zaszkodzi.

Aby ograniczyć alokację pamięci i zwiększyć limit deskryptorów plików do naszego kontenera bazy danych, należy dołączyć --memory , --zamień-pamięci i --ulimit parametry do polecenia „docker run”:

$ docker kill -s 15 mariadb1
$ docker rm -f mariadb1
$ docker run -d \
        --name mariadb1 \
        --hostname mariadb1.weave.local \
        --net weave \
        --publish "3306:3306" \
        --publish "4444" \
        --publish "4567" \
        --publish "4568" \
        $(weave dns-args) \
        --memory 16g \
        --memory-swap 16g \
        --ulimit nofile:16000:16000 \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --volume /containers/mariadb1/datadir:/var/lib/mysql \
        --volume /containers/mariadb1/conf.d:/etc/mysql/mariadb.conf.d \
        mariadb:10.2.15 \
        --wsrep_cluster_address=gcomm://mariadb0.weave.local,mariadb1.weave.local,mariadb2.weave.local,mariadb3.weave.local \
        --wsrep_sst_auth="root:PM7%[email protected]^1" \
        --wsrep_node_address=mariadb1.weave.local

Zwróć uwagę, że jeśli --memory-swap ma taką samą wartość jak --memory i --pamięć jest ustawiona na dodatnią liczbę całkowitą, kontener nie będzie miał dostępu do wymiany. Jeśli --memory-swap nie jest ustawiona, zamiana kontenera będzie domyślnie ustawiona na --memory pomnóż przez 2. Jeśli --memory i --memory-swap są ustawione na tę samą wartość, co uniemożliwi kontenerom korzystanie z jakiejkolwiek wymiany. Dzieje się tak, ponieważ --memory-swap to ilość połączonej pamięci i wymiany, której można użyć, podczas gdy --memory to tylko ilość pamięci fizycznej, którą można wykorzystać.

Niektóre zasoby kontenera, takie jak pamięć i procesor, mogą być kontrolowane dynamicznie za pomocą polecenia „aktualizacja platformy dokującej”, jak pokazano w poniższym przykładzie, aby zaktualizować pamięć kontenera mariadb1 do 32G w locie:

$ docker update \
    --memory 32g \
    --memory-swap 32g \
    mariadb1

Nie zapomnij odpowiednio dostroić my.cnf do nowych specyfikacji. Zarządzanie konfiguracją jest wyjaśnione w następnej sekcji.

Zarządzanie konfiguracją

Większość parametrów konfiguracyjnych MySQL/MariaDB można zmienić w czasie wykonywania, co oznacza, że ​​nie trzeba ponownie uruchamiać, aby zastosować zmiany. Sprawdź stronę dokumentacji MariaDB, aby uzyskać szczegółowe informacje. Parametr wymieniony z „Dynamiczny:Tak” oznacza, że ​​zmienna jest ładowana natychmiast po zmianie, bez konieczności ponownego uruchamiania serwera MariaDB. W przeciwnym razie ustaw parametry w niestandardowym pliku konfiguracyjnym na hoście platformy Docker. Na przykład w mariadb3 wprowadź zmiany w następującym pliku:

$ vim /containers/mariadb3/conf.d/my.cnf

A następnie uruchom ponownie kontener bazy danych, aby zastosować zmianę:

$ docker restart mariadb3

Sprawdź, czy kontener uruchamia proces, przeglądając dzienniki dockera. Wykonaj tę operację na jednym węźle naraz, jeśli chcesz wprowadzić zmiany w całym klastrze.

Kopia zapasowa

Wykonanie logicznej kopii zapasowej jest dość proste, ponieważ obraz MariaDB jest również dostarczany z plikiem binarnym mysqldump. Wystarczy użyć polecenia „docker exec”, aby uruchomić mysqldump i wysłać dane wyjściowe do pliku względem ścieżki hosta. Następujące polecenie wykonuje kopię zapasową mysqldump na mariadb2 i zapisuje ją w /backups/mariadb2 wewnątrz hosta2:

$ docker exec -it mariadb2 mysqldump -uroot -p --single-transaction > /backups/mariadb2/dump.sql

Kopia zapasowa binarna, taka jak Percona Xtrabackup lub MariaDB Backup, wymaga bezpośredniego dostępu do katalogu danych MariaDB. Musisz zainstalować to narzędzie w kontenerze lub za pośrednictwem hosta maszyny lub użyć do tego celu dedykowanego obrazu, takiego jak obraz „perconalab/percona-xtrabackup”, aby utworzyć kopię zapasową i zapisać ją w /tmp/backup na hoście Docker:

$ docker run --rm -it \
    -v /containers/mariadb2/datadir:/var/lib/mysql \
    -v /tmp/backup:/xtrabackup_backupfiles \
    perconalab/percona-xtrabackup \
    --backup --host=mariadb2 --user=root --password=mypassword

Możesz także zatrzymać kontener za pomocą innodb_fast_shutdown ustaw na 0 i skopiuj wolumin datadir do innej lokalizacji na fizycznym hoście:

$ docker exec -it mariadb2 mysql -uroot -p -e 'SET GLOBAL innodb_fast_shutdown = 0'
$ docker kill -s 15 mariadb2
$ cp -Rf /containers/mariadb2/datadir /backups/mariadb2/datadir_copied
$ docker start mariadb2

Przywróć

Przywracanie jest dość proste dla mysqldump. Możesz po prostu przekierować standardowe wejście do kontenera z fizycznego hosta:

$ docker exec -it mariadb2 mysql -uroot -p < /backups/mariadb2/dump.sql

Możesz także zdalnie użyć standardowego wiersza poleceń klienta mysql z odpowiednią nazwą hosta i wartością portu zamiast tego polecenia "docker exec":

$ mysql -uroot -p -h127.0.0.1 -P3306 < /backups/mariadb2/dump.sql

W przypadku Percona Xtrabackup i MariaDB Backup musimy wcześniej przygotować kopię zapasową. Spowoduje to przewinięcie kopii zapasowej do czasu zakończenia tworzenia kopii zapasowej. Powiedzmy, że nasze pliki Xtrabackup znajdują się w /tmp/backup na hoście Docker, aby je przygotować, po prostu:

$ docker run --rm -it \
    -v mysql-datadir:/var/lib/mysql \
    -v /tmp/backup:/xtrabackup_backupfiles \
    perconalab/percona-xtrabackup \
    --prepare --target-dir /xtrabackup_backupfiles

Przygotowaną kopię zapasową w katalogu /tmp/backup hosta platformy Docker można następnie wykorzystać jako katalog danych MariaDB dla nowego kontenera lub klastra. Załóżmy, że chcemy tylko zweryfikować przywracanie na samodzielnym kontenerze MariaDB, uruchomilibyśmy:

$ docker run -d \
    --name mariadb-restored \
    --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
    -v /tmp/backup:/var/lib/mysql \
    mariadb:10.2.15

Jeśli wykonałeś kopię zapasową przy użyciu metody zatrzymania i kopiowania, możesz po prostu zduplikować katalog danych i użyć zduplikowanego katalogu jako mapowania woluminu do katalogu danych MariaDB w celu uruchomienia w innym kontenerze. Załóżmy, że kopia zapasowa została skopiowana do /backups/mariadb2/datadir_copied, możemy uruchomić nowy kontener, uruchamiając:

$ mkdir -p /containers/mariadb-restored/datadir
$ cp -Rf /backups/mariadb2/datadir_copied /containers/mariadb-restored/datadir
$ docker run -d \
    --name mariadb-restored \
    --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
    -v /containers/mariadb-restored/datadir:/var/lib/mysql \
    mariadb:10.2.15

MYSQL_ROOT_PASSWORD musi pasować do aktualnego hasła roota dla tej konkretnej kopii zapasowej.

Aktualizacja wersji bazy danych

Istnieją dwa rodzaje uaktualnienia - uaktualnienie w miejscu lub uaktualnienie logiczne.

Uaktualnienie w miejscu obejmuje zamknięcie serwera MariaDB, zastąpienie starych plików binarnych nowymi, a następnie uruchomienie serwera w starym katalogu danych. Po uruchomieniu musisz uruchomić mysql_upgrade skrypt sprawdzający i aktualizujący wszystkie tabele systemowe, a także sprawdzający tabele użytkowników.

Uaktualnienie logiczne obejmuje wyeksportowanie SQL z bieżącej wersji za pomocą logicznego narzędzia do tworzenia kopii zapasowych, takiego jak mysqldump, uruchomienie nowego kontenera z plikami binarnymi zaktualizowanej wersji, a następnie zastosowanie SQL do nowej wersji MySQL/MariaDB. Jest to podobne do podejścia do tworzenia kopii zapasowych i przywracania opisanego w poprzedniej sekcji.

Niemniej jednak dobrym podejściem jest wykonanie kopii zapasowej bazy danych przed wykonaniem jakichkolwiek destrukcyjnych operacji. Następujące kroki są wymagane podczas uaktualniania z bieżącego obrazu, MariaDB 10.1.33 do innej głównej wersji, MariaDB 10.2.15 na mariadb3 znajduje się na hoście3:

0. Wykonaj kopię zapasową bazy danych. Nie ma znaczenia fizyczna czy logiczna kopia zapasowa, ale ta ostatnia przy użyciu mysqldump jest zalecana.

1. Pobierz najnowszy obraz, do którego chcielibyśmy uaktualnić:

   $ docker pull mariadb:10.2.15

2. Ustaw innodb_fast_shutdown na 0 dla naszego kontenera bazy danych:

   $ docker exec -it mariadb3 mysql -uroot -p -e 'SET GLOBAL innodb_fast_shutdown = 0'

3. Pełen wdzięku zamknij kontener bazy danych:

   $ docker kill --signal=TERM mariadb3

4. Utwórz nowy kontener z nowym obrazem dla naszego kontenera bazy danych. Zachowaj pozostałe parametry bez zmian, z wyjątkiem używania nowej nazwy kontenera (w przeciwnym razie byłoby to sprzeczne):

   $ docker run -d \
           --name mariadb3-new \
           --hostname mariadb3.weave.local \
           --net weave \
           --publish "3306:3306" \
           --publish "4444" \
           --publish "4567" \
           --publish "4568" \
           $(weave dns-args) \
           --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
           --volume /containers/mariadb3/datadir:/var/lib/mysql \
           --volume /containers/mariadb3/conf.d:/etc/mysql/mariadb.conf.d \
           mariadb:10.2.15 \
           --wsrep_cluster_address=gcomm://mariadb0.weave.local,mariadb1.weave.local,mariadb2.weave.local,mariadb3.weave.local \
           --wsrep_sst_auth="root:PM7%[email protected]^1" \
           --wsrep_node_address=mariadb3.weave.local

5. Uruchom skrypt mysql_upgrade:

   $ docker exec -it mariadb3-new mysql_upgrade -uroot -p

6. Jeśli nie wystąpiły żadne błędy, usuń stary kontener mariadb3 (nowy to mariadb3-new):

   $ docker rm -f mariadb3

7. W przeciwnym razie, jeśli proces aktualizacji się nie powiedzie, możemy wrócić do poprzedniego kontenera:

   $ docker stop mariadb3-new
   $ docker start mariadb3

Aktualizacja wersji głównej może być wykonana podobnie do aktualizacji wersji drugorzędnej, z tym wyjątkiem, że należy pamiętać, że MySQL/MariaDB obsługuje tylko aktualizację główną z poprzedniej wersji. Jeśli korzystasz z MariaDB 10.0 i chcesz uaktualnić do wersji 10.2, musisz najpierw uaktualnić do MariaDB 10.1, a następnie wykonać kolejny krok uaktualnienia do MariaDB 10.2.

Zwróć uwagę na zmiany konfiguracji wprowadzane i wycofywane między głównymi wersjami.

Przełączanie awaryjne

W Galerze wszystkie węzły są masterami i pełnią tę samą rolę. Z ProxySQL na zdjęciu, połączenia, które przechodzą przez tę bramę, będą automatycznie przełączane awaryjnie, o ile istnieje podstawowy komponent działający dla Galera Cluster (czyli większość węzłów jest uruchomiona). Aplikacja nie zauważy żadnej różnicy, jeśli jeden węzeł bazy danych ulegnie awarii, ponieważ ProxySQL po prostu przekieruje połączenia do innych dostępnych węzłów.

Jeśli aplikacja łączy się bezpośrednio z MariaDB z pominięciem ProxySQL, przełączenie awaryjne musi zostać wykonane po stronie aplikacji poprzez wskazanie następnego dostępnego węzła, pod warunkiem, że węzeł bazy danych spełnia następujące warunki:

• Stan wsrep_local_state_comment jest zsynchronizowany (stan „Desynchronizowany/dawca” jest również możliwy, tylko jeśli wsrep_sst_method to xtrabackup, xtrabackup-v2 lub mariabackup).
• Stan wsrep_cluster_status jest podstawowym.

W Galera dostępny węzeł nie oznacza, że ​​jest zdrowy, dopóki powyższy stan nie zostanie zweryfikowany.

Skalowanie

Aby skalować w poziomie, możemy utworzyć nowy kontener w tej samej sieci i użyć tego samego niestandardowego pliku konfiguracyjnego dla istniejącego kontenera na tym konkretnym hoście. Na przykład, powiedzmy, że chcemy dodać czwarty kontener MariaDB na hoście3, możemy użyć tego samego pliku konfiguracyjnego zamontowanego dla mariadb3, jak pokazano na poniższym diagramie:

Uruchom następujące polecenie na hoście 3, aby skalować w poziomie:

$ docker run -d \
        --name mariadb4 \
        --hostname mariadb4.weave.local \
        --net weave \
        --publish "3306:3307" \
        --publish "4444" \
        --publish "4567" \
        --publish "4568" \
        $(weave dns-args) \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --volume /containers/mariadb4/datadir:/var/lib/mysql \
        --volume /containers/mariadb3/conf.d:/etc/mysql/mariadb.conf.d \
        mariadb:10.2.15 \
        --wsrep_cluster_address=gcomm://mariadb1.weave.local,mariadb2.weave.local,mariadb3.weave.local,mariadb4.weave.local \
        --wsrep_sst_auth="root:PM7%[email protected]^1" \
        --wsrep_node_address=mariadb4.weave.local

Po utworzeniu kontener dołączy do klastra i wykona SST. Można uzyskać do niego dostęp na porcie 3307 na zewnątrz lub poza siecią Weave, lub na porcie 3306 w obrębie hosta lub w sieci Weave. Nie jest już konieczne dołączanie mariadb0.weave.local do adresu klastra. Po skalowaniu klastra musimy dodać nowy kontener MariaDB do zestawu równoważenia obciążenia ProxySQL za pomocą konsoli administracyjnej:

$ docker exec -it proxysql1 mysql -uadmin -padmin -P6032
mysql> INSERT INTO mysql_servers(hostgroup_id,hostname,port) VALUES (10,'mariadb4.weave.local',3306);
mysql> INSERT INTO mysql_servers(hostgroup_id,hostname,port) VALUES (20,'mariadb4.weave.local',3306);
mysql> LOAD MYSQL SERVERS TO RUNTIME;
mysql> SAVE MYSQL SERVERS TO DISK;

Powtórz powyższe polecenia na drugiej instancji ProxySQL.

Na koniec w ostatnim kroku (możesz pominąć tę część, jeśli już uruchomiłeś instrukcję "SAVE .. TO DISK" w ProxySQL), dodaj następującą linię do proxysql.cnf, aby była trwała przy ponownym uruchomieniu kontenera na hoście1 i hoście2:

$ vim /containers/proxysql1/proxysql.cnf # host1
$ vim /containers/proxysql2/proxysql.cnf # host2

I dołącz wiersze związane z mariadb4 pod dyrektywą mysql_server:

mysql_servers =
(
        { address="mariadb1.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
        { address="mariadb2.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
        { address="mariadb3.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
        { address="mariadb4.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
        { address="mariadb1.weave.local" , port=3306 , hostgroup=20, max_connections=100 },
        { address="mariadb2.weave.local" , port=3306 , hostgroup=20, max_connections=100 },
        { address="mariadb3.weave.local" , port=3306 , hostgroup=20, max_connections=100 },
        { address="mariadb4.weave.local" , port=3306 , hostgroup=20, max_connections=100 }
)

Zapisz plik i powinniśmy być w porządku przy następnym ponownym uruchomieniu kontenera.

Skalowanie w dół

Aby zmniejszyć skalę, po prostu zamyka pojemnik z wdziękiem. Najlepszym poleceniem byłoby:

$ docker kill -s 15 mariadb4
$ docker rm -f mariadb4

Pamiętaj, że jeśli węzeł bazy danych opuścił klaster bez gracji, nie było to częścią zmniejszania skali i wpłynęłoby to na obliczanie kworum.

Aby usunąć kontener z ProxySQL, uruchom następujące polecenia na obu kontenerach ProxySQL. Na przykład na proxysql1:

$ docker exec -it proxysql1 mysql -uadmin -padmin -P6032
mysql> DELETE FROM mysql_servers WHERE hostname="mariadb4.weave.local";
mysql> LOAD MYSQL SERVERS TO RUNTIME;
mysql> SAVE MYSQL SERVERS TO DISK;

Następnie możesz usunąć odpowiedni wpis w pliku proxysql.cnf lub po prostu tak go zostawić. I tak zostanie wykryty jako OFFLINE z punktu widzenia ProxySQL.

Podsumowanie

Dzięki Dockerowi sytuacja wygląda nieco inaczej niż w konwencjonalnym sposobie obsługi serwerów MySQL lub MariaDB. Obsługa usług stanowych, takich jak Galera Cluster, nie jest tak łatwa jak aplikacje bezstanowe i wymaga odpowiedniego testowania i planowania.

W naszym następnym blogu na ten temat ocenimy zalety i wady uruchamiania Galera Cluster na platformie Docker bez żadnych narzędzi do orkiestracji.