Einrichtung eines hochverfügbaren Datenbankclusters mit MariaDB Galera, ProxySQL, Keepalived und Debian 13 | INTROSERV
EUR
european

EUR

usa

USD

German De
Ex. VAT Ex. VAT 0%

Einrichtung eines hochverfügbaren Datenbankclusters mit MariaDB Galera, ProxySQL, Keepalived und Debian 13

Einleitung

Da Ihre Anwendungen immer umfangreicher und wichtiger werden, ist die Gewährleistung einer kontinuierlichen Verfügbarkeit von entscheidender Bedeutung. Ausfälle der Datenbank können zu Umsatzverlusten, verärgerten Benutzern und einem Imageverlust führen. Dieser Leitfaden zeigt, wie Sie einen hochverfügbaren (HA) MariaDB-Cluster unter Verwendung von Galera-Replikation, ProxySQL für intelligentes Abfrage-Routing und Keepalived für die Verwaltung virtueller IP-Adressen unter Debian aufbauen.

Diese Architektur kombiniert die Stärken der einzelnen Technologien, um eine robuste und ausfallsichere Datenbankumgebung zu schaffen. MariaDB Galera bietet synchrone Multi-Master-Replikation und gewährleistet so die Datenkonsistenz über mehrere Knoten hinweg. ProxySQL fungiert als Abfrage-Router und Lastverteiler, sorgt für ein intelligentes Datenverkehrsmanagement und entlastet die Datenbankserver. Keepalived verwaltet eine virtuelle IP-Adresse, bietet einen zentralen Zugangspunkt zum Cluster und automatisiert das Failover im Falle von Knotenausfällen.

Dieser Leitfaden setzt Erfahrung in der Linux-Systemadministration, grundlegende Kenntnisse im Bereich Netzwerke (TCP/IP, DNS) sowie Vertrautheit mit der Datenbankadministration voraus. Wir konzentrieren uns auf die Konfiguration und Integration dieser Technologien in einer Debian-Umgebung.

Wesentliche Vorteile dieser Architektur:

  • Hohe Verfügbarkeit: Das automatisierte Failover gewährleistet minimale Ausfallzeiten.
  • Datenkonsistenz: Die synchrone Replikation garantiert Datenkonsistenz über alle Knoten hinweg.
  • Verbesserte Leistung: ProxySQL optimiert das Abfrage-Routing und entlastet die Datenbankserver.
  • Vereinfachte Verwaltung: Eine einzige virtuelle IP-Adresse vereinfacht die Anwendungskonfiguration und den Zugriff.

Was Sie benötigen:

  • Drei Debian 13-VPS oder -Server.
  • Root- oder sudo-Zugriff auf alle Server.
  • Vertrautheit mit der Befehlszeilenschnittstelle.
  • Grundlegende Kenntnisse über TCP/IP-Netzwerke und DNS.

Voraussetzungen

Verbindung der Knoten

Eine korrekte Hostnamenauflösung ist für den ordnungsgemäßen Betrieb des Clusters unerlässlich. Jeder Server muss die anderen Server anhand ihres Namens finden können. Wir verwenden Hostnamen, um die Verwaltung zu vereinfachen. Die IP-Adressen der Knoten müssen sich im selben Subnetz befinden.

Zuordnung von Hostnamen und IP-Adressen

  • galera0 (Master-Knoten): 192.168.10.10
  • galera1 (Slave-Knoten): 192.168.10.11
  • galera2 (Slave-Knoten): 192.168.10.12

Die Auflösung der Hostnamen können Sie entweder über die Datei `/etc/hosts` oder über DNS vornehmen.

  • Verwendung von /etc/hosts (einfachere Einrichtung): Diese Methode eignet sich für Test- und Entwicklungsumgebungen. Fügen Sie auf jedem Server Einträge in die Datei /etc/hosts hinzu, die den Hostnamen des Servers seiner statischen IP-Adresse zuordnen.
  • Verwendung von DNS (für den Produktivbetrieb empfohlen): Konfigurieren Sie in größeren oder komplexeren Umgebungen DNS-Einträge (A-Einträge), die die Hostnamen der Server ihren jeweiligen IP-Adressen zuordnen.

Überprüfung

Überprüfen Sie nach der Konfiguration der Hostnamenauflösung mithilfe des Befehls `ping`, ob jeder Server die Hostnamen der anderen Server auflösen kann. Führen Sie beispielsweise von `galera0` aus den Befehl `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. In diesem Abschnitt werden die erforderlichen Schritte für Debian-basierte Systeme beschrieben.

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 zunächst Ihre Paketlisten und Pakete. Führen Sie den folgenden 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 Sicherheitsskript auf jedem Knoten aus:

sudo mariadb-secure-installation

Dieses Skript führt zwei wichtige Schritte durch: Es fordert Sie auf, ein starkes Root-Passwort für den MariaDB-Server festzulegen, und es entfernt alle unsicheren Standardkonfigurationen. Befolgen Sie die Anweisungen auf dem Bildschirm, um diesen Vorgang abzuschließen.

Fernzugriff auf MariaDB aktivieren

Führen Sie diese Befehle aus, um den Fernzugriff 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 ermöglicht die synchrone Replikation von Daten über alle Knoten im Cluster hinweg. Das bedeutet, dass jede Änderung, die an der Datenbank auf einem Knoten vorgenommen wird, automatisch und gleichzeitig auf alle anderen Knoten übertragen wird. Die wichtigsten Vorteile von Galera in dieser Konfiguration:

  • Hohe Verfügbarkeit: Wenn ein Knoten ausfällt, stellen die anderen Knoten den Datendienst ohne Unterbrechung fort. Der Cluster ernennt automatisch einen noch funktionierenden Knoten zum Primärknoten.
  • Datenkonsistenz: Dank der synchronen Replikation sind die Daten auf allen Knoten stets konsistent. Dadurch wird das Risiko veralteter Lesevorgänge ausgeschlossen – Sie lesen immer die aktuellste Version der Daten.
  • Skalierbarkeit beim Lesen: Da die Daten auf mehrere Knoten repliziert werden, können Sie Leseabfragen über den Cluster verteilen, um die Leseleistung zu steigern.

Im Wesentlichen stellt Galera sicher, dass Ihre MariaDB-Datenbank hochverfügbar, konsistent und skalierbar bleibt – entscheidende Anforderungen für viele Anwendungen.

Konfiguration

Erstellen Sie auf jedem Knoten eine Konfigurationsdatei /etc/mysql/conf.d/galera.cnf. Der Inhalt ist identisch, mit Ausnahme des Namens und der Adresse des jeweiligen Knotens. Fügen Sie diese Vorlage ein:

[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

Ändern Sie <node_name> und <node_address> auf jedem Knoten. Verwenden Sie „galera0“ für den ersten Knoten und so weiter.

Info

wsrep_cluster_address — Geben Sie auf jedem Knoten die Hostnamen aller Knoten im Cluster an. wsrep_node_name — Muss für jeden Knoten eindeutig sein (z. B. galera0, galera1, galera2). wsrep_node_address — Setzen Sie diesen Wert auf den Hostnamen des Knotens, den Sie gerade konfigurieren.

Starten Sie den Cluster

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

Überprüfen Sie die Einrichtung

Überprüfen Sie die Clustergröße

Stellen Sie auf einem beliebigen Knoten eine Verbindung zu MariaDB her und überprüfen Sie den Clusterstatus. Stellen Sie eine Verbindung zur Datenbank her:

sudo mariadb -u root -p

Überprüfen Sie den Status der Cluster-Knoten in der MariaDB-Shell:

SHOW STATUS LIKE 'wsrep_cluster_size';

„wsrep_cluster_size“ sollte der Anzahl unserer Knoten entsprechen.

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

Replikation testen

Erstellen Sie auf einem beliebigen Knoten eine Testdatenbank 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 anschließend die Daten auf anderen Knoten mithilfe der folgenden SQL-Abfrage über die MariaDB-Shell:

USE galtest; SELECT * FROM messages;

Die Testnachricht sollte angezeigt werden:

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 ist in dieser Clusterkonfiguration mehr als nur ein einfacher Vermittler; es verbessert die Leistung, Zuverlässigkeit und Verwaltbarkeit Ihrer Datenbank erheblich. ProxySQL bildet eine entscheidende Schicht zwischen Ihren Anwendungen und Ihrem Galera-Cluster. Seine Hauptzwecke sind:

  • Abfrage-Caching: ProxySQL speichert häufig ausgeführte Abfragen intensiv im Cache. Anstatt den Galera-Cluster wiederholt nach denselben Daten abzufragen, liefert es das zwischengespeicherte Ergebnis aus, wodurch die Datenbankauslastung erheblich reduziert und die Antwortzeiten verbessert werden. Dies ist besonders vorteilhaft für leseintensive Anwendungen.
  • Verbindungspooling: ProxySQL unterhält einen Pool persistenter Verbindungen zum Galera-Cluster. Das Herstellen einer Datenbankverbindung ist ein ressourcenintensiver Vorgang. Durch Verbindungspooling wird dieser Overhead vermieden, indem bestehende Verbindungen wiederverwendet werden, was die Leistung weiter steigert.
  • Lastenausgleich und Abfrageweiterleitung: ProxySQL kann Abfragen intelligent an verschiedene Knoten in Ihrem Galera-Cluster weiterleiten, basierend auf Faktoren wie Serverauslastung, Abfragetyp oder Datenaffinität. So können Sie die Arbeitslast verteilen und die Leistung Ihres Clusters maximieren.
  • Abfrageoptimierung: ProxySQL kann Abfragen umschreiben, um sie effizienter zu gestalten, und dabei möglicherweise die Funktionen von Galera für eine optimale Ausführung nutzen.
  • Fehlererkennung und Weiterleitung: ProxySQL überwacht kontinuierlich den Betriebszustand Ihrer Galera-Knoten. Fällt ein Knoten aus, leitet ProxySQL Abfragen automatisch an funktionierende Knoten weiter und gewährleistet so einen unterbrechungsfreien Betrieb.

Im Wesentlichen fungiert ProxySQL als intelligenter Traffic-Manager und Leistungsoptimierer für Ihren Galera-Cluster und verbessert dessen Effizienz und Ausfallsicherheit erheblich.

Hinweise

Info

Die unten aufgeführten Anmeldedaten und Passwörter dienen ausschließlich zu Schulungszwecken. Verwenden Sie für die Produktionsumgebung sichere Passwörter.

Benutzereinrichtung

Monitor-Benutzer

Der Monitor-Benutzer in ProxySQL ist ein dediziertes Datenbankkonto, das ausschließlich für Überwachungstools bestimmt ist, um sicher auf interne Statistiken und Metriken zugreifen zu können. Er ist mit minimalen Berechtigungen konfiguriert – lediglich SELECT-Zugriff –, wodurch die Integrität und Sicherheit Ihrer Daten gewährleistet wird und gleichzeitig eine umfassende Leistungsüberwachung ermöglicht wird.

Führen Sie diese Abfrage in der MariaDB-Shell auf dem Master-Knoten aus, um den Überwachungsbenutzer hinzuzufügen:

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

Anwendungsbenutzer

Der Anwendungsbenutzer in ProxySQL ist ein Standard-Datenbankkonto, das von Ihren Anwendungen verwendet wird, um eine Verbindung zum zugrunde liegenden Galera-Cluster herzustellen und Abfragen auszuführen. Über diesen Benutzer interagiert Ihre Anwendung direkt mit der Datenbank, um Daten abzurufen und zu bearbeiten.

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;

Überprüfung

Überprüfen Sie die Erstellung des Benutzers auf allen Knoten mit diesem Befehl:

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

Konfiguration

Erstellen Sie auf jedem Knoten eine Konfigurationsdatei /etc/proxysql.cnf 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-Konfiguration 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, stellt einen einzigen Zugangspunkt zum Cluster bereit und automatisiert das Failover im Falle von Knotenausfällen. Es überwacht den Zustand der MariaDB-Knoten und leitet den Datenverkehr bei einem Ausfall auf einen funktionsfähigen Knoten um, wodurch eine hohe Verfügbarkeit gewährleistet wird. Die Konfiguration definiert die Virtual Router ID 51 und verwendet die Schnittstelle eth0. Auf dem Master-Knoten ist der Status auf „MASTER“ mit einer Priorität von 100 gesetzt. Die Backup-Knoten sind mit dem Status „BACKUP“ konfiguriert und haben Prioritäten von 90 bzw. 80. Die „virtual_ipaddress“ ist auf allen Knoten auf 192.168.10.50 gesetzt. VIP und Knoten müssen sich im selben Subnetz befinden. Der Hosting-Anbieter muss VIP für VPS unterstützen. Die Authentifizierung ist mit einem gemeinsamen Passwort von 1234 aktiviert. Die Einstellung „advert_int“ legt fest, wie häufig der Master-Knoten VRRP-Advertisements sendet. Ein niedrigerer Wert bedeutet häufigere Anzeigen, was die Failover-Erkennung potenziell beschleunigen kann; ein höherer Wert bedeutet seltenere Anzeigen, was das Failover potenziell verzögert, aber den Netzwerk-Overhead reduziert.

Konfiguration

Erstellen Sie auf jedem Knoten eine Konfigurationsdatei /etc/keepalived/keepalived.conf 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

Überprüfung

Um die Einrichtung zu überprüfen, verwenden Sie die über Keepalived konfigurierte VIP und den über ProxySQL konfigurierten Port. Überprüfen Sie beispielsweise 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-Überprüfung übereinstimmen:

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

Nun können Sie Knoten nach Belieben neu starten, die Clustergröße überprüfen und die Datenverfügbarkeit testen.

Keepalived cluster verification result

Fazit

In dieser Anleitung wurde gezeigt, wie man unter Debian einen hochverfügbaren MariaDB-Cluster unter Verwendung der Galera-Replikation, von ProxySQL für das Abfrage-Routing und von Keepalived für die Verwaltung virtueller IP-Adressen aufbaut. Diese Architektur bietet mehrere wesentliche Vorteile, darunter Hochverfügbarkeit mit automatisiertem Failover, Datenkonsistenz durch synchrone Replikation und verbesserte Leistung durch ProxySQL. Durch die Kombination dieser Technologien können Sie eine robuste und ausfallsichere Datenbankumgebung aufbauen, die in der Lage ist, erhöhte Arbeitslasten zu bewältigen und Ausfallzeiten zu minimieren.

VAT

  • Other

    Ex. VAT

    0%
  • austria

    Austria

    20%
  • Belgium

    Belgium

    21%
  • Bulgaria

    Bulgaria

    20%
  • Croatia

    Croatia

    25%
  • Cyprus

    Cyprus

    19%
  • Czech Republic

    Czech Republic

    21%
  • Denmark

    Denmark

    25%
  • Estonia

    Estonia

    22%
  • France

    France

    20%
  • Finland

    Finland

    24%
  • Germany

    Germany

    19%
  • Greece

    Greece

    24%
  • Hungary

    Hungary

    27%
  • Ireland

    Ireland

    23%
  • Italy

    Italy

    22%
  • Latvia

    Latvia

    21%
  • Lithuania

    Lithuania

    21%
  • Luxembourg

    Luxembourg

    17%
  • Malta

    Malta

    18%
  • Netherlands

    Netherlands

    21%
  • Poland

    Poland

    23%
  • Portugal

    Portugal

    23%
  • Romania

    Romania

    19%
  • Slovakia

    Slovakia

    20%
  • Slovenia

    Slovenia

    22%
  • Spain

    Spain

    21%
  • Sweden

    Sweden

    25%
  • USA

    USA

    0%
european
states
  • germany
  • Español
  • Italiano
  • Poland
  • Русский
  • Slovenski
  • Türkçe
  • ukraine
  • kingdom
  • French
  • Hrvatska
  • Other
  • Austria
  • Belgium
  • Bulgaria
  • Croatia
  • Cyprus
  • Czech Republic
  • Denmark
  • Estonia
  • Finland
  • France
  • Germany
  • Greece
  • Hungary
  • Ireland
  • Italy
  • Latvia
  • Lithuania
  • Luxembourg
  • Malta
  • Netherlands
  • Poland
  • Portugal
  • Romania
  • Slovakia
  • Slovenia
  • Spain
  • Sweden
  • USA