georundantes cluster

28. April 2020

Georundanter hochverfügbarer MariaDB Galera Cluster mit ProxySQL

Einen georedundanten MariaDB Galera Cluster über zwei oder mehr Standorte aufzubauen ist aufgrund der genügsamen Bandbreitenanforderungen des wsrep-Protokolls grundsätzlich kein Problem. In vielen Konstellationen können die Knoten eines Clusters ohne nennenswerte Performance-Einbußen an unterschiedliche Standorte gestellt werden. Ausnahmen sind hier Cluster mit extrem hohen Transaktionsraten. In solchen Fällen kann die Bandbreite der WAN-Verbindung zum limiierenden Faktor werden. Eine solche Verteilung birgt aber immer die Gefahr, dass der Cluster nicht erreichbar ist, wenn die Netzwerkverbindung ausfällt und keines der einzelnen Segmente ein Quorum hat.

Ein häufiges Setup ist die Verteilung der Systeme, für die eine hohe Verfügbarkeit erforderlich ist, auf zwei Standorte, von den einer der primäre Standort (MAIN) ist. An diesem primären Standort sollen die Ressourcen verfügbar sein, auch wenn die Netzwerkverbindung unterbrochen ist. Nur bei einem Totalausfall oder im Rahmen einer geplanten Wartung wird der sekundäre Standort (DR) genutzt, muss aber dann ohne nennenswerte Unterbrechung – bei 99,999% sind das ca. 5 Minuten pro Jahr – einsatzbereit sein. Wie man dies mit einem MariaDB Galera Cluster und dem Datenbank-Proxy ProxySQL 2.0.x erreicht, wird im folgenden gezeigt.

Der MariaDB Galera Cluster

Beginnen wir mit dem MariaDB Galera Cluster. Da auch bei Ausfall des primären Standorts kein Single Point of Failure (SPoF) auftreten soll, arbeitet man in diesem Fall mit einem Cluster aus vier Knoten. Diese sind so konfiguriert, dass die MAIN Site bei Netzausfall in jedem Fall ein Quorum hat. Dies erreicht man über ein gewichtetes Quorum. Dabei erhalten die Knoten in der MAiN Site ein Gewicht von drei, während in die DR Site Knoten das Standardgewicht von eins haben. Bei einem WAN-Ausfall hat so die MAIN Site ein Gewicht von 6/8 und damit ein Quorum. Die DR Site mit 2/8 Gewicht geht in den Status non-primary, akzeptiert also keine weiteren Requests, und versucht die Verbindung wieder aufzubauen. Der einzige kritische Fall ist der Totalausfall des primären Standorts. In diesem Fall ist das verbleibende Cluster-Segment im non-primary Status und benötigt eine Intervention, um in den primary Status zu wechseln. Auf einem der Knoten muss der Befehl

SET GLOBAL wsrep_provider_options="pc.bootstrap=yes;";

abgesetzt werden. Dies kann auch über ein Skript erfolgen, das über ein unabhängiges Device ausgelöst wird, über das zweifelsfrei feststellbar ist, dass die MAIN Site nicht mehr verfügbar ist.

ProxySQL Konfiguration

ProxySQL ist ein Open Source Datenbank Proxy, der seit Version 2.0 auch Galera Cluster Setups nativ unterstützt. Auch die Vorgängerversionen wurden bereits mit Galera Cluster Installationen genutzt, es gibt aber Situationen, in denen Anwendungen Timeouts bekamen, weil ProxySQL bei den Verteilregeln nicht den Cluster Status berücksichtigt hat, sondern nur den MariaDB Server Status. Dies musste über zusätzliches Skripting abgefangen werden.

Beim Setup eines georedundanten Clusters soll ProxySQL bevorzugt immer die lokalen Knoten verwenden und nur bei hoher Last zum Lesen auch die Knoten im Zweitstandort in Betracht ziehen. Dazu wird an jedem Standort mindestens ein ProxySQL installiert. Dabei ist es wichtig, dass die ProxySQL instanzen nicht standortübergreifend in einem ProySQL-Cluster zusammengefasst werden, da die Konfigurationen nicht identisch sondern spiegelbildlich sind.

Die Regeln für das Setup des Demo-Clusters auf dem dieser Artikel basiert sind folgende.

Gewichtung am MAIN Standort
Knoten Writer Gewicht Reader Gewicht
 1 100 100
2 50 100
3   10
4   10
  • Der Demo Cluster besteht aus den Knoten 1 und 2 im MAIN-Segment und 3 und 4 im DR Segment.
  • In jedem Standort gibt es einen Writer Knoten auf dem bevorzugt alle Schreibanforderungen abgearbeitet werden.
  • In jedem Standort gibt es zudem einen Backup Writer, der aktiv wird, wenn der Writer ausfällt oder wegen Wartung nicht aktiv ist.
  • Da Anfragen möglichst nicht standortübergreifend abgearbeitet werden sollen, sind die Writer zugleich auch Reader.
  • Im Fall von sehr hohen Anfrageraten können lesende Anfragen auch auf den zweiten Standort geleitet werden.
  • Die Knoten am Standort der ProxySQL Instanz sind sowohl in der Writer wie auch in der Reader Hostgroup.
  • Die Knoten am anderen Standort sind in der Reader Hostgroup aber nur mit einem geringen Gewicht, im Test-Setup 10% des Gewichts der lokalen Knoten.

Die nebenstehende Tabelle zeigt die Gewichtungen des Demo-Systems

Die Gewichtung am DR Standort ist genau spiegelbildllich dazu.

Da in der Regel am Hauptstandort gearbeitet wird, kann es sinnvoll sein, hier eine zweite ProxySQL-Instanz zu installieren, die mit der ersten in einem Cluster Setup läuft. Damit wird ein SPoF am Hauptstandort vermieden. Sollte der Hauptstandort wirklich komplett und für absehbar längere Zeit ausfallen, kann am Ausweichstandort ohne großen Aufwand eine zweite ProxySQL-Instanz nachgerüstet werden.

Es ist zudem möglich, den Knoten am Zweitstandort ebenfalls die Writer-Rolle zu geben allerdings ebenfalls mit geringem Gewicht. Dies ist aber aus meiner Sicht nur in wenigen Wartungsszenarien sinnvoll. Anstelle einer Umleitung der Anfragen auf den Zweitstandort ist es sinnvoller, zuvor gezielt auf den zweiten Standort zu wechseln, sollte es aus irgendwelchen Gründen erforderlich sein, dass beide Knoten am Hauptstandort in Wartung gehen.

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