Konfigurowanie klastra bazy danych o wysokiej dostępności z użyciem MariaDB Galera, ProxySQL, Keepalived i Debian 13

Wprowadzenie

W miarę jak Twoje aplikacje rosną pod względem skali i znaczenia, zapewnienie ciągłej dostępności staje się kluczowe. Przestoje bazy danych mogą prowadzić do utraty przychodów, frustracji użytkowników i uszkodzenia reputacji. Ten przewodnik pokazuje, jak zbudować wysoce dostępny (HA) klaster MariaDB wykorzystujący replikację Galera, ProxySQL do inteligentnego routingu zapytań oraz Keepalived do zarządzania wirtualnym IP na Debianie.

Ta architektura łączy mocne strony każdej technologii, aby dostarczyć solidne i odporne środowisko bazodanowe. MariaDB Galera zapewnia synchroniczną replikację multi-master, zapewniając spójność danych na wielu węzłach. ProxySQL działa jako router zapytań i równoważnik obciążenia, zapewniając inteligentne zarządzanie ruchem i odciążając serwery baz danych. Keepalived zarządza wirtualnym adresem IP, zapewniając jeden punkt dostępu do klastra i automatyzując przełączanie awaryjne w przypadku awarii węzła.

Ten przewodnik zakłada doświadczenie w administracji systemami Linux, podstawowe pojęcia sieciowe (TCP/IP, DNS) oraz znajomość administracji bazami danych. Skupimy się na konfiguracji i integracji tych technologii w środowisku Debian.

Kluczowe korzyści z tej architektury:

• Wysoka dostępność: Automatyczne przełączanie awaryjne zapewnia minimalne przestoje.
• Spójność danych: Synchroniczna replikacja gwarantuje spójność danych na wszystkich węzłach.
• Poprawiona wydajność: ProxySQL optymalizuje routing zapytań i zmniejsza obciążenie serwerów baz danych.
• Uproszczone zarządzanie: Jeden wirtualny adres IP upraszcza konfigurację aplikacji i dostęp.

Co będziesz potrzebować:

• Trzy VPS lub serwery Debian 13.
• Dostęp root lub sudo do wszystkich serwerów.
• Znajomość interfejsu wiersza poleceń.
• Podstawowe zrozumienie sieci TCP/IP i DNS.

Wymagania wstępne

Połączenie węzłów

Prawidłowe rozwiązywanie nazw hostów jest niezbędne do prawidłowego działania klastra. Każdy serwer musi być w stanie znaleźć inne serwery po nazwie. Używamy nazw hostów, aby uprościć zarządzanie. Adresy IP węzłów muszą znajdować się w tej samej podsieci.

Mapowanie nazw hostów i adresów IP

• galera0 (węzeł główny): 192.168.10.10
• galera1 (węzeł podrzędny): 192.168.10.11
• galera2 (węzeł podrzędny): 192.168.10.12

Możesz osiągnąć rozwiązywanie nazw hostów za pomocą pliku /etc/hosts lub DNS.

• Użycie /etc/hosts (prostsza konfiguracja): Jest to odpowiednie dla środowisk testowych i deweloperskich. Na każdym serwerze dodaj wpisy mapujące nazwę hosta serwera na jego statyczny adres IP w pliku /etc/hosts.
• Użycie DNS (zalecane dla produkcji): Dla większych lub bardziej złożonych środowisk skonfiguruj rekordy DNS (rekordy A), które mapują nazwy hostów serwerów na ich odpowiednie adresy IP.

Weryfikacja

Po skonfigurowaniu rozwiązywania nazw hostów, zweryfikuj, czy każdy serwer może rozwiązać nazwy hostów innych serwerów za pomocą polecenia ping. Na przykład, z galera0, uruchom ping galera1. Powinieneś otrzymać odpowiedź.

Instalacja wymaganych pakietów

Zanim będziesz mógł skonfigurować klaster Galera, musisz zainstalować niezbędne pakiety MariaDB na każdym węźle. Ta sekcja opisuje wymagane kroki dla systemów opartych na Debianie.

Dodaj wymagane repozytoria

Dodaj wymagane repozytoria za pomocą następujących poleceń:

apt-get update && apt-get install -y --no-install-recommends lsb-release wget apt-transport-https ca-certificates

wget -nv -O /usr/share/keyrings/proxysql-3.0.x-keyring.gpg 'https://repo.proxysql.com/ProxySQL/proxysql-3.0.x/repo_pub_key.gpg'

echo "deb [signed-by=/usr/share/keyrings/proxysql-3.0.x-keyring.gpg] https://repo.proxysql.com/ProxySQL/proxysql-3.0.x/bookworm/ ./" | tee /etc/apt/sources.list.d/proxysql.list

Aktualizacja systemu

Najpierw zaktualizuj listy pakietów i pakiety. Uruchom następne polecenie jako root na każdym węźle:

apt update && apt upgrade -y

Zainstaluj pakiety

Zainstaluj wymagane pakiety na każdym węźle za pomocą tego polecenia:

apt install rsync mariadb-server mariadb-client galera-4 proxysql keepalived -y

Zabezpiecz instalację MariaDB

Wykonaj skrypt zabezpieczający na każdym węźle:

sudo mariadb-secure-installation

Ten skrypt wykonuje dwa kluczowe kroki: poprosi Cię o ustawienie silnego hasła root dla serwera MariaDB oraz usunie wszelkie niebezpieczne domyślne konfiguracje. Postępuj zgodnie z instrukcjami na ekranie, aby zakończyć ten proces.

Włącz zdalny dostęp do MariaDB

Wykonaj te polecenia, aby włączyć zdalny dostęp na każdym węźle:

sed -i "s/.*bind-address.*/bind-address = 0.0.0.0/" /etc/mysql/mariadb.conf.d/50-server.cnf

systemctl restart mariadb

Galera

Galera zapewnia synchroniczną replikację danych na wszystkich węzłach w klastrze. Oznacza to, że każda zmiana dokonana w bazie danych na jednym węźle jest automatycznie i jednocześnie propagowana na wszystkie inne węzły. Kluczowe korzyści z Galera w tej konfiguracji:

• Wysoka dostępność: Jeśli jeden węzeł zawiedzie, inne węzły nadal obsługują dane bez przerwy. Klaster automatycznie promuje przetrwały węzeł do roli głównej.
• Spójność danych: Dzięki synchronicznej replikacji dane są zawsze spójne na wszystkich węzłach. Eliminuje to ryzyko nieaktualnych odczytów – zawsze czytasz najnowszą wersję danych.
• Skalowalność odczytu: Ponieważ dane są replikowane na wielu węzłach, możesz rozdzielić zapytania odczytu na klaster, aby zwiększyć wydajność odczytu.

W istocie, Galera zapewnia, że Twoja baza danych MariaDB pozostaje wysoce dostępna, spójna i skalowalna – kluczowe wymagania dla wielu aplikacji.

Konfiguracja

Utwórz plik konfiguracyjny /etc/mysql/conf.d/galera.cnf na każdym węźle. Zawartość będzie identyczna, z wyjątkiem nazwy i adresu każdego węzła. Wklej ten szablon:

[mysqld]
# Podstawowe ustawienia MariaDB
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0

# Konfiguracja dostawcy Galera
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so

# Konfiguracja klastra Galera
wsrep_cluster_name="my_galera_cluster"
wsrep_cluster_address="gcomm://galera0,galera1,galera2"

# Specyficzna konfiguracja tego węzła
wsrep_node_name="<node_name>"
wsrep_node_address="<node_address>"

Zmień <node_name> i <node_address> na każdym węźle. Użyj galera0 dla pierwszego węzła i tak dalej.

Uruchom klaster

Uruchom klaster na pierwszym węźle za pomocą tego polecenia:

sudo systemctl stop mariadb && sudo galera_new_cluster

Zrestartuj MariaDB na innych węzłach:

sudo systemctl restart mariadb

Weryfikacja konfiguracji

Sprawdź rozmiar klastra

Połącz się z MariaDB na dowolnym węźle i sprawdź status klastra. Połącz się z bazą danych:

sudo mariadb -u root -p

Sprawdź status węzłów klastra w powłoce MariaDB:

SHOW STATUS LIKE 'wsrep_cluster_size';

wsrep_cluster_size powinno być równe liczbie naszych węzłów.

+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 3     |
+--------------------+-------+
1 row in set (0.001 sec)

Test replikacji

Utwórz testową bazę danych na dowolnym węźle i wstaw testową wiadomość. Wykonaj następujące polecenia z powłoki MariaDB:

CREATE DATABASE galtest;

USE galtest;

CREATE TABLE messages (id INT AUTO_INCREMENT PRIMARY KEY, text VARCHAR(255));

INSERT INTO messages (text) VALUES ('Test from galera0!');

Następnie zweryfikuj dane na innych węzłach za pomocą następującego zapytania SQL w powłoce MariaDB:

USE galtest;

SELECT * FROM messages;

Powinna pojawić się testowa wiadomość:

+----+--------------------+
| id | text               |
+----+--------------------+
|  7 | Test from galera0! |
+----+--------------------+
1 row in set (0.001 sec)

ProxySQL

ProxySQL w tej konfiguracji klastra to więcej niż tylko prosty pośrednik; znacząco poprawia wydajność, niezawodność i zarządzanie Twoją bazą danych. ProxySQL działa jako kluczowa warstwa między Twoją aplikacją(-ami) a klastrem Galera. Jego główne cele to:

• Buforowanie zapytań: ProxySQL agresywnie buforuje często wykonywane zapytania. Zamiast wielokrotnie zapytywać klaster Galera o te same dane, serwuje buforowany wynik, znacznie zmniejszając obciążenie bazy danych i poprawiając czasy odpowiedzi. Jest to szczególnie korzystne dla aplikacji z dużą ilością odczytów.
• Pula połączeń: ProxySQL utrzymuje pulę trwałych połączeń z klastrem Galera. Nawiązywanie połączenia z bazą danych to operacja zasobożerna. Pula połączeń unika tego obciążenia, ponownie wykorzystując istniejące połączenia, co dodatkowo zwiększa wydajność.
• Równoważenie obciążenia i routing zapytań: ProxySQL może inteligentnie kierować zapytania do różnych węzłów w klastrze Galera na podstawie takich czynników jak obciążenie serwera, typ zapytania czy powiązanie danych. Pozwala to na rozłożenie obciążenia i maksymalizację wydajności klastra.
• Optymalizacja zapytań: ProxySQL może przekształcać zapytania, aby były bardziej efektywne, potencjalnie wykorzystując możliwości Galera do optymalnego wykonania.
• Wykrywanie awarii i routing: ProxySQL ciągle monitoruje stan zdrowia węzłów Galera. Jeśli węzeł zawiedzie, ProxySQL automatycznie przekierowuje zapytania do zdrowych węzłów, zapewniając nieprzerwaną obsługę.

W istocie, ProxySQL działa jako inteligentny menedżer ruchu i optymalizator wydajności dla Twojego klastra Galera, znacznie poprawiając jego efektywność i odporność.

Środki ostrożności

Konfiguracja użytkowników

Użytkownik monitorujący

Użytkownik monitorujący w ProxySQL to dedykowane konto bazy danych wyłącznie dla narzędzi monitorujących, aby bezpiecznie uzyskać dostęp do wewnętrznych statystyk i metryk. Jest skonfigurowany z minimalnymi uprawnieniami – tylko dostęp SELECT – zapewniając integralność i bezpieczeństwo Twoich danych, jednocześnie umożliwiając kompleksowe monitorowanie wydajności.

Wykonaj to zapytanie w powłoce MariaDB na węźle głównym, aby dodać użytkownika monitorującego:

CREATE USER 'monitor'@'%' IDENTIFIED BY 'monitor';

GRANT SELECT ON *.* TO 'monitor'@'%';

FLUSH PRIVILEGES;

Użytkownik aplikacji

Użytkownik aplikacji w ProxySQL to standardowe konto bazy danych używane przez Twoje aplikacje do łączenia się i wykonywania zapytań w klastrze Galera. To przez tego użytkownika Twoja aplikacja bezpośrednio współdziała z bazą danych, pobierając i manipulując danymi.

Wykonaj to zapytanie w powłoce MariaDB na węźle głównym, aby dodać użytkownika aplikacji:

GRANT ALL PRIVILEGES ON *.* TO 'test'@'%' IDENTIFIED BY 'test' WITH GRANT OPTION;

FLUSH PRIVILEGES;

Weryfikacja

Zweryfikuj utworzenie użytkowników na wszystkich węzłach za pomocą tego polecenia:

mariadb -u root -e "SELECT user, host FROM mysql.user;"

Konfiguracja

Utwórz plik konfiguracyjny /etc/proxysql.cnf na każdym węźle i wklej następującą zawartość:

datadir="/var/lib/proxysql"
admin_variables={
        admin_credentials="admin:admin"
        mysql_ifaces="127.0.0.1:6032"
}
mysql_variables={
        threads=4
        max_connections=2048
        monitor_username="monitor"
        monitor_password="monitor"
}
mysql_servers=(
        { address="galera0" , port=3306 , hostgroup=0 },
        { address="galera1" , port=3306 , hostgroup=0 },
        { address="galera2" , port=3306 , hostgroup=0 })
mysql_users=(
        { username = "test" , password = "test" , default_hostgroup = 0 , active = 1 })
mysql_query_rules=(
        {
                rule_id=2
                active=1
                match_pattern="^SELECT.*"
                destination_hostgroup=0
                apply=1
        })

Włącz i uruchom ProxySQL za pomocą tych poleceń:

sudo systemctl start proxysql

sudo systemctl enable proxysql

sudo proxysql --reload

Sprawdź konfigurację ProxySQL za pomocą tego polecenia:

mysql -u admin -padmin -h 127.0.0.1 -P6032 -e "SELECT hostname,status FROM mysql_servers;"

Wszystkie węzły muszą być online:

+----------+--------+
| hostname | status |
+----------+--------+
| galera0  | ONLINE |
| galera1  | ONLINE |
| galera2  | ONLINE |
+----------+--------+

Keepalived

Keepalived zarządza wirtualnym adresem IP, zapewniając jeden punkt dostępu do klastra i automatyzując przełączanie awaryjne w przypadku awarii węzła. Monitoruje stan zdrowia węzłów MariaDB i przekierowuje ruch do zdrowego węzła, jeśli wystąpi awaria, utrzymując wysoką dostępność. Konfiguracja definiuje Virtual Router ID 51 i używa interfejsu eth0. Na węźle głównym state jest ustawione na MASTER z priorytetem 100. Węzły zapasowe są skonfigurowane z state jako BACKUP, mając priorytety odpowiednio 90 i 80. virtual_ipaddress jest ustawione na 192.168.10.50 na wszystkich węzłach. VIP i węzły muszą być w tej samej podsieci. Hosting musi obsługiwać VIP dla VPS. Uwierzytelnianie jest włączone z wspólnym hasłem 1234. Ustawienie advert_int definiuje, jak często węzeł główny wysyła reklamy VRRP. Niższa wartość oznacza częstsze reklamy, potencjalnie przyspieszając wykrywanie awarii; wyższa wartość oznacza rzadsze reklamy, potencjalnie opóźniając awarię, ale zmniejszając obciążenie sieci.

Konfiguracja

Utwórz plik konfiguracyjny /etc/keepalived/keepalived.conf na każdym węźle i wklej następującą zawartość:

vrrp_instance VI_1 {
    state <NODE_STATE>
    interface eth0
    virtual_router_id 51
    priority <NODE_PRIORITY>
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1234
    }
    virtual_ipaddress {
        192.168.10.50/24
    }
}

Zmień <NODE_STATE> i <NODE_PRIORITY> zgodnie z opisem powyżej. Włącz i uruchom usługę keepalived:

sudo systemctl enable keepalived && sudo systemctl start keepalived

Weryfikacja

Aby zweryfikować konfigurację, użyj VIP skonfigurowanego przez Keepalived i portu skonfigurowanego przez ProxySQL. Sprawdź rozmiar klastra na przykład:

mariadb -u test -ptest -h 192.168.10.50 -P6033 -D galtest -e "SHOW STATUS LIKE 'wsrep_cluster_size';"

Oczekiwana odpowiedź musi odpowiadać weryfikacji Galera:

+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 3     |
+--------------------+-------+

Teraz możesz losowo restartować węzły, sprawdzać rozmiar klastra i dostępność danych.

Podsumowanie

Ten przewodnik pokazał, jak zbudować wysoce dostępny klaster MariaDB wykorzystujący replikację Galera, ProxySQL do routingu zapytań oraz Keepalived do zarządzania wirtualnym IP na Debianie. Ta architektura zapewnia kilka kluczowych korzyści, w tym wysoką dostępność z automatycznym przełączaniem awaryjnym, spójność danych dzięki synchronicznej replikacji oraz poprawioną wydajność dzięki ProxySQL. Łącząc te technologie, możesz zbudować solidne i odporne środowisko bazodanowe zdolne do obsługi zwiększonych obciążeń i minimalizacji przestojów.