Konfiguracja klastra baz danych o wysokiej dostępności z wykorzystaniem MariaDB Galera, ProxySQL, Keepalived i Debiana 13

Wprowadzenie

Wraz ze wzrostem skali i znaczenia aplikacji zapewnienie ciągłej dostępności staje się kluczowe. Przestoje baz danych mogą prowadzić do utraty przychodów, frustracji użytkowników i utraty reputacji. Niniejszy przewodnik pokazuje, jak zbudować klaster MariaDB o wysokiej dostępności (HA) z wykorzystaniem replikacji Galera, ProxySQL do inteligentnego kierowania zapytań oraz Keepalived do zarządzania wirtualnymi adresami IP w systemie Debian.

Architektura ta łączy zalety każdej z tych technologii, zapewniając solidne i odporne środowisko bazodanowe. MariaDB Galera zapewnia synchroniczną replikację typu multi-master, gwarantując spójność danych w wielu węzłach. ProxySQL pełni rolę routera zapytań i modułu równoważenia obciążenia, zapewniając inteligentne zarządzanie ruchem i odciążając serwery baz danych. Keepalived zarządza wirtualnym adresem IP, zapewniając pojedynczy punkt dostępu do klastra i automatyzując przełączanie awaryjne w przypadku awarii węzłów.

Niniejszy przewodnik zakłada doświadczenie w administrowaniu systemami Linux, znajomość podstawowych pojęć sieciowych (TCP/IP, DNS) oraz znajomość administrowania bazami danych. Skoncentrujemy się na konfiguracji i integracji tych technologii w środowisku Debiana.

Główne zalety tej architektury:

• Wysoka dostępność: Zautomatyzowane przełączanie awaryjne zapewnia minimalny czas przestoju.
• Spójność danych: Replikacja synchroniczna gwarantuje spójność danych we wszystkich węzłach.
• Zwiększona wydajność: ProxySQL optymalizuje routing zapytań i zmniejsza obciążenie serwerów baz danych.
• Uproszczone zarządzanie: Pojedynczy wirtualny adres IP upraszcza konfigurację aplikacji i dostęp do nich.

Co będzie potrzebne:

• Trzy serwery lub VPS z systemem Debian 13.
• Dostęp z uprawnieniami roota lub sudo do wszystkich serwerów.
• Znajomość interfejsu wiersza poleceń.
• Podstawowa znajomość sieci TCP/IP i systemu DNS.

Wymagania wstępne

Połączenie węzłów

Prawidłowe rozpoznawanie 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

Rozpoznawanie nazw hostów można zrealizować za pomocą pliku /etc/hosts lub systemu DNS.

• Korzystanie z pliku /etc/hosts (prostsza konfiguracja): Ta metoda jest odpowiednia dla środowisk testowych i programistycznych. Na każdym serwerze należy dodać do pliku /etc/hosts wpisy mapujące nazwę hosta serwera na jego statyczny adres IP.
• Korzystanie z DNS (zalecane w środowisku produkcyjnym): W przypadku większych lub bardziej złożonych środowisk należy skonfigurować rekordy DNS (rekordy A), które przypisują nazwy hostów serwerów do odpowiednich adresów IP.

Weryfikacja

Po skonfigurowaniu rozpoznawania nazw hostów sprawdź, czy każdy serwer może rozpoznać nazwy hostów pozostałych serwerów za pomocą polecenia ping. Na przykład z serwera galera0 uruchom polecenie ping galera1. Powinieneś otrzymać odpowiedź.

Instalacja wymaganych pakietów

Zanim będzie można skonfigurować klaster Galera, należy zainstalować niezbędne pakiety MariaDB na każdym węźle. W tej sekcji opisano 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 same pakiety. Uruchom następujące 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

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

sudo mariadb-secure-installation

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

Włącz zdalny dostęp do MariaDB

Uruchom poniższe 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 między wszystkimi węzłami w klastrze. Oznacza to, że każda zmiana wprowadzona w bazie danych na jednym węźle jest automatycznie i jednocześnie propagowana do wszystkich pozostałych węzłów. Kluczowe zalety Galery w tej konfiguracji:

• Wysoka dostępność: Jeśli jeden węzeł ulegnie awarii, pozostałe węzły nadal obsługują dane bez zakłóceń. Klaster automatycznie promuje działający węzeł do roli węzła głównego.
• Spójność danych: Dzięki synchronicznej replikacji dane są zawsze spójne na wszystkich węzłach. Eliminuje to ryzyko odczytu nieaktualnych danych — zawsze odczytujesz najnowszą wersję danych.
• Skalowalność odczytu: Ponieważ dane są replikowane na wielu węzłach, można rozdzielić zapytania odczytowe w całym klastrze, aby zwiększyć wydajność odczytu.

Zasadniczo Galera zapewnia, że baza danych MariaDB pozostaje wysoce dostępna, spójna i skalowalna – są to 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]
# Basic MariaDB settings
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0 # Binds to all network interfaces. Adjust if you have a specific private IP for cluster traffic.
# Galera Provider Configuration
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so # Adjust path if different (e.g., /usr/lib64/galera-4/libgalera_smm.so)
# Galera Cluster Configuration
wsrep_cluster_name="my_galera_cluster" # A unique name for your cluster
# IP addresses of ALL nodes in the cluster, comma-separated.
# Use private IPs if available for cluster communication.
wsrep_cluster_address="gcomm://galera0,galera1,galera2"
# This node's specific configuration
wsrep_node_name="<node_name>" # Must be unique for each node (e.g., node1, node2, node3)
wsrep_node_address="<node_address>" # This node's own IP address

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

Uruchom klaster

Uruchom klaster na pierwszym węźle za pomocą następującego polecenia:

sudo systemctl stop mariadb && sudo galera_new_cluster

Uruchom ponownie MariaDB na pozostałych węzłach:

sudo systemctl restart mariadb

Sprawdź konfigurację

Sprawdź rozmiar klastra

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

sudo mariadb -u root -p

Sprawdź stan 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.

MariaDB [galtest]> SHOW STATUS LIKE
'wsrep_cluster_size';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 3     |
+--------------------+-------+
1 row in set (0.001 sec)

MariaDB [galtest]>

Przetestuj replikację

Utwórz testową bazę danych na dowolnym węźle i wstaw testową wiadomość. Wykonaj następujące polecenia w powłoce 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, używając następującego zapytania SQL w powłoce MariaDB:

USE galtest;
SELECT * FROM messages;

Powinna pojawić się wiadomość testowa:

MariaDB [galtest]> USE galtest;
Database changed
MariaDB [galtest]> SELECT * FROM messages;
+----+--------------------+
| id | text               |
+----+--------------------+
|  7 | Test from galera0! |
+----+--------------------+
1 row in set (0.001 sec)

MariaDB [galtest]>

ProxySQL

ProxySQL w tej konfiguracji klastra to coś więcej niż tylko prosty pośrednik; znacznie poprawia wydajność, niezawodność i łatwość zarządzania bazą danych. ProxySQL stanowi kluczową warstwę pomiędzy aplikacjami a klastrem Galera. Jego główne zadania to:

• Buforowanie zapytań: ProxySQL intensywnie buforuje często wykonywane zapytania. Zamiast wielokrotnie wysyłać do klastra Galera zapytania o te same dane, serwuje wynik z pamięci podręcznej, co znacznie zmniejsza obciążenie bazy danych i skraca czas odpowiedzi. Jest to szczególnie korzystne w przypadku aplikacji intensywnie korzystających z operacji odczytu.
• Pula połączeń: ProxySQL utrzymuje pulę trwałych połączeń z klastrem Galera. Nawiązywanie połączenia z bazą danych jest operacją wymagającą dużych zasobów. Pula połączeń pozwala uniknąć tego obciążenia poprzez ponowne wykorzystanie istniejących połączeń, 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 w oparciu o takie czynniki, jak obciążenie serwera, typ zapytania lub powinowactwo danych. Pozwala to na rozłożenie obciążenia i maksymalizację wydajności klastra.
• Optymalizacja zapytań: ProxySQL może przepisywać zapytania tak, aby były bardziej wydajne, potencjalnie wykorzystując możliwości Galery w celu optymalnego wykonania.
• Wykrywanie awarii i przekierowywanie: ProxySQL nieustannie monitoruje stan węzłów Galera. W przypadku awarii węzła ProxySQL automatycznie przekierowuje zapytania do sprawnych węzłów, zapewniając nieprzerwaną obsługę.

Zasadniczo ProxySQL pełni rolę inteligentnego menedżera ruchu i optymalizatora wydajności klastra Galera, znacznie poprawiając jego wydajność i odporność.

Środki ostrożności

Konfiguracja użytkowników

Użytkownik monitorujący

Użytkownik monitorujący w ProxySQL to dedykowane konto bazodanowe przeznaczone wyłącznie dla narzędzi monitorujących, umożliwiające bezpieczny dostęp do wewnętrznych statystyk i wskaźników. Jest ono skonfigurowane z minimalnymi uprawnieniami – jedynie dostępem SELECT – co zapewnia integralność i bezpieczeństwo danych, jednocześnie umożliwiając kompleksowe monitorowanie wydajności.

Aby dodać użytkownika monitorującego, należy wykonać następujące zapytanie w powłoce MariaDB na węźle głównym:

CREATE USER 'monitor'@'%' IDENTIFIED BY 'monitor';
GRANT SELECT ON *.* TO 'monitor'@'%';
FLUSH PRIVILEGES;

Użytkownik aplikacji

Użytkownik aplikacji w ProxySQL to standardowe konto bazodanowe używane przez aplikacje do łączenia się z klastrem Galera i wykonywania zapytań. To właśnie za pośrednictwem tego użytkownika aplikacja bezpośrednio komunikuje się z bazą danych, pobierając i przetwarzając dane.

Aby dodać użytkownika aplikacji, należy wykonać następujące zapytanie w powłoce MariaDB na węźle głównym:

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

Weryfikacja

Sprawdź utworzenie użytkownika 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 do niego następującą treść:

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ą następujących poleceń:

sudo systemctl start proxysql
sudo systemctl enable proxysql
sudo proxysql --reload

Sprawdź konfigurację ProxySQL za pomocą następującego 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 pojedynczy punkt dostępu do klastra i automatyzując przełączanie awaryjne w przypadku awarii węzłów. Monitoruje stan węzłów MariaDB i przekierowuje ruch do sprawnego węzła w przypadku awarii, zapewniając wysoką dostępność. Konfiguracja definiuje identyfikator wirtualnego routera (Virtual Router ID) 51 i wykorzystuje interfejs eth0. Na węźle głównym stan jest ustawiony na MASTER z priorytetem 100. Węzły rezerwowe są skonfigurowane ze stanem BACKUP, mając priorytety odpowiednio 90 i 80. Adres virtual_ipaddress jest ustawiony na 192.168.10.50 na wszystkich węzłach. Adres VIP i węzły muszą znajdować się w tej samej podsieci. Usługa hostingowa musi obsługiwać adresy VIP dla serwerów VPS. Uwierzytelnianie jest włączone przy użyciu wspólnego hasła 1234. Ustawienie advert_int określa, jak często węzeł główny wysyła komunikaty VRRP. Niższa wartość oznacza częstsze komunikaty, co potencjalnie przyspiesza wykrywanie przełączenia awaryjnego; wyższa wartość oznacza rzadsze komunikaty, co potencjalnie opóźnia przełączenie awaryjne, ale zmniejsza obciążenie sieci.

Konfiguracja

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

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 powyższym opisem. Włącz i uruchom usługę keepalived:

sudo systemctl enable keepalived && sudo systemctl start keepalived

Weryfikacja

Aby zweryfikować konfigurację, użyj adresu VIP skonfigurowanego za pomocą Keepalived oraz portu skonfigurowanego za pomocą ProxySQL. Sprawdź na przykład rozmiar klastra:

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

Oczekiwana odpowiedź musi być zgodna z weryfikacją Galera:

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

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

Wnioski

W niniejszym przewodniku pokazano, jak zbudować klaster MariaDB o wysokiej dostępności, wykorzystujący replikację Galera, ProxySQL do routingu zapytań oraz Keepalived do zarządzania wirtualnymi adresami IP w systemie Debian. Architektura ta zapewnia kilka kluczowych korzyści, w tym wysoką dostępność z automatycznym przełączaniem awaryjnym, spójność danych dzięki replikacji synchronicznej oraz zwiększoną wydajność dzięki ProxySQL. Łącząc te technologie, można zbudować solidne i odporne środowisko bazodanowe, zdolne do obsługi zwiększonego obciążenia i minimalizowania przestojów.