Allzeit bereit!

von Wolfgang Disselhoff

Ausfallsicherheit ist für viele Unternehmen ein Kernkriterium für ihr Datenbanksystem. Kein Wunder: Ihre Existenz hängt davon ab, dass sich Daten jederzeit und unterbrechungsfrei verarbeiten lassen. Wir zeigen, wie Sie für diesen Zweck einen MariaDB-Cluster aufbauen und mithilfe von MaxScale die Verfügbarkeit sowie die Lese-/Schreibleistung der Datenbank verbessern.

Rund-um-die-Uhr-Ausfallsicherheit wird als Hochverfügbarkeit oder High Availability (HA) bezeichnet. Ein hochverfügbares IT-System arbeitet trotz des Ausfalls einer Komponente weiter. Erreicht wird das durch Redundanz: Jede Ressource ist mehrfach vorhanden. Ausfallzeiten durch Störungen sind damit praktisch ausgeschlossen.

Die Verfügbarkeit von IT-Anwendungen wird häufig als Prozentzahl angegeben und beschreibt die Dauer, die ein System störungsfrei arbeitet. Eine typische Angabe zur Verfügbarkeit ist beispielsweise 99,999 Prozent Ausfallsicherheit. Das sind bezogen auf ein Jahr ungefähr fünf Minuten Stillstand.

Das Problem beim Erreichen einer solchen Ausfallsicherheit ist die sogenannte singuläre Fehlerquelle. Damit ist eine Ressource gemeint, deren Ausfall das Gesamtsystem zum Stillstand bringt. Hochverfügbare Datenbanken müssen also durch redundante Instanzen vermeiden, dass eine einzelne defekte Festplatte oder der Ausfall eines Cloudservices die gesamte Anwendung blockiert. Die größte Ausfallsicherheit bietet dabei eine Shared-Nothing-Architektur, bei der keine der betei-ligten Datenbankinstanzen eine gemeinsame Komponente nutzt. In unserem Beispiel setzt das voraus, dass jedes System seine eigene Festplatte hat.

Replikation mit Datenbank-Proxy

Grundprinzip der Hochverfügbarkeit bei Datenbanken ist das mehrfache Speichern derselben Daten etwa durch Spiegelung der Daten auf zwei oder mehr Datenträger. Dabei müssen aber alle Datenträger jeweils die neuesten Daten erhalten. Das macht die Administration und auch die Anwendungsentwicklung komplex. Deshalb ist der Einsatz eines Datenbank-Proxies wie MariaDB-MaxScale sinnvoll.

Der Datenbank-Proxy erzeugt eine Abstraktionsschicht zwischen der Anwendung und den Datenbanken. Für Anwendungen ist sie vollständig transparent. Aus ihrer Sicht (und damit der Entwickler- und Nutzersicht) wirkt der Proxy wie eine normale Datenbankinstanz. Dahinter steht entweder ein primärer Datenbankserver (Primary) mit mehreren Replikaten (Replicas) oder ein Multi-Primary-Cluster mit MariaDB-Galera-Cluster. Die Details reicht MaxScale nicht bis zur Anwendungsschicht weiter.

Der Proxy automatisiert die Verteilung der einzelnen Transaktionen auf die Instanzen. Ebenso automatisch gelingt der Switchover bei geplanten Wartungen an einer Instanz und der Failover beim Ausfall des Primary. MaxScale hat zudem den Vorteil, dass die Topologie ohne Rückwirkung auf die Anwendungen veränderbar ist. Administratoren können also zusätzliche Replicas einfügen und zum Beispiel für die Leseskalierung einsetzen. MaxScale verteilt alle Transaktionen automatisch an die Maria-DB-Instanzen und sorgt für eine sofortige Leistungssteigerung.

Am Beispiel der Primary/Replica-Topologie erläutert: Jede neue Transaktion erhält vom Primary eine globale Transaktions-ID (GTID). Er schreibt sie nun in sein binäres Protokoll. Der Replica fordert mit der GTID der zuletzt verarbeiteten Transaktion eine neue an und erhält die mit der nächsthöheren ID.

Da die Replicas ihre Transaktionen nicht immer in gleicher Geschwindigkeit verarbeiten, sind nicht alle Replicas zur gleichen Zeit auf dem gleichen Stand. MariaDB sorgt dafür, dass auf jedem Replica die Transaktionen in der richtigen Reihenfolge geschrieben werden. Das automatische Failover bestimmt, dass beim Ausfall des Primary der Replica mit der höchsten GTID zum neuen Primary wird.

Es gibt zwei unterschiedliche Formen, wie die beiden Datenbankinstanzen zusammenarbeiten, um Hochverfügbarkeit zu erreichen: Asynchrone und semi-synchrone Replikation. Jenseits dieser Replikationsverfahren gibt es noch das Multi-Primary-Clustering mit synchroner Replikation, das wir im Anschluss erläutern.

Asynchrone und semisynchrone Replikation

Bei der asynchronen Replikation arbeitet der Primary nacheinander alle Transaktionen ab, ohne auf Rückmeldungen der angeschlossenen Knoten zu warten. Diese werden parallel synchronisiert, in der durch die GTID angegebenen Reihenfolge. Dadurch entsteht eine hohe Schreibgeschwindigkeit, sodass dieses Verfahren sich für gemischte und schreibintensive Arbeitslasten eignet. Das sind zum Beispiel Warenkörbe, Kundenbewertungen oder Sensordaten.

Ein Problem entsteht jedoch beim Ausfall des Primary: Mit asynchroner Replikation kann es zu Datenverlusten kommen. Denn möglicherweise sind beim Ausfall noch nicht alle Transaktionen repliziert. Zwar wird der Replica mit der höchsten GTID zum neuen Primary, doch er enthält nicht unbedingt alle Transaktionen.

Die semisynchrone Replikation vermeidet das Risiko von Datenverlusten. Eine Transaktion wird erst dann bestätigt, wenn sie auf wenigstens einem Replica repliziert wurde. Dies wirkt sich allerdings auf die Schreibleistung aus, die im Vergleich zur asynchronen Replikation etwas geringer ist. Diese Form der Replikation ist empfehlenswert für alle Arbeitslasten, bei denen Datenverluste kritisch sind.

Wenn das automatische Failover aktiviert ist, wird beim Ausfall des Primary der Replica mit der höchsten GTID als neuer Primary konfiguriert. Doch da er dank der kurzen Wartezeit bei der Replikation alle Transaktionen repliziert hat, kommt es nicht zu Datenverlusten.

MariaDB für semisynchrone Replikation konfigurieren

Das Standardverfahren ist die asynchrone Replikation. Die semisynchrone Variante starten Sie, indem Sie die entsprechenden Systemvariablen mit dem SQL-Statement SET GLOBAL auf dem Primary setzen. Zusätzlich müssen Sie das Timeout des Primary auf 10 Sekunden konfigurieren:

Auf jedem Replica wiederum müssen Sie folgenden SQL-Befehl ausführen:

Synchrone Replikation mit Multi-Primary-Cluster

Anstatt die Primary/Replica-Replikation zu nutzen, lässt sich alternativ ein Maria-DB-Cluster aufsetzen. Bei diesem ist die Unterscheidung zwischen Primary und Replica aufgehoben. Jeder Rechner (Knoten) arbeitet als Primary und wird zum Schreiben der Daten genutzt. Diese Form der Datenbanktopologie nennt sich Multi-Primary-Clustering. Auch in diesem Fall besteht die kleinstmögliche Cluster-Größe aus drei Knoten.

MariaDB Cluster nutzt das Prinzip der synchronen Replikation: Eine Transaktion wird erst dann bestätigt, wenn alle Änderungen auf jedem Knoten innerhalb des Clusters repliziert wurden. So sind die Datenbestände auf allen Knoten jederzeit ohne Verzögerung aktuell. Der genaue Ablauf der Synchronreplikation ist deutlich aufwendiger als bei der einfachen Primary/Replica-Topologie.

So übernimmt der Ursprungsknoten (Primary Server) nach dem COMMIT-Befehl die Transaktion zunächst von seinem Client. Er sammelt alle an der Datenbank vorgenommenen Änderungen und Primärschlüssel in einem Write-Set und sendet sie dann an die einzelnen Knoten. Das Write-Set wird nun anhand der Primärschlüssel einem deterministischen Zertifizierungstest unterzogen. Dieser überprüft, ob die Transaktionen in der richtigen Reihenfolge eintreffen. Wenn dies der Fall ist, senden die einzelnen Knoten das Ergebnis "Transaktion bestätigt" zurück. Nun führt der Primary-Server den Commit aus und schreibt die Transaktion und anschließend die weiteren Knoten. Zu guter Letzt bekommt der Client Bescheid, dass die Transaktion abgeschlossen ist.

Obwohl die einzelnen Knoten gleichberechtigt sind, gibt es einen Primary-Server. Auf ihn wird nach dem Bestätigen der Transaktion als Erstes geschrieben. Sollte er allerdings stark ausgelastet sein, reagiert der Loadbalancer von MaxScale und leitet die Transaktion an einen weniger ausgelasteten Knoten weiter. Ebenso wie in den anderen Topologien bietet MaxScale auch für einen Cluster das automatische Failover: Wenn ein Knoten ausfällt, entfernt MariaDB Cluster ihn und der Datenbank-Proxy MaxScale stoppt die Weiterleitung von Anfragen an diesen Knoten.

Besonderheiten der synchronen Replikation

Synchrone Replikation hat einen wichtigen Vorteil gegenüber den beiden anderen Verfahren: Es gibt keine Datenverluste oder Inkonsistenzen. Allerdings kann hierbei die Leistung der Datenbank sinken. Deshalb nutzen viele Administratoren auch heute noch die asynchrone Replikation mit der Primary-Replica-Topologie, um die maximale Leistung bei nicht notwendiger Cluster-Konsistenz zu erreichen.

Der MariaDB Galera Cluster nutzt ein etwas anderes Verfahren, das nicht vollständig synchron arbeitet: Die Transaktion wird nicht unmittelbar nach der Zertifizierung auf einen Knoten geschrieben, sondern in die Empfangswarteschlange des Cluster-Knotens gestellt und erst dann geschrieben, wenn die entsprechende Position in der Warteschlange abgearbeitet wird.

Die synchrone Replikation mit MariaDB Galera Cluster ist hochgradig skalierbar. Je nach Anwendungsfall lässt sich durch Hinzufügen zusätzlicher Knoten zum Cluster eine nahezu lineare Skalierbarkeit erreichen. Zudem eignet sich ein Multi-Primary-Cluster auch für eine verteilte Topologie, bei der sich einzelne Knoten in einem anderen Rechenzentrum befinden.

Galera erlaubt zudem einige Optimierungen. "Group Commits" ermöglichen mehrere zusammenhängende Transaktionen in einer Operation durchzuführen. Über die Option "Streaming Replication" können Sie sehr große Transaktionen schon vor dem "Primary"-Commit in kleineren Teilen auf alle Knoten im Cluster verteilen, um sehr große Transaktionen zu beschleunigen.

Multi-Primary-Cluster konfigurieren

Ein grundlegender Multi-Primary-Cluster besteht aus vier dedizierten oder virtuellen Servern. Drei Server sind aus dem eigentlichen Datenbank-Cluster. Auf dem vierten Server läuft der Datenbank-Proxy MaxScale. Er ist das Backend für Anwendungen und arbeitet zusätzlich als Cluster-Manager.

Normalerweise sollte die Zahl der Maria-DB-Server als Cluster-Knoten ungerade sein. Bei einer Erweiterung dieses Dreier-Clusters müssen Sie also zwei MariaDB-Server hinzufügen. Der Grund für diese Anforderung: Bei einem Ausfall muss die Mehrheit der aktiven Knoten verfügbar sein, damit der Datenbank-Proxy einen neuen primären Server für die Replikation auswählen kann, ohne ein "Split Brain"-Szenario zu erzeugen.

Bei drei Knoten darf also nur ein Knoten ausfallen, ohne dass es zu Problemen kommt. Dies gilt auch für vier Knoten: Die Mehrheit ist drei Knoten, es darf also ebenfalls nur ein Knoten ausfallen. Diese beiden Cluster-Konfigurationen haben deshalb die gleiche Fehlertoleranz. Das Hinzufügen eines einzelnen Knotens bringt hier keine höhere Verfügbarkeit. Er kann aber die Leseleistung verbessern.

Bei fünf Knoten verhält es sich anders. Hier ist die Mehrheit zwar ebenfalls drei Knoten, aber es dürfen zwei Knoten ausfallen – die Fehlertoleranz und damit die Verfügbarkeit steigen. Wer also die oben angegebene Basiskonfiguration skalieren möchte, muss zwei Knoten hinzufügen. Umgekehrt ist es bei größeren Konfigurationen mit einer geraden Anzahl an Knoten aus Sicht der Verfügbarkeit effizienter, einen der Knoten zu entfernen. Die Fehlertoleranz bleibt gleich, aber der Verwaltungsaufwand für den Proxy sinkt.

Knoten installieren und konfigurieren

Für den Aufbau des Clusters gelten die Voraussetzungen, dass die einzelnen Knoten sowie der Proxy-Server "Security-Enhanced Linux" (SELinux) einsetzen. Als Distribution muss CentOS ab Release 7 zum Einsatz kommen. Grundsätzlich gelten die Erklärungen aber für alle neueren Distributionen, die auf systemd basieren (Fedora, openSuSE, Debian, Ubuntu et cetera).

Im ersten Schritt installieren Sie auf jedem der drei Cluster-Knoten die folgenden Linux-Pakete:

- epel-release Extra Packages for Enterprise Linux (EPEL)

- socat (Netzwerk-Tool für Socket-Verbindung)

Bei vielen Distributionen startet der Paketmanager bereits MariaDB Server. Sie sollten ihn zunächst mittels systemctl stop mariadb herunterfahren. Passen Sie anschließend die Einstellungen für "SELinux Runtime Configuration" via setenforce 0 an sowie die "SELinux Persistent Configuration" mithilfe von vi /etc/selinux/config und ändern Sie die Einstellung auf "SELINUX=permissive". Für den Betrieb eines Clusters ist es außerdem wichtig, die systemd-Timeout zu verlängern. Andernfalls kann es sein, dass systemd die Knoten beendet, bevor sie ihre Arbeitslasten abgearbeitet haben:

Die einzige für MariaDB-Cluster geeignete Firewall ist iptables:

Danach öffnen sich die folgenden Ports:

MariaDB-Cluster konfigurieren und starten

Die Konfigurationsdatei für MariaDB heißt "my.cnf" und befindet sich entweder in "/etc/my.cnf.d/server.cnf" oder "/etc/my.cnf". Der Listing-Kasten zeigt die Syntax der notwendigen Konfigurationsparameter.

Nun lässt sich der Cluster hochfahren. Starten Sie auf dem ersten Knoten Maria-DB Backup und dann das Skript "galera_ new_cluster" mit dem gleichnamigen Befehl. Es registriert den Namen des Clusters sowie seine ID und führt den ersten Cluster-Knoten aus. Stoßen Sie nun nacheinander auf jedem Knoten MariaDB mit dem Befehl systemctl start mariadb an.

Anschließend ist der hochverfügbare MariaDB-Cluster für die ersten Dateneingaben einsatzbereit. Ein Hinweis: Bei einer vorhandenen Datenbank müssen Sie zunächst MariaDB Backup ausführen, um die Datenbank auf jeden Knoten zu kopieren. Erst anschließend fährt der Cluster hoch.

Fazit

Der Aufbau eines MariaDB-Clusters ist dank der mitgelieferten Werkzeuge und der Automatisierungsfunktionen vergleichsweise einfach. Die in MaxScale integrierte Lastverteilung verbessert die Verfügbarkeit und die Lese-/Schreibleistung der Datenbank.

Die optionale MariaDB-Xpand-Engine bietet verteiltes SQL. Dabei werden alle oder ausgewählte Tabellen nach Last-Kriterien über den Cluster verteilt – mit lückenloser, globaler Verfügbarkeit. Dadurch bleibt die Datenbank konsistent und hochverfügbar. Der Einsatz eines Clusters eignet sich für viele Anwendungen, bei denen es auf möglichst langfristige Datenhaltung ankommt. Darüber hinaus hat der Cluster im Vergleich zur einfachen Replikation auf Replica-Instanzen Vorteile bei regional verteilten Zugriffen auf die Datenbank. Auf diese Weise sind Unternehmen in der Lage, ihre vorhandene, oft verteilte IT-Infrastruktur optimal auszunutzen.

Hochverfügbarkeit mit MariaDB