Einrichten eines hochverfügbaren Datenbankclusters mit MariaDB Galera, ProxySQL, Keepalived und Debian 13.
Einführung
Mit dem Wachstum und der Bedeutung Ihrer Anwendungen wird die Sicherstellung der kontinuierlichen Verfügbarkeit entscheidend. Datenbankausfälle können zu Umsatzeinbußen, frustrierten Nutzern und einem Schaden für Ihren Ruf führen. Dieser Leitfaden zeigt, wie man einen hochverfügbaren (HA) MariaDB-Cluster aufbaut, der Galera-Replikation, ProxySQL für intelligentes Abfragerouting und Keepalived für das Management virtueller IPs auf Debian nutzt.
Diese Architektur kombiniert die Stärken jeder Technologie, um eine robuste und widerstandsfähige Datenbankumgebung bereitzustellen. MariaDB Galera bietet synchrone Multi-Master-Replikation, die Datenkonsistenz über mehrere Knoten hinweg sicherstellt. ProxySQL fungiert als Abfragerouter und Lastverteiler, bietet intelligentes Verkehrsmanagement und entlastet die Datenbankserver. Keepalived verwaltet eine virtuelle IP-Adresse, bietet einen einzigen Zugangspunkt zum Cluster und automatisiert das Failover im Falle von Knotenausfällen.
Dieser Leitfaden setzt Erfahrung in der Linux-Systemadministration, grundlegende Netzwerkkenntnisse (TCP/IP, DNS) und Vertrautheit mit der Datenbankadministration voraus. Wir konzentrieren uns auf die Konfiguration und Integration dieser Technologien in einer Debian-Umgebung.
Hauptvorteile dieser Architektur:
- Hohe Verfügbarkeit: Automatisches Failover sorgt für minimale Ausfallzeiten.
- Datenkonsistenz: Synchrone Replikation garantiert Datenkonsistenz über alle Knoten hinweg.
- Verbesserte Leistung: ProxySQL optimiert das Abfragerouting und reduziert die Last auf den Datenbankservern.
- Vereinfachte Verwaltung: Eine einzige virtuelle IP-Adresse vereinfacht die Anwendungs-Konfiguration und den Zugriff.
Was Sie benötigen:
- Drei Debian 13 VPS oder Server.
- Root- oder Sudo-Zugriff auf alle Server.
- Vertrautheit mit der Befehlszeilenschnittstelle.
- Grundlegendes Verständnis von TCP/IP-Netzwerken und DNS.
Voraussetzungen
Verbindung der Knoten
Eine ordnungsgemäße Hostnamenauflösung ist für das korrekte Funktionieren des Clusters unerlässlich. Jeder Server muss in der Lage sein, die anderen Server per Namen zu finden. Wir verwenden Hostnamen, um die Verwaltung zu vereinfachen. Die IP-Adressen der Knoten müssen im selben Subnetz liegen.
Hostname- und IP-Adresszuordnung
- galera0 (Master-Knoten): 192.168.10.10
- galera1 (Slave-Knoten): 192.168.10.11
- galera2 (Slave-Knoten): 192.168.10.12
Sie können die Hostnamenauflösung entweder mit /etc/hosts oder DNS erreichen.
- Verwendung von
/etc/hosts(Einfachere Einrichtung): Dies ist für Test- und Entwicklungsumgebungen geeignet. Fügen Sie auf jedem Server Einträge hinzu, die den Hostnamen des Servers mit seiner statischen IP-Adresse in der Datei/etc/hostsabbilden. - Verwendung von DNS (Empfohlen für die Produktion): Für größere oder komplexere Umgebungen konfigurieren Sie DNS-Einträge (A-Einträge), die die Server-Hostnamen auf ihre jeweiligen IP-Adressen abbilden.
Verifizierung
Nach der Konfiguration der Hostnamenauflösung überprüfen Sie, ob jeder Server die Hostnamen der anderen Server mit dem Befehl ping auflösen kann. Zum Beispiel, von galera0 aus, führen Sie ping galera1 aus. Sie sollten eine Antwort erhalten.
Installation der erforderlichen Pakete
Bevor Sie den Galera-Cluster konfigurieren können, müssen Sie die erforderlichen MariaDB-Pakete auf jedem Knoten installieren. Dieser Abschnitt beschreibt die erforderlichen Schritte für Debian-basierte Systeme.
Erforderliche Repositories hinzufügen
Fügen Sie die erforderlichen Repositories mit den folgenden Befehlen hinzu:
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
Systemaktualisierung
Aktualisieren Sie zuerst Ihre Paketlisten und Pakete. Führen Sie den nächsten Befehl als Root auf jedem Knoten aus:
apt update && apt upgrade -y
Pakete installieren
Installieren Sie die erforderlichen Pakete auf jedem Knoten mit diesem Befehl:
apt install rsync mariadb-server mariadb-client galera-4 proxysql keepalived -y
MariaDB-Installation sichern
Führen Sie das Sicherheits-Skript auf jedem Knoten aus:
sudo mariadb-secure-installation
Dieses Skript führt zwei entscheidende Schritte aus: Es wird Sie auffordern, ein starkes Root-Passwort für den MariaDB-Server festzulegen, und es wird alle unsicheren Standardkonfigurationen entfernen. Folgen Sie den Bildschirmanweisungen, um diesen Prozess abzuschließen.
Remote-Zugriff auf MariaDB aktivieren
Führen Sie diese Befehle aus, um den Remote-Zugriff auf jedem Knoten zu aktivieren:
sed -i "s/.*bind-address.*/bind-address = 0.0.0.0/" /etc/mysql/mariadb.conf.d/50-server.cnf
systemctl restart mariadb
Galera
Galera bietet synchrone Replikation von Daten über alle Knoten im Cluster. Das bedeutet, dass jede Änderung, die an der Datenbank auf einem Knoten vorgenommen wird, automatisch und gleichzeitig auf alle anderen Knoten übertragen wird. Hauptvorteile von Galera in diesem Setup:
- Hohe Verfügbarkeit: Wenn ein Knoten ausfällt, bedienen die anderen Knoten weiterhin Daten ohne Unterbrechung. Der Cluster fördert automatisch einen überlebenden Knoten zum Primärknoten.
- Datenkonsistenz: Aufgrund der synchronen Replikation sind die Daten immer konsistent über alle Knoten hinweg. Dies eliminiert das Risiko veralteter Lesevorgänge – Sie lesen immer die aktuellste Version der Daten.
- Leseskalierbarkeit: Da Daten über mehrere Knoten repliziert werden, können Sie Leseabfragen über den Cluster verteilen, um die Leseleistung zu erhöhen.
Im Wesentlichen stellt Galera sicher, dass Ihre MariaDB-Datenbank hochverfügbar, konsistent und skalierbar bleibt – entscheidende Anforderungen für viele Anwendungen.
Konfiguration
Erstellen Sie eine Konfigurationsdatei /etc/mysql/conf.d/galera.cnf auf jedem Knoten. Der Inhalt wird identisch sein, mit Ausnahme des Namens und der Adresse jedes Knotens. Fügen Sie diese Vorlage ein:
[mysqld] # Grundlegende MariaDB-Einstellungen binlog_format=ROW default_storage_engine=InnoDB innodb_autoinc_lock_mode=2 bind-address=0.0.0.0 # Galera Provider Konfiguration wsrep_on=ON wsrep_provider=/usr/lib/galera/libgalera_smm.so # Galera Cluster Konfiguration wsrep_cluster_name="my_galera_cluster" wsrep_cluster_address="gcomm://galera0,galera1,galera2" # Spezifische Konfiguration dieses Knotens wsrep_node_name="<node_name>" wsrep_node_address="<node_address>"
Ändern Sie <node_name> und <node_address> auf jedem Knoten. Verwenden Sie galera0 für den ersten Knoten und so weiter.
Wichtig: wsrep_cluster_address — listen Sie die Hostnamen aller Knoten im Cluster auf jedem Knoten auf. wsrep_node_name — muss für jeden Knoten eindeutig sein (z.B. galera0, galera1, galera2). wsrep_node_address — auf den Hostnamen des Knotens setzen, den Sie konfigurieren.
Cluster starten
Starten Sie den Cluster auf dem ersten Knoten mit diesem Befehl:
sudo systemctl stop mariadb && sudo galera_new_cluster
Starten Sie MariaDB auf den anderen Knoten neu:
sudo systemctl restart mariadb
Setup überprüfen
Clustergröße überprüfen
Verbinden Sie sich mit MariaDB auf einem beliebigen Knoten und überprüfen Sie den Clusterstatus. Verbinden Sie sich mit der Datenbank:
sudo mariadb -u root -p
Überprüfen Sie den Status der Clusterknoten in der MariaDB-Shell:
SHOW STATUS LIKE 'wsrep_cluster_size';
wsrep_cluster_size sollte gleich der Anzahl unserer Knoten sein.
+--------------------+-------+ | Variable_name | Value | +--------------------+-------+ | wsrep_cluster_size | 3 | +--------------------+-------+ 1 row in set (0.001 sec)
Replikation testen
Erstellen Sie eine Testdatenbank auf einem beliebigen Knoten und fügen Sie eine Testnachricht ein. Führen Sie die folgenden Befehle in der MariaDB-Shell aus:
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!');
Überprüfen Sie dann die Daten auf anderen Knoten mit der folgenden SQL-Abfrage über die MariaDB-Shell:
USE galtest;
SELECT * FROM messages;
Die Testnachricht sollte erscheinen:
+----+--------------------+ | id | text | +----+--------------------+ | 7 | Test from galera0! | +----+--------------------+ 1 row in set (0.001 sec)
ProxySQL
ProxySQL innerhalb dieses Cluster-Setups ist mehr als nur ein einfacher Vermittler; es verbessert die Leistung, Zuverlässigkeit und Verwaltbarkeit Ihrer Datenbank erheblich. ProxySQL fungiert als entscheidende Schicht zwischen Ihrer(n) Anwendung(en) und Ihrem Galera-Cluster. Seine Hauptzwecke sind:
- Abfrage-Caching: ProxySQL cached aggressiv häufig ausgeführte Abfragen. Anstatt den Galera-Cluster wiederholt nach denselben Daten abzufragen, liefert es das zwischengespeicherte Ergebnis, was die Datenbanklast erheblich reduziert und die Antwortzeiten verbessert. Dies ist besonders vorteilhaft für leseintensive Anwendungen.
- Verbindungs-Pooling: ProxySQL hält einen Pool von persistenten Verbindungen zum Galera-Cluster aufrecht. Das Herstellen einer Datenbankverbindung ist ein ressourcenintensiver Vorgang. Verbindungs-Pooling vermeidet diesen Overhead, indem es bestehende Verbindungen wiederverwendet und so die Leistung weiter steigert.
- Lastverteilung & Abfragerouting: ProxySQL kann Abfragen intelligent an verschiedene Knoten in Ihrem Galera-Cluster basierend auf Faktoren wie Serverlast, Abfragetyp oder Datenaffinität weiterleiten. Dies ermöglicht es Ihnen, die Arbeitslast zu verteilen und die Leistung Ihres Clusters zu maximieren.
- Abfrageoptimierung: ProxySQL kann Abfragen umschreiben, um effizienter zu sein und möglicherweise die Fähigkeiten von Galera für eine optimale Ausführung zu nutzen.
- Fehlererkennung & Routing: ProxySQL überwacht kontinuierlich die Gesundheit Ihrer Galera-Knoten. Wenn ein Knoten ausfällt, leitet ProxySQL Abfragen automatisch an gesunde Knoten weiter, um einen unterbrechungsfreien Dienst sicherzustellen.
Im Wesentlichen fungiert ProxySQL als intelligenter Verkehrsmanager und Leistungsoptimierer für Ihren Galera-Cluster, was dessen Effizienz und Widerstandsfähigkeit erheblich verbessert.
Vorsichtsmaßnahmen
Die unten stehenden Logins und Passwörter dienen nur zu Bildungszwecken. Verwenden Sie starke Passwörter für die Produktionseinrichtung.
Benutzerkonfiguration
Monitor-Benutzer
Der Monitor-Benutzer innerhalb von ProxySQL ist ein dediziertes Datenbankkonto, das ausschließlich für Überwachungstools verwendet wird, um sicher auf interne Statistiken und Metriken zuzugreifen. Es ist mit minimalen Berechtigungen konfiguriert – nur SELECT-Zugriff – und stellt so die Integrität und Sicherheit Ihrer Daten sicher, während eine umfassende Leistungsüberwachung ermöglicht wird.
Führen Sie diese Abfrage in der MariaDB-Shell auf dem Master-Knoten aus, um den Monitor-Benutzer hinzuzufügen:
CREATE USER 'monitor'@'%' IDENTIFIED BY 'monitor';
GRANT SELECT ON *.* TO 'monitor'@'%';
FLUSH PRIVILEGES;
Anwendungsbenutzer
Der Anwendungsbenutzer innerhalb von ProxySQL ist ein Standard-Datenbankkonto, das von Ihren Anwendungen verwendet wird, um sich zu verbinden und Abfragen gegen den zugrunde liegenden Galera-Cluster auszuführen. Über diesen Benutzer interagiert Ihre Anwendung direkt mit der Datenbank, um Daten abzurufen und zu manipulieren.
Führen Sie diese Abfrage in der MariaDB-Shell auf dem Master-Knoten aus, um den Anwendungsbenutzer hinzuzufügen:
GRANT ALL PRIVILEGES ON *.* TO 'test'@'%' IDENTIFIED BY 'test' WITH GRANT OPTION;
FLUSH PRIVILEGES;
Verifizierung
Überprüfen Sie die Benutzererstellung auf allen Knoten mit diesem Befehl:
mariadb -u root -e "SELECT user, host FROM mysql.user;"
Konfiguration
Erstellen Sie eine Konfigurationsdatei /etc/proxysql.cnf auf jedem Knoten und fügen Sie den folgenden Inhalt ein:
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 })
Aktivieren und starten Sie ProxySQL mit diesen Befehlen:
sudo systemctl start proxysql
sudo systemctl enable proxysql
sudo proxysql --reload
Überprüfen Sie Ihre ProxySQL-Einrichtung mit diesem Befehl:
mysql -u admin -padmin -h 127.0.0.1 -P6032 -e "SELECT hostname,status FROM mysql_servers;"
Alle Knoten müssen online sein:
+----------+--------+ | hostname | status | +----------+--------+ | galera0 | ONLINE | | galera1 | ONLINE | | galera2 | ONLINE | +----------+--------+
Keepalived
Keepalived verwaltet eine virtuelle IP-Adresse, bietet einen einzigen Zugangspunkt zum Cluster und automatisiert das Failover im Falle von Knotenausfällen. Es überwacht die Gesundheit der MariaDB-Knoten und leitet den Verkehr zu einem gesunden Knoten um, wenn ein Ausfall auftritt, um eine hohe Verfügbarkeit aufrechtzuerhalten. Die Konfiguration definiert Virtual Router ID 51 und verwendet die Schnittstelle eth0. Auf dem Master-Knoten ist der state auf MASTER mit einer Priorität von 100 gesetzt. Backup-Knoten sind mit einem state von BACKUP konfiguriert, mit Prioritäten von 90 bzw. 80. Die virtual_ipaddress ist auf 192.168.10.50 auf allen Knoten gesetzt. VIP und Knoten müssen im selben Subnetz sein. Das Hosting muss VIP für VPS unterstützen. Die Authentifizierung ist mit einem gemeinsamen Passwort von 1234 aktiviert. Die Einstellung advert_int definiert, wie häufig der Master-Knoten VRRP-Anzeigen sendet. Ein niedrigerer Wert bedeutet häufigere Anzeigen, was die Failover-Erkennung beschleunigen kann; ein höherer Wert bedeutet weniger häufige Anzeigen, was das Failover möglicherweise verzögert, aber die Netzwerklast reduziert.
Konfiguration
Erstellen Sie eine Konfigurationsdatei /etc/keepalived/keepalived.conf auf jedem Knoten und fügen Sie den folgenden Inhalt ein:
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 } }
Ändern Sie <NODE_STATE> und <NODE_PRIORITY> wie oben beschrieben. Aktivieren und starten Sie den Keepalived-Dienst:
sudo systemctl enable keepalived && sudo systemctl start keepalived
Verifizierung
Um das Setup zu überprüfen, verwenden Sie die über Keepalived konfigurierte VIP und den über ProxySQL konfigurierten Port. Überprüfen Sie zum Beispiel die Clustergröße:
mariadb -u test -ptest -h 192.168.10.50 -P6033 -D galtest -e "SHOW STATUS LIKE 'wsrep_cluster_size';"
Die erwartete Antwort muss mit der Galera-Verifizierung übereinstimmen:
+--------------------+-------+ | Variable_name | Value | +--------------------+-------+ | wsrep_cluster_size | 3 | +--------------------+-------+
Jetzt können Sie Knoten zufällig neu starten, die Clustergröße und die Datenverfügbarkeit überprüfen.

Fazit
Dieser Leitfaden hat gezeigt, wie man einen hochverfügbaren MariaDB-Cluster mit Galera-Replikation, ProxySQL für das Abfragerouting und Keepalived für das Management virtueller IPs auf Debian aufbaut. Diese Architektur bietet mehrere wichtige Vorteile, darunter hohe Verfügbarkeit mit automatischem Failover, Datenkonsistenz durch synchrone Replikation und verbesserte Leistung durch ProxySQL. Durch die Kombination dieser Technologien können Sie eine robuste und widerstandsfähige Datenbankumgebung aufbauen, die in der Lage ist, erhöhte Arbeitslasten zu bewältigen und Ausfallzeiten zu minimieren.