Istnieje wiele sposobów wdrażania bazy danych. Możesz zainstalować go ręcznie, możesz polegać na szeroko dostępnych narzędziach do orkiestracji infrastruktury, takich jak Ansible, Chef, Puppet lub Salt. Narzędzia te są bardzo popularne i dość łatwo jest znaleźć skrypty, przepisy, poradniki, co tylko chcesz, co pomoże Ci zautomatyzować instalację klastra bazy danych. Istnieją również bardziej wyspecjalizowane platformy automatyzacji baz danych, takie jak ClusterControl, które można również wykorzystać do zautomatyzowanego wdrażania. Jaki byłby najlepszy sposób wdrożenia klastra? Ile czasu będziesz potrzebować na jego wdrożenie?
Najpierw wyjaśnijmy, co chcemy zrobić. Załóżmy, że będziemy wdrażać klaster Percona XtraDB Cluster 5.7. Będzie składał się z trzech węzłów, a do tego wykorzystamy trzy wirtualne maszyny Vagrant z systemem Ubuntu 16.04 (obraz bento/ubuntu-16.04). Spróbujemy ręcznie wdrożyć klaster, a następnie użyjemy Ansible i ClusterControl. Zobaczmy, jak będą wyglądać wyniki.
Wdrażanie ręczne
Konfiguracja repozytorium — 1 minuta, 45 sekund.
Przede wszystkim musimy skonfigurować repozytoria Percona na wszystkich węzłach Ubuntu. Szybkie wyszukiwanie w Google, ssh do maszyn wirtualnych i uruchamianie wymaganych poleceń zajmuje 1m45s
Znaleźliśmy następującą stronę z instrukcjami:
https://www.percona.com/doc/percona-repo-config/percona-release.html
i wykonaliśmy kroki opisane w sekcji „DYSTRYBUCJE GNU/LINUX OPARTE NA DEB”. Przeprowadziliśmy również aktualizację apt, aby odświeżyć pamięć podręczną apt.
Instalowanie węzłów PXC — 2 minuty 45 sekund
Ten krok zasadniczo polega na wykonaniu:
[email protected]:~# apt install percona-xtradb-cluster-5.7Reszta zależy głównie od szybkości połączenia internetowego, ponieważ pakiety są pobierane. Twoje dane wejściowe będą również potrzebne (będziesz przekazywać hasło dla superużytkownika), więc nie jest to instalacja bez nadzoru. Kiedy wszystko zostanie zrobione, otrzymasz trzy działające węzły klastra Percona XtraDB:
root 15488 0.0 0.2 4504 1788 ? S 10:12 0:00 /bin/sh /usr/bin/mysqld_safe
mysql 15847 0.3 28.3 1339576 215084 ? Sl 10:12 0:00 \_ /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plugin --user=mysql --wsrep-provider=/usr/lib/galera3/libgalera_smm.so --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock --wsrep_start_position=00000000-0000-0000-0000-000000000000:-1Konfigurowanie węzłów PXC — 3 minuty, 25 sekund
Tutaj zaczyna się trudna część. Naprawdę trudno jest oszacować doświadczenie i ile czasu potrzeba, aby faktycznie zrozumieć, co należy zrobić. Co dobre, wyszukiwarka google „jak zainstalować klaster percona xtrabdb” wskazuje na dokumentację Percony, która opisuje, jak powinien wyglądać ten proces. Nadal może to zająć więcej lub mniej czasu, w zależności od tego, jak dobrze znasz PXC i Galerę. W najgorszym przypadku nie będziesz świadomy żadnych dodatkowych wymaganych działań i połączysz się ze swoim PXC i zaczniesz z nim pracować, nie zdając sobie sprawy, że w rzeczywistości masz trzy węzły, z których każdy tworzy własny klaster.
Załóżmy, że postępujemy zgodnie z zaleceniami firmy Percona i ustalamy czas tylko tych kroków do wykonania. Krótko mówiąc, zmodyfikowaliśmy pliki konfiguracyjne zgodnie z instrukcjami na stronie Percona, próbowaliśmy również załadować pierwszy węzeł:
[email protected]:~# /etc/init.d/mysql bootstrap-pxc
mysqld: [ERROR] Found option without preceding group in config file /etc/mysql/my.cnf at line 10!
mysqld: [ERROR] Fatal error in defaults handling. Program aborted!
mysqld: [ERROR] Found option without preceding group in config file /etc/mysql/my.cnf at line 10!
mysqld: [ERROR] Fatal error in defaults handling. Program aborted!
mysqld: [ERROR] Found option without preceding group in config file /etc/mysql/my.cnf at line 10!
mysqld: [ERROR] Fatal error in defaults handling. Program aborted!
mysqld: [ERROR] Found option without preceding group in config file /etc/mysql/my.cnf at line 10!
mysqld: [ERROR] Fatal error in defaults handling. Program aborted!
* Bootstrapping Percona XtraDB Cluster database server mysqld ^CTo nie wyglądało poprawnie. Niestety instrukcje nie były jasne. Ponownie, jeśli nie wiesz, co się dzieje, spędzisz więcej czasu próbując zrozumieć, co się stało. Na szczęście stackoverflow.com jest bardzo pomocny (choć nie jest to pierwsza odpowiedź na liście, którą otrzymaliśmy) i powinieneś zdać sobie sprawę, że brakuje nagłówka sekcji [mysqld] w swoim pliku /etc/mysql/my.cnf. Dodanie tego we wszystkich węzłach i powtórzenie procesu ładowania początkowego rozwiązało problem. W sumie spędziliśmy 3 minuty i 25 sekund (nie licząc googlowania w poszukiwaniu błędu, ponieważ natychmiast zauważyliśmy, na czym polega problem).
Konfiguracja SST, przenoszenie innych węzłów do klastra — od 8 minut do nieskończoności
Instrukcje na stronie internetowej Percony są dość jasne. Po uruchomieniu jednego węzła po prostu uruchom pozostałe węzły i wszystko będzie dobrze. Próbowaliśmy tego i nie mogliśmy zobaczyć więcej węzłów dołączających do klastra. W tym miejscu praktycznie niemożliwe jest określenie, ile czasu zajmie zdiagnozowanie problemu. Zajęło nam to 6-7 minut, ale żeby zrobić to szybko, trzeba:
- Zapoznaj się ze strukturą konfiguracji PXC:
[email protected]:~# tree /etc/mysql/ /etc/mysql/ ├── conf.d │ ├── mysql.cnf │ └── mysqldump.cnf ├── my.cnf -> /etc/alternatives/my.cnf ├── my.cnf.fallback ├── my.cnf.old ├── percona-xtradb-cluster.cnf └── percona-xtradb-cluster.conf.d ├── client.cnf ├── mysqld.cnf ├── mysqld_safe.cnf └── wsrep.cnf - Wiedz, jak dyrektywy !include i !includedir działają w plikach konfiguracyjnych MySQL
- Wiedz, jak MySQL obsługuje te same zmienne zawarte w wielu plikach
- Wiedz, czego szukać i pamiętaj o konfiguracjach, które skutkowałyby ładowaniem się węzła w celu utworzenia samodzielnego klastra
Problem był związany z faktem, że instrukcje nie wspominały o żadnym pliku poza /etc/mysql/my.cnf, gdzie tak naprawdę powinniśmy zmodyfikować /etc/mysql/percona-xtradb-cluster.conf.d/wsrep .cnf. Ten plik zawierał pustą zmienną:
wsrep_cluster_address=gcomm://a taka konfiguracja wymusza na węźle ładowanie początkowe, ponieważ nie ma informacji o innych węzłach, do których można się przyłączyć. Ustawiliśmy tę zmienną w /etc/mysql/my.cnf, ale później plik wsrep.cnf został dołączony, nadpisując naszą konfigurację.
Ten problem może być poważnym przeszkodą dla osób, które nie są zaznajomione z działaniem MySQL i Galera, co skutkuje nawet godzinami, jeśli nie więcej debugowania.
Całkowity czas instalacji — 16 minut (jeśli jesteś administratorem bazy danych MySQL tak jak ja)
Udało nam się zainstalować klaster Percona XtraDB w 16 minut. Trzeba pamiętać o kilku rzeczach - nie dostrajaliśmy konfiguracji. To będzie wymagało więcej czasu i wiedzy. Węzeł PXC jest dostarczany z prostą konfiguracją, związaną głównie z logowaniem binarnym i replikacją zbioru zapisu Galera. Nie ma strojenia InnoDB. Jeśli nie znasz elementów wewnętrznych MySQL, to godziny, jeśli nie dni, na czytanie i zapoznawanie się z wewnętrznymi mechanizmami. Inną ważną rzeczą jest to, że jest to proces, który musiałbyś ponownie zastosować dla każdego wdrożonego klastra. Wreszcie udało nam się zidentyfikować problem i bardzo szybko go rozwiązać dzięki naszym doświadczeniom z klastrem Percona XtraDB i ogólnie MySQL. Przypadkowy użytkownik najprawdopodobniej spędzi znacznie więcej czasu, próbując zrozumieć, co się dzieje i dlaczego.
Poradnik Ansible
Teraz przejdźmy do automatyzacji z Ansible. Spróbujmy znaleźć i wykorzystać podręcznik ansibla, którego moglibyśmy użyć ponownie we wszystkich dalszych wdrożeniach. Zobaczmy, jak długo to zajmie.
Konfigurowanie łączności SSH — 1 minuta
Ansible wymaga połączenia SSH we wszystkich węzłach, aby je połączyć i skonfigurować. Wygenerowaliśmy klucz SSH i ręcznie rozesłaliśmy go do węzłów.
Znajdowanie podręcznika Ansible — 2 minuty 15 sekund
Głównym problemem jest to, że dostępnych jest tak wiele podręczników, że nie można zdecydować, co jest najlepsze. W związku z tym postanowiliśmy przejść z 3 najlepszymi wynikami Google i spróbować wybrać jeden. Zdecydowaliśmy się na https://github.com/cdelgehier/ansible-role-XtraDB-Cluster, ponieważ wydaje się, że jest bardziej konfigurowalny niż pozostałe.
Klonowanie repozytorium i instalowanie Ansible — 30 sekund
To jest szybkie, wystarczyło
apt install ansible git
git clone https://github.com/cdelgehier/ansible-role-XtraDB-Cluster.gitPrzygotowywanie pliku inwentaryzacji — 1 minuta 10 sekund
Ten krok również był bardzo prosty, stworzyliśmy plik inwentarzowy na przykładzie z dokumentacji. Po prostu podmieniliśmy adresy IP węzłów na to, co skonfigurowaliśmy w naszym środowisku.
Przygotowywanie poradnika — 1 minuta 45 sekund
Zdecydowaliśmy się na skorzystanie z jak najszerszego przykładu z dokumentacji, który zawiera również trochę dostrajania konfiguracji. Przygotowaliśmy poprawną strukturę dla Ansible (w dokumentacji nie było takiej informacji):
/root/pxcansible/
├── inventory
├── pxcplay.yml
└── roles
└── ansible-role-XtraDB-ClusterPotem go uruchomiliśmy, ale od razu pojawił się błąd:
[email protected]:~/pxcansible# ansible-playbook pxcplay.yml
[WARNING]: provided hosts list is empty, only localhost is available
ERROR! no action detected in task
The error appears to have been in '/root/pxcansible/roles/ansible-role-XtraDB-Cluster/tasks/main.yml': line 28, column 3, but may
be elsewhere in the file depending on the exact syntax problem.
The offending line appears to be:
- name: "Include {{ ansible_distribution }} tasks"
^ here
We could be wrong, but this one looks like it might be an issue with
missing quotes. Always quote template expression brackets when they
start a value. For instance:
with_items:
- {{ foo }}
Should be written as:
with_items:
- "{{ foo }}"Zajęło to 1 minutę i 45 sekund.
Naprawianie problemu ze składnią podręcznika Playbook — 3 minuty 25 sekund
Błąd był mylący, ale ogólną zasadą jest wypróbowanie nowszej wersji Ansible, co zrobiliśmy. Wygooglowaliśmy i znaleźliśmy dobre instrukcje na stronie Ansible. Następna próba uruchomienia podręcznika również nie powiodła się:
TASK [ansible-role-XtraDB-Cluster : Delete anonymous connections] *****************************************************************************************************************************************************************************************************************
fatal: [node2]: FAILED! => {"changed": false, "msg": "The PyMySQL (Python 2.7 and Python 3.X) or MySQL-python (Python 2.X) module is required."}
fatal: [node3]: FAILED! => {"changed": false, "msg": "The PyMySQL (Python 2.7 and Python 3.X) or MySQL-python (Python 2.X) module is required."}
fatal: [node1]: FAILED! => {"changed": false, "msg": "The PyMySQL (Python 2.7 and Python 3.X) or MySQL-python (Python 2.X) module is required."}Konfiguracja nowej wersji Ansible i uruchomienie Playbooka aż do tego błędu zajęło 3 minuty i 25 sekund.
Naprawianie brakującego modułu Pythona — 3 minuty 20 sekund
Najwyraźniej rola, której użyliśmy, nie spełniała wymagań wstępnych i brakowało modułu Pythona do łączenia się z klastrem Galera i zabezpieczania go. Najpierw próbowaliśmy zainstalować MySQL-python przez pip, ale okazało się, że zajmie to więcej czasu, ponieważ wymagało to mysql_config:
[email protected]:~# pip install MySQL-python
Collecting MySQL-python
Downloading https://files.pythonhosted.org/packages/a5/e9/51b544da85a36a68debe7a7091f068d802fc515a3a202652828c73453cad/MySQL-python-1.2.5.zip (108kB)
100% |████████████████████████████████| 112kB 278kB/s
Complete output from command python setup.py egg_info:
sh: 1: mysql_config: not found
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/tmp/pip-build-zzwUtq/MySQL-python/setup.py", line 17, in <module>
metadata, options = get_config()
File "/tmp/pip-build-zzwUtq/MySQL-python/setup_posix.py", line 43, in get_config
libs = mysql_config("libs_r")
File "/tmp/pip-build-zzwUtq/MySQL-python/setup_posix.py", line 25, in mysql_config
raise EnvironmentError("%s not found" % (mysql_config.path,))
EnvironmentError: mysql_config not found
----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-zzwUtq/MySQL-python/Zapewniają to biblioteki programistyczne MySQL, więc musielibyśmy je instalować ręcznie, co było prawie bezcelowe. Zdecydowaliśmy się na PyMySQL, który nie wymagał instalacji innych pakietów. To doprowadziło nas do kolejnego problemu:
TASK [ansible-role-XtraDB-Cluster : Delete anonymous connections] *****************************************************************************************************************************************************************************************************************
fatal: [node3]: FAILED! => {"changed": false, "msg": "unable to connect to database, check login_user and login_password are correct or /root/.my.cnf has the credentials. Exception message: (1698, u\"Access denied for user 'root'@'localhost'\")"}
fatal: [node2]: FAILED! => {"changed": false, "msg": "unable to connect to database, check login_user and login_password are correct or /root/.my.cnf has the credentials. Exception message: (1698, u\"Access denied for user 'root'@'localhost'\")"}
fatal: [node1]: FAILED! => {"changed": false, "msg": "unable to connect to database, check login_user and login_password are correct or /root/.my.cnf has the credentials. Exception message: (1698, u\"Access denied for user 'root'@'localhost'\")"}
to retry, use: --limit @/root/pxcansible/pxcplay.retryDo tego momentu spędziliśmy 3 minuty i 20 sekund.
Naprawianie błędu „Odmowa dostępu” — 18 minut 55 sekund
Jak na błąd, upewniliśmy się, że konfiguracja MySQL jest przygotowana poprawnie i zawiera poprawnego użytkownika i hasło do połączenia z bazą danych. To niestety nie działało zgodnie z oczekiwaniami. Zbadaliśmy dokładniej i stwierdziliśmy, że rola nie tworzy poprawnie użytkownika root, mimo że oznaczała krok jako zakończony. Przeprowadziliśmy krótkie dochodzenie, ale postanowiliśmy dokonać ręcznej naprawy, zamiast próbować debugować podręcznik, co zajęłoby znacznie więcej czasu niż kroki, które wykonaliśmy. Właśnie utworzyliśmy ręcznie użytkowników [email protected] i [email protected] z poprawnymi hasłami. To pozwoliło nam przejść ten krok i przejść do innego błędu:
TASK [ansible-role-XtraDB-Cluster : Start the master node] ************************************************************************************************************************************************************************************************************************
skipping: [node1]
skipping: [node2]
skipping: [node3]
TASK [ansible-role-XtraDB-Cluster : Start the master node] ************************************************************************************************************************************************************************************************************************
skipping: [node1]
skipping: [node2]
skipping: [node3]
TASK [ansible-role-XtraDB-Cluster : Create SST user] ******************************************************************************************************************************************************************************************************************************
skipping: [node1]
skipping: [node2]
skipping: [node3]
TASK [ansible-role-XtraDB-Cluster : Start the slave nodes] ************************************************************************************************************************************************************************************************************************
fatal: [node3]: FAILED! => {"changed": false, "msg": "Unable to start service mysql: Job for mysql.service failed because the control process exited with error code. See \"systemctl status mysql.service\" and \"journalctl -xe\" for details.\n"}
fatal: [node2]: FAILED! => {"changed": false, "msg": "Unable to start service mysql: Job for mysql.service failed because the control process exited with error code. See \"systemctl status mysql.service\" and \"journalctl -xe\" for details.\n"}
fatal: [node1]: FAILED! => {"changed": false, "msg": "Unable to start service mysql: Job for mysql.service failed because the control process exited with error code. See \"systemctl status mysql.service\" and \"journalctl -xe\" for details.\n"}
to retry, use: --limit @/root/pxcansible/pxcplay.retryW tej sekcji spędziliśmy 18 minut i 55 sekund.
Naprawa problemu „Uruchom węzły podrzędne” (część 1) – 7 minut 40 sekund
Próbowaliśmy kilku rzeczy, aby rozwiązać ten problem. Próbowaliśmy określić węzeł za pomocą jego nazwy, próbowaliśmy zamienić nazwy grup, nic nie rozwiązało problemu. Postanowiliśmy posprzątać środowisko za pomocą skryptu dostarczonego w dokumentacji i zacząć od zera. Nie wyczyściło go, ale tylko pogorszyło sytuację. Po 7 minutach i 40 sekundach zdecydowaliśmy się wymazać maszyny wirtualne, odtworzyć środowisko i zacząć od zera, mając nadzieję, że dodanie zależności Pythona rozwiąże nasz problem.
Naprawa problemu „Uruchom węzły podrzędne” (część 2) — 13 minut 15 sekund
Niestety, skonfigurowanie wymagań wstępnych Pythona wcale nie pomogło. Postanowiliśmy zakończyć ten proces ręcznie, uruchamiając pierwszy węzeł, a następnie konfigurując użytkownika SST i uruchamiając pozostałe urządzenia podrzędne. To zakończyło „zautomatyzowaną” konfigurację, a debugowanie zajęło nam 13 minut i 15 sekund, a następnie zaakceptowaliśmy, że nie będzie działać tak, jak oczekiwał projektant podręcznika.
Dalsze debugowanie — 10 minut 45 sekund
Nie poprzestaliśmy na tym i postanowiliśmy, że spróbujemy jeszcze jednej rzeczy. Zamiast polegać na zmiennych Ansible, po prostu umieszczamy adres IP jednego z węzłów jako węzeł główny. To rozwiązało tę część problemu i otrzymaliśmy:
TASK [ansible-role-XtraDB-Cluster : Create SST user] ******************************************************************************************************************************************************************************************************************************
skipping: [node2]
skipping: [node3]
fatal: [node1]: FAILED! => {"changed": false, "msg": "unable to connect to database, check login_user and login_password are correct or /root/.my.cnf has the credentials. Exception message: (1045, u\"Access denied for user 'root'@'::1' (using password: YES)\")"}To był koniec naszych prób — próbowaliśmy dodać tego użytkownika, ale nie działało to poprawnie w podręczniku ansible, podczas gdy mogliśmy użyć adresu lokalnego hosta IPv6 do połączenia się podczas korzystania z klienta MySQL.
Całkowity czas instalacji — nieznany (instalacja automatyczna nie powiodła się)
W sumie spędziliśmy 64 minuty i nadal nie udało nam się uruchomić wszystkiego automatycznie. Pozostałe problemy to tworzenie hasła roota, które wydaje się nie działać, a następnie uruchomienie klastra Galera (problem użytkownika SST). Trudno powiedzieć, ile czasu zajmie dalsze debugowanie. Jest to na pewno możliwe - po prostu trudno to oszacować, ponieważ tak naprawdę zależy to od doświadczenia z Ansible i MySQL. Zdecydowanie nie jest to coś, co każdy może po prostu pobrać, skonfigurować i uruchomić. Cóż, może inny poradnik działałby inaczej? Jest to możliwe, ale równie dobrze może skutkować różnymi problemami. Ok, więc trzeba wspiąć się na krzywą uczenia się i wykonać debugowanie, ale potem, kiedy wszystko będzie gotowe, po prostu uruchomisz skrypt. Cóż, to trochę prawda. Dopóki zmiany wprowadzone przez opiekuna nie spowodują czegoś, na czym polegasz lub nowa wersja Ansible zepsuje playbook lub opiekun po prostu zapomni o projekcie i przestanie go rozwijać (na rolę, której użyliśmy, czeka bardzo przydatne żądanie ściągnięcia już prawie rok, co może rozwiązać problem zależności od Pythona - nie został scalony). O ile nie zaakceptujesz, że będziesz musiał utrzymywać ten kod, nie możesz naprawdę polegać na tym, że jest w 100% dokładny i działa w twoim środowisku, zwłaszcza biorąc pod uwagę, że oryginalny programista nie ma zachęt do aktualizowania kodu. A co z innymi wersjami? Nie można użyć tego konkretnego podręcznika do zainstalowania PXC 5.6 ani żadnej wersji MariaDB. Jasne, możesz znaleźć inne podręczniki. Czy będą działać lepiej, czy może spędzisz jeszcze kilka godzin, próbując zmusić je do pracy?
ClusterControlSingle Console dla całej infrastruktury bazy danychDowiedz się, co jeszcze nowego w ClusterControlZainstaluj ClusterControl ZA DARMOClusterControl
Na koniec przyjrzyjmy się, jak można użyć ClusterControl do wdrożenia klastra Percona XtraDB.
Konfigurowanie łączności SSH — 1 minuta
ClusterControl wymaga połączenia SSH we wszystkich węzłach, aby je połączyć i skonfigurować. Wygenerowaliśmy klucz SSH i ręcznie rozesłaliśmy go do węzłów.
Konfiguracja ClusterControl — 3 minuty 15 sekund
Szybkie wyszukiwanie „ClusterControl install” wskazało nam odpowiednią stronę dokumentacji ClusterControl. Szukaliśmy „prostszego sposobu instalacji ClusterControl”, dlatego skorzystaliśmy z linku i znaleźliśmy następujące instrukcje.
Pobranie skryptu i uruchomienie go zajęło 3 minuty i 15 sekund. Podczas instalacji musieliśmy wykonać pewne czynności, aby nie była to instalacja bez nadzoru.
Logowanie się do interfejsu użytkownika i rozpoczęcie wdrażania — 1 minuta 10 sekund
Skierowaliśmy naszą przeglądarkę na adres IP węzła ClusterControl.
Przekazaliśmy wymagane informacje kontaktowe i pojawił się ekran powitalny:
Następny krok — wybraliśmy opcję wdrożenia.
Musieliśmy przekazać szczegóły połączenia SSH.
Zdecydowaliśmy się również na dostawcę, wersję, hasło i hosty, których będziemy używać. Cały ten proces trwał 1 minutę i 10 sekund.
Wdrożenie klastra Percona XtraDB — 12 minut 5 sekund
Pozostało tylko czekać, aż ClusterControl zakończy wdrażanie. Po 12 minutach i 5 sekundach klaster był gotowy:
Całkowity czas instalacji — 17 minut 30 sekund
Powiązane zasoby ClusterControl for MySQL ClusterControl for MariaDB ClusterControl for Galera ClusterUdało nam się wdrożyć ClusterControl, a następnie klaster PXC przy użyciu ClusterControl w 17 minut i 30 sekund. Samo wdrożenie PXC zajęło 12 minut i 5 sekund . Na koniec mamy działający klaster, wdrożony zgodnie z najlepszymi praktykami. ClusterControl zapewnia również, że konfiguracja klastra ma sens. Krótko mówiąc, nawet jeśli tak naprawdę nie wiesz nic o klastrze MySQL lub Galera, możesz wdrożyć gotowy do produkcji klaster w ciągu kilku minut. ClusterControl to nie tylko narzędzie do wdrażania, to także platforma do zarządzania - ułatwia osobom, które nie mają doświadczenia z MySQL i Galera, identyfikowanie problemów z wydajnością (poprzez doradców) i wykonywanie czynności związanych z zarządzaniem (skalowanie klastra w górę i w dół, wykonywanie kopii zapasowych, tworzenie asynchronicznych niewolników do Galera). Co ważne, ClusterControl będzie zawsze utrzymywany i może być używany do wdrażania wszystkich smaków MySQL (i nie tylko MySQL/MariaDB, obsługuje również TimeScaleDB, PostgreSQL i MongoDB). Zadziałało to również po wyjęciu z pudełka, czego nie można powiedzieć o innych testowanych przez nas metodach.
Jeśli chcesz doświadczyć tego samego, możesz bezpłatnie pobrać ClusterControl. Daj nam znać, jak Ci się podobało.
