Galera Cluster: Der MariaDB-Cluster im Überblick

Ein kon­ti­nu­ier­li­cher Betrieb und eine hohe Ver­füg­bar­keit sind bei modernen Lösungen für das Datenbank-Ma­nage­ment ebenso un­ver­zicht­bar wie möglichst flexible Ska­lie­rungs­mög­lich­kei­ten. Nur so sind Sie den heutigen An­for­de­run­gen mit stark schwan­ken­den Zugriffen und un­er­war­tet hohen Last­spit­zen gewachsen. Der schwie­ri­ge Spagat besteht dabei ins­be­son­de­re darin, diesen An­for­de­run­gen trotz mi­ni­ma­li­sier­ter In­fra­struk­tur­kos­ten auf Cloud-Basis gerecht zu werden.

Galera Cluster un­ter­stützt Sie bei diesem Vorhaben: Die Multi-Master-Clus­te­ring-Lösung für Da­ten­ban­ken setzt auf eine hoch per­for­man­te, synchrone Re­pli­ka­ti­on, um alle Knoten eines Datenbank-Verbunds in Echtzeit mit den gleichen Daten zu versorgen. Unter anderem für MariaDB verfügbar, sorgt Galera Cluster so für minimalen Da­ten­ver­lust und eine hohe Aus­fall­si­cher­heit. Erfahren Sie in den nach­fol­gen­den Ab­schnit­ten, wie genau der Aufbau von MariaDB-Clustern auf Basis von Galera Cluster funk­tio­niert, welche Vorzüge die Tech­no­lo­gie hat und wo sie genau zum Einsatz kommt.

Galera Cluster ist ein Software-Paket für Linux-Be­triebs­sys­te­me, das den Aufbau und das Ma­nage­ment von MySQL-, XtraDB- und MariaDB-Clustern er­mög­licht. Die Basis der Cluster-Anwendung bildet die Storage-Engine von InnoDB bzw. von deren Ab­spal­tung XtraDB. Ex­pe­ri­men­tell wird außerdem die Engine MyISAM un­ter­stützt, die in MySQL und MariaDB als InnoDB-Vorgänger ebenfalls lange Zeit zum Einsatz kam. Bei der Spei­che­rung der Daten in den ver­schie­de­nen, ei­gen­stän­di­gen Cluster-Knoten wendet Galera Cluster das Prinzip der syn­chro­nen Re­pli­ka­ti­on an: Sämtliche Ko­pier­pro­zes­se und Ver­än­de­run­gen an ge­spei­cher­ten Daten werden gleich­zei­tig auf allen primären und se­kun­dä­ren Spei­cher­ein­hei­ten durch­ge­führt, sodass die Da­ten­be­stän­de jederzeit an allen Knoten aktuell sind und nicht von­ein­an­der abweichen.

Ein minimaler Galera Cluster besteht aus drei Knoten (die Ent­wick­ler empfehlen generell eine ungerade Anzahl). Fällt ein Knoten bei der Trans­ak­ti­on von Daten aus, bei­spiels­wei­se aufgrund von Netz­werk­pro­ble­men oder einem defekten System, bilden die beiden anderen Knoten weiterhin die er­for­der­li­che Mehrheit, um die Trans­ak­ti­on dennoch er­folg­reich durch­füh­ren zu können.

Ein MariaDB-Cluster auf Basis von Galera Cluster zeichnet sich dadurch aus, dass alle Knoten des Verbunds zu jeder Zeit über den gleichen Da­ten­be­stand verfügen. Die klas­si­sche Un­ter­schei­dung der ein­ge­spann­ten Datenbank-Server in Master (Server, auf den ge­schrie­ben werden kann) und Slaves (Server, von denen aus­schließ­lich gelesen werden kann) wird dabei durch die Cluster-Software auf­ge­ho­ben: Als Nutzer können Sie Daten auf jeden be­lie­bi­gen Spei­cher­kno­ten schreiben, woraufhin diese au­to­ma­tisch an alle weiteren Cluster-Teil­neh­mer wei­ter­ge­lei­tet werden. Diese Ei­gen­schaft wird auch als Multi-Master be­zeich­net.

Um diesen flexiblen Da­ten­aus­tausch zu ge­währ­leis­ten, nutzt Galera Cluster bei der Ver­wal­tung ein syn­chro­nes Re­pli­ka­ti­ons­ver­fah­ren, das auf dem Austausch von Zer­ti­fi­ka­ten basiert. Werden Daten re­pli­ziert, also in eine der Da­ten­ban­ken des Clusters ge­schrie­ben, gelten im MariaDB-Galera-Cluster folgende zwei Grund­prin­zi­pi­en:

1. Jeder Datenbank-Trans­ak­ti­on wird eine ein­zig­ar­ti­ge Se­quenz­num­mer zu­ge­wie­sen. Bevor ein Cluster-Knoten die je­wei­li­gen Än­de­run­gen an der Datenbank zulässt, gleicht er diese Se­quenz­num­mer mit der Nummer der letzten be­stä­tig­ten Trans­ak­ti­on ab. Alle Knoten kommen bei dieser Über­prü­fung immer zu dem gleichen Ergebnis („Trans­ak­ti­on bestätigt“ oder „Trans­ak­ti­on abgelehnt“). Der Knoten, der die Trans­ak­ti­on gestartet hat, teilt dieses dem Client mit.
2. Bei jeder Trans­ak­ti­on werden alle Datenbank-Replikate ak­tua­li­siert. Wird eine Trans­ak­ti­on also im Anschluss an die Zer­ti­fi­zie­rung bestätigt, nehmen alle Knoten die ent­spre­chen­de Ver­än­de­rung am Datensatz vor. Lediglich im Falle eines tech­ni­schen Problems auf Seiten eines Galera-Cluster-Knotens kann dieser vor­über­ge­hend von der syn­chro­nen Re­pli­ka­ti­on aus­ge­schlos­sen werden.

Die ent­schei­den­den Vorzüge eines MariaDB-Galera-Clusters sind im Laufe dieses Artikels bereits erwähnt worden: Der Umstieg auf diese Cluster-Tech­no­lo­gie bietet Ihnen eine flexible Da­ten­spei­che­rung mit einem Höchstmaß an Aus­fall­si­cher­heit und Ver­füg­bar­keit, das mit einem ge­wöhn­li­chen MariaDB-Setup nicht zu erreichen ist.

Dank der syn­chro­nen Re­pli­ka­ti­on müssen Sie sich keine Gedanken mehr darüber machen, ob alle in­vol­vier­ten Spei­cher­ein­hei­ten auf dem neuesten Stand sind. Jede Datenbank-Einheit wird durch Galera Cluster au­to­ma­tisch mit den neuesten Ver­än­de­run­gen versorgt, was ein manuelles Kopieren bzw. mühsam ein­zu­rich­ten­de Back-up-Stra­te­gien gänzlich erübrigt. Der Multi-Master-Ansatz macht es darüber hinaus möglich, jeden be­lie­bi­gen, ein­ge­bun­de­nen MariaDB-Datenbank-Server an­zu­steu­ern, wenn Sie Daten schreiben, ändern oder löschen möchten wollen. Da sich die Knoten gezielt in der Nähe der Clients plat­zie­ren lassen, kann die dabei an­fal­len­de Latenz minimiert werden.

Ein zu­sätz­li­cher Vorteil eines MariaDB-Clusters auf Galera-Cluster-Basis ist der gute Cloud-Support einer solchen Ar­chi­tek­tur: Für eine flexible, cloud­ba­sier­te Ska­lie­rung der Datenbank-Res­sour­cen sind Sie bestens gerüstet. Auch die Ver­tei­lung von Daten auf ver­schie­de­ne Re­chen­zen­tren stellt kein Problem dar, da jede Trans­ak­ti­on im Galera Cluster nur ein einziges Mal an jedes Re­chen­zen­trum geschickt werden muss.

Ein MariaDB-Galera-Cluster ist aufgrund der genannten Ei­gen­schaf­ten und Vorzüge eine her­vor­ra­gen­de Lösung für das Ma­nage­ment der eigenen Datenbank-Lösung. Konkret deckt das Cluster-Setup u. a. folgende Use Cases ab:

Die Ver­tei­lung von Schreib­vor­gän­gen über den gesamten Cluster er­mög­licht eine optimale Nutzung der zur Verfügung stehenden Schreib­res­sour­cen. Nach der initialen Ver­ar­bei­tung einer Client-Trans­ak­ti­on müssen alle Knoten, an die diese Trans­ak­ti­on wei­ter­ge­lei­tet wird, nur die darin erfolgten Ver­än­de­run­gen aufnehmen. Die Re­pli­ka­ti­ons­me­tho­de des Galera Clusters sorgt im All­ge­mei­nen also für einen deutlich höheren Schreib­durch­satz, als ihn ein ge­wöhn­li­ches Datenbank-Set-up liefern kann – was die Cluster-Tech­no­lo­gie besonders in­ter­es­sant für schreib­in­ten­si­ve An­wen­dun­gen macht.

Auch in einem WAN (Wide Area Network) wie dem Internet funk­tio­niert das synchrone Re­pli­ka­ti­ons­prin­zip von Galera Cluster ohne Probleme. Es gibt zwar einen geringen Delay (Ver­zö­ge­rung in der Über­tra­gung), der pro­por­tio­nal zur Pa­ket­um­lauf­zeit (RTT) des Netzwerks ist – al­ler­dings betrifft dieser nur den Be­stä­ti­gungs­pro­zess der ein­ge­hen­den Datenbank-Trans­ak­tio­nen. Ein MariaDB-Cluster in der Cloud zählt folglich zu den in­ter­es­san­tes­ten Use Cases.

Eng mit der ge­ne­rel­len Spei­che­rung und Ver­wal­tung von Da­ten­be­stän­den in der Cloud verwandt ist das Prinzip der Disaster Recovery, bei der Daten in einem separaten Re­chen­zen­trum liegen, um im Notfall ein kom­plet­tes Da­ten­ab­bild für die Wie­der­her­stel­lung parat zu haben. In diesem Fall leitet Galera Cluster zwar die Re­pli­ka­ti­ons­da­ten weiter, stellt sie jedoch nicht für die Ver­ar­bei­tung von Client-Trans­ak­tio­nen zur Verfügung. Ist eine Wie­der­her­stel­lung nötig, wird der Disaster-Recovery-Teil des MariaDB-Clusters vor­über­ge­hend zur Primär-Instanz de­kla­riert, um die Aus­fall­zeit so gering wie möglich zu halten.