2. Februar 2021

Verteilter MariaDB Galera Cluster mit Standort-Affinität

In meinem Artikel Georedundanter hochverfügbarer MariaDB Galera Cluster mit ProxySQL vom 28. April 2020 hatte ich bereits beschrieben, wie man einen MariaDB Galera Cluster für Business Continuity und Desaster Recovery über zwei Standorte verteilen kann. In diesem Artikel soll es darum gehen, wie man vorgeht, wenn an jedem der Standorte Anwender bzw. Applikationen sind, die möglichst auf die lokalen Knoten zugreifen sollen und nur dann die entfernten Knoten nutzen, wenn die lokalen nicht erreichbar oder überlastet sind.

Das grundsätzliche Setup entspricht dem aus dem zuvor erwähnten Artikel. Hier soll allerdings das Load-Balancing so konfiguriert werden, dass Verbindungen standort-affin sind. Die zusätzliche Herausforderung ist in diesem Fall, dass im Fall eines Split Brain des Clusters aufgrund eines Ausfalls der Netzverbindung zwischen den Standorten nur eine Seite aktiv bleiben darf, dann aber auch alle Anwendungen auf der inaktiven Seite keine aktive Datenbankverbindung mehr haben, da sie ebenfalls über die unterbrochene Netzverbindung zur gegenüberliegenden Seite sich verbinden müssten.

Der MariaDB Galera Cluster

Im Gegensatz zur BC/DR Lösung aus dem früheren Artikel besteht hier das Problem, dass beide Seiten bei einem Split Brain idealerweise weiter arbeiten sollten. Das kann allerdings zu Inkonsistenzen führen, die vom Cluster beim Re-Join nicht aufgelöst werden können. Also darf auch in diesem Fall bei einem Split Brain nur eine Cluster-Seite aktiv bleiben, was uns wieder zu dem gewichteten Quorum führt. Sollen also die Anwendungen und Clients auf der inaktiven Seite weiter arbeiten können, muss sichergestellt sein, dass sie die aktive Seite erreichen können. Dies kann mit den Möglichkeiten des Clusters allein nicht erreicht werden.

Netzwerk-Redundanz

Die Netzwerkverbindungen für die Intra-Cluster Kommunikation (standardmäßig Ports 4567, 4568, 4444) und die für den Client-Zugriff (standardmäßig 3306) können auf unterschiedliche Netze gelegt werden. Zudem ist es sinnvoll das Management Out-of-Band (OOB), also über ein drittes Netz zu realisieren. Für den hier betrachteten Fall bedeutet das, dass für eine Near-Zero-Downtime Verfügbarkeit (99,999% oder besser) die Netze für die Cluster-Kommunikation und die Client-Anbindung

• physisch getrennt sind,
• jeweils dual-homed realisiert werden,
• auf physisch getrennten Trassen geführt werden.

Damit sinkt die Wahrscheinlichkeit, dass

1. ein Split-Brain auftritt,
2. Intra-Cluster- und Client-Verbindungen gleichermaßen davon betroffen sind.

Jedem, der sich mit Business Continuity und Desaster Recovery befasst, ist bewusst, dass es immer ein minimales Restrisiko für eine Totalausfall gibt. Ziel ist es dieses auf ein akzeptables Maß zu reduzieren. Dabei spielt auch immer eine Rolle, wie die Zeit für die Wiederherstellung einer unterbrochenen Verbindung zwischen den Standorten (Mean Time to Repair, MTTR) ist. Wenn diese kurz genug ist, dass eine Nichterreichbarkeit des Clusters auf der inaktiven Seite toleriert werden kann, dann kann natürlich der Aufwand auf Netzwerkebene reduziert werden.

Falls das Management über ein OOB-Netz erfolgt und auch das Monitoring darüber läuft, kann dies auch dazu genutzt werden, im Fall eines Totalausfalls der Cluster-Knoten auf der "primären" Seite skript-gesteuert die "sekundäre" Seite in den aktiven Zustand zu versetzen.

Vorteile	Nachteile
Die Datenbestände beider Standorte sind immer synchron.	Bei Split-Brain ist ein Standort im non-primary Status und damit für Anwendungen nicht erreichbar.
Gleichzeitige Änderungen am Datenbestand an beiden Standorten, die zu Konflikten führen werden erkannt und aufgelöst.	Sollen bei Split-Brain-Situationen Anwendungen auf den entfernten Standort zugreifen können, sind ergänzende Maßnahmen auf Netzwerkebene erforderlich.
Bei Split-Brain geht ein Standort in den non-primary Status, um Dateninkonsistenzen durch nicht synchronisierte Änderungen zu vermeiden.	Bei langsamen oder unsteten Netzverbindungen für die Intra-Cluster-Kommunikation kann es zu merklichen Performance-Einbußen und vermehrten Verbindungsabbrüchen für die Anwendungen auf der "sekundären" Seite kommen.

Cluster und Geo-Replikation

Ein alternativer Ansatz wäre je einen Cluster an jedem Standort zu betreiben und die Standorte mit MariaDB Replikation zu verbinden. Dabei kann sowohl die asynchrone wie auch die semi-synchrone Replikation genutzt werden. Damit dies allerdings zuverlässig funktioniert, sollte für diesen Fall MariaDB 10.5 eingesetzt werden. Mit MariaDB 10.5 werden im Galera-Cluster die InnoDB Global Transaction IDs über alle Cluster-Knoten synchronisiert. Bei einem Ausfall einer Master-Slave-Verbindung kann auf einen anderen entfernten Knoten als Master verbunden werden, ohne dass die Replikation dadurch wegen ungültiger GTID-Abfolge abbricht.

Die Replikation kann sowohl semi-synchron oder asynchron erfolgen. Bei semi-synchroner Replikation wartet der sendende Master beim COMMIT bis der empfangende Slave den Empfang der Transaktion quittiert, d.h., bestätigt das die Transaktion im relay-log abgelegt wurde und zur Verarbeitung in die Datenbank hinein bereitsteht. Bei der asynchronen Replikation wird auf Master-Seite ein COMMIT sofort quittiert und die Übertragung der Transaktion auf den Slave erfolgt unabhängig davon. Kann eine Transaktion nicht (mehr) an den entfernten Server übertragen werden, so geht sie bei einem Absturz des Masters verloren.

Der Vorteil der Replikationslösung ist, dass im Fall eines Split-Brain beide Cluster aktiv bleiben und auf beiden Seiten weiter gearbeitet werden kann. Sobald die Verbindung wieder steht und die Replikation soweit erforderlich wieder angestartet wurde, werden zwischenzeitlich erfolgte Änderungen an die jeweilige Gegenseite übertragen.

Vor- und Nachteile der Replikation

Vorteile	Nachteile
Beide Standorte können auch bei Netzwerkausfall weiter arbeiten.	Änderungen am gleichen Satz auf beiden Seiten führen zu Race Condition.
Aufgelaufene Veränderungen am Datenbestand werden automatisch abgeglichen.	Änderungen am Datenbestand sind immer erst mit Verzögerung auf der Gegenseite verfügbar.
Asynchrone Replikation funktioniert auch bei geringerer Bandbreite zwischen den Standorten oder bei schlechten Netzverbindungen.	Wenn Synchronität der Datenbestände an beiden Standorten gefordert ist, ist die Replikation nicht einsetzbar.

Gerne unterstützen wir Sie bei Ihrer Cluster-Lösung mit MariaDB und ProxySQL.