Der Galera Cluster für MySQL

© © Andrii-Vergeles, 123RF

Abgesichert

Je länger die MySQL-Datenbank in Betrieb ist, umso weniger ist sie verzichtbar. Folgerichtig stellt sich früher oder später die Frage nach der Verfügbarkeit. Eine mögliche Antwort darauf ist der Galera Cluster für MySQL.
Security ist ein stets aktuelles Thema in der IT. Deshalb widmet sich das ADMIN-Magazin 04/2012 speziell Sicherheitsaspekten und gibt Antworten auf die Fragen: ... (mehr)

Gibt es das nicht schon? Wieso brauchen wir jetzt noch einen Cluster für MySQL, wo doch schon diverse Ansätze existieren, um die Verfügbarkeit von MySQL-Datenbanken zu steigern? Die Antwort ist: Jede der bisherigen Lösungen hatte auch erhebliche Nachteile. Der Galera Cluster aber ist nun angetreten, um es in etlichen Punkten besser zu machen. Wo genau es jeweils Optimierungspotenzial gibt, zeigt ein genauerer Blick auf die bisher angetretenen Bewerber.

Nachteile

MySQL Master/Slave Replikation: Hier entsteht ein Problem dadurch, dass durch das asynchrone Replizieren die Daten auf den Slaves immer verzögert ankommen. Fehlerhaftes Handling (zum Beispiel inkonsistente Snapshots auf dem Master oder falsches Setzen der Binary-Log-Position nach dem Einspielen) kann außerdem schnell zu Dateninkonsistenzen zwischen Master und Slave führen. Bei der alten, sogenannten Statement Based Replikation (SBR), die immer noch sehr häufig eingesetzt wird, besteht zudem die Gefahr, Inkonsistenzen durch unsichere, nicht-deterministische Abfragen zu erhalten. Das passiert etwa, wenn Sie die Abfragen »DELETE« und »UPDATE« mit »LIMIT« verwenden oder wenn Sie die Funktionen »LOAD_FILE()« , »UUID()« , »USER()« , »SYSDATE()« und andere einsetzen.

Ein Absturz von Master oder Slave kann Lücken im Datenstrom bewirken oder aber die Binary Logs korrumpieren. Auch das Stoppen des Slaves bei noch nicht abgearbeiteten temporären Tabellen kann unbemerkt zu Inkonsistenzen führen. Schließlich besteht eine weitere Ursache von Inkonsistenzen darin, dass Daten direkt auf dem Slave absichtlich oder unabsichtlich manipuliert werden. Noch gefährlicher wird die Sache aber, wenn bei Master-/Master-Replikation auf beide Knoten geschrieben werden soll. In diesem Fall sind Dateninkonsistenzen praktisch sicher. Wer das nicht glaubt, braucht danach nur einmal die Daten auf Master und Slave zu vergleichen.

Aktiv/Passiv-Failover-Cluster: Diese für Datenbanken oft genutzte Lösung hat den Nachteil, dass das Handling des ganzen Cluster recht komplex ist und besonders das Wiederinstandsetzen eines kaputten Clusters leicht zu Schwierigkeiten führen kann.

Der Administrator muss sich mit dem Clustermanager (Pacemaker und Corosync oder Heartbeat) auskennen und sollte auch genau wissen, wie er mit einem Shared-Disk-System umgeht. Bei der Verwendung von DRBD kommt eine synchrone Replikation zwischen den Disk-Systemen der beiden Clusterknoten zustande. Auch diese Technik sollte der Admin genau verstehen. Stattdessen bekommen zwar viele Administratoren die Installation einigermaßen ordentlich hin, im Notfall fehlen ihnen aber Übung und Kenntnis, um richtig zu reagieren. Ist DRBD im Spiel, kann zudem das I/O-System zum Flaschenhals werden. Ein Skalieren ist hier nur durch MySQL Master/Slave-Replikation möglich.

MySQL Cluster (NDB-Cluster): Der größte Nachteil bei dieser Lösung besteht darin, dass diese Datenbank üblicherweise nicht einfach einer Applikation untergeschoben werden kann. Der MySQL-Cluster stammt aus dem Telco-Umfeld, wo hauptsächlich Primary Key-Abfragen ausgeführt werden (Key/Value Store). Hierfür eignet er sich sehr gut und skaliert auch wunderbar. Bei den üblichen Web-Anwendungen (Web-Shops, CMS, CRM und so weiter) sind aber erheblich komplexere Abfragen meist mit Joins die Regel. Und bei denen ist der MySQL-Cluster – bedingt durch seine Architektur als Netzwerk-Datenbank (NDB) – nicht mehr sehr performant, weil jeder Join Netzverbindungen nutzen muss.

Um das auszugleichen, sind Anpassungen aufseiten der Applikation nötig, die Joins in einzelne Abfragen umschreiben. Möglicherweise braucht deshalb die ganze Applikation ein neues Design, weil nur so das volle Potenzial des NDB-Clusters auszuschöpfen ist. Zudem muss man lernen, mit diesem verteilten Cluster umzugehen, der aus drei verschiedenen Komponenten besteht (Daten-Knoten, Management-Knoten und SQL-Knoten). Für den Administrator bedeuten sie zusätzliche Komplexität.

Was Galera kann

Optimal wäre eine Lösung, die all die oben gelisteten Probleme nicht aufweist. Genau mit diesem Ziel tritt der Galera Cluster für MySQL an. Er bietet eine unkomplizierte Lösung für Hochverfügbarkeitsanforderungen und gleichzeitig das Skalieren von Lese-Anfragen.

Wie erreicht er das? Der Galera Cluster ist ein synchroner Replikationscluster, der auf der InnoDB-Storage-Engine aufbaut. Das bedeutet, dass alle Tabellen als InnoDB-Tabellen vorliegen müssen. Geht das aus bestimmten Gründen nicht, lässt sich Galera nur bedingt verwenden. Meist erfolgt das Konvertieren von Tabellen nach InnoDB aber ohne Probleme. Das synchrone Replizieren hat zudem zur Folge, dass die Slaves nicht hinterherhinken und keine Transaktionen verloren gehen können.

Galera verwendet eine echte Aktiv/Aktiv-Multi-Master-Topologie. Das bedeutet, dass der Cluster gleichzeitig von allen Knoten lesen und auf alle Knoten schreiben kann. Sobald ein Knoten aus dem Cluster fällt, merken dies die anderen Knoten automatisch. Kommt ein neuer Knoten zum Cluster hinzu, wird er automatisch in den Cluster aufgenommen und synchronisiert sich.

Im Gegensatz zur Master-/Slave-Replikation und darauf aufbauenden Lösungen kann der Galera Cluster parallel auf Zeilenebene replizieren. Damit erzielt er ein Zigfaches an Durchsatz, verglichen mit der MySQL-Master-/Slave-Replikation. Der Schreibdurchsatz skaliert in einem gewissen Rahmen, die Lese-Zugriffe beliebig mit der Anzahl der Cluster-Knoten. Dabei kann es im Unterschied zur MySQL-Replikation aber nicht vorkommen, dass Knoten hinterherhinken, weswegen die Aktualität der Daten auch nicht überprüft zu werden braucht.

Bei so vielen Vorteilen fragt man sich natürlich: Wo ist der Pferdefuß? Und tatsächlich bringt der Galera Cluster auch einige Nachteile mit sich: Da MySQL die benötigten Funktionen selbst nicht bereitstellt, muss der MySQL-Code entsprechend gepachet werden. Die eigentliche Replikation realisiert dabei ein Plug-in. Glücklicherweise kann der Anwender auf fertige Binaries zurückgreifen, die die Firma Codership zur Verfügung stellt. Als Alternative lassen sich auch die entsprechenden Binaries von Percona oder MariaDB verwenden.

Ähnliche Artikel

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023