Nachbetrachtung zum Webseminar: Galera Cluster und MariaDB Enterprise

Als Nachbetrachtung zum deutschsprachigen Webseminar “Galera Cluster und MariaDB Enterprise” – die Aufzeichnung finden Sie hier – möchte ich in diesem Blog Post die Gelegenheit nutzen nochmals auf die wichtigsten Fragen einzugehen, die im Webseminar von den zahlreichen Teilnehmern gestellt wurden.

Inhalt des Webseminars war:

  • Die Vorstellung von MariaDB Galera Cluster bzw. Galera Cluster als Hochverfügbarkeits-Lösung
  • Typische Cluster-Topologien
  • Wie Nodes zu einem bestehenden Galera Cluster hinzugefügt werden können
  • MariaDB Manager, ein hilfreiches Werkzeug zum Aufbau und Betrieb einer MariaDB Galera Cluster Umgebung

Frage: Wie geht MariaDB Galera Cluster mit temporären Tabellen um?

Antwort: Da temporäre Tabellen in MySQL/MariaDB immer im Bezug auf eine Session angelegt werden und auch nur von dieser genutzt werden können, werden diese nicht auf die anderen Nodes repliziert.

Frage: Wie effizient ist MariaDB Galera Cluster bei größeren Datenmengen ( > 10 Mio Rows )?

Antwort: Einen direkten Zusammenhang von Effizienz zur Datenmenge gibt es nicht, zumindest nicht für den normalen Betrieb. Die synchrone Replikation findet auf Basis von abgeschlossenen Transaktionen statt. Dabei ist es für einen Datenbank-Cluster von Vorteil, wenn kleinere Transaktionspakete verwendet werden. Da Galera Cluster den Replikations-Typ “ROW” voraussetzt, ist auch hier die Datenbank-Größe nicht so relevant wie bei Verwendung einer STATEMENT Based Replikation, wo DML-Befehle mit all ihrem Overhead nochmals ausgeführt werden müssten.

Datenbank-Größe kann zum Thema werden, wenn es zum Ausfall einer Node gekommen ist. Im Optimalfall kann für die Wiederherstellung die Variante IST (Incremental State Transfer) verwendet werden. Hier müssen nur die während des Ausfalls durchgeführten Änderungen nachgezogen werden, die Größe der Datenbank spielt hier wiederum eine untergeordnete Rolle. Muss allerdings auf die Variante SST (State Snapshot Transfer) zurückgegriffen werden, muss die gesamte Datenbasis von einer Node im Cluster (Donor) auf die wiederherzustellende Node (Joiner) übertragen werden. Auch hier wird zwischen drei Varianten unterschieden, welche zu verschiedenen Recovery-Zeiten führen. Eine Beschreibung hierzu finden Sie unter http://www.codership.com/wiki/doku.php?id=sst_mysql Das Gesamtsystem ist während einer Node-Wiederherstellung aber Online.

Frage: Unterstützt MariaDB Galera Cluster Tabellen-Partitionierung?

Antwort: MariaDB Galera Cluster unterstützt keine Cluster-spezifische Partitionierung, die für MariaDB Server vorhandene Partitionierung aber kann auch bei Nutzung von MariaDB Galera Cluster eingesetzt werden. Dies bedeutet, eine Node-interne Partitionierung ist möglich. Jede Node eines Galera Cluster enthält aber die kompletten Daten. Es ist also nicht möglich, einen Teil einer Tabelle auf Node 1 zu haben, einen anderen nur auf Node 2.

Frage: Welche Nachteile bringt die Synchronität von MariaDB Galera Cluster bei “Bulk-Inserts” in Bezug auf Latenz und Performance mit sich?

Antwort: Wie schon erwähnt sind große Transaktionen nicht optimal für Galera Cluster – siehe auch “Transaction Size” https://mariadb.com/kb/en/mariadb-galera-cluster-known-limitations/. Da, wie im Webseminar auf den Folien “Optimistic Concurrency Control” beschrieben, Galera Cluster kein Two-Face-Commit für Transaktionen benötigt, besteht für den Commit zum Client keine direkte Abhängigkeit zum Commit aller Nodes des Clusters. Daher ergibt sich ein Overhead gegenüber “Bulk-Inserts” auf nur einem Server, dieser ist jedoch im Vergleich zu einem Datenbank-Cluster mit Two-Face-Commit sehr gering.

Frage: Wie performant muss das Netzwerk in Bezug auf die Client-Netzwerkverbindung bei z.B. 3 Cluster Nodes mit je 1GBit Anbindung sein?

Antwort: Wichtig ist eine gute Anbindung zwischen den einzelnen Cluster Nodes, um nicht in Time-Out Bereiche zu kommen, die zur Isolierung einer Node aus dem Cluster führen könnte. Die Anforderungen der Client-Netzwerkanbindung sind eher abhängig von den Anforderungen der Anwendung. Da eine Client-Verbindung immer zu einer der Cluster Nodes aufgebaut wird und die anderen Nodes erst ab einem internen Commit einer Transaktion in Aktion treten, besteht kein direkter Einfluss von Client-Netzwerkverbindung und der Verfügbarkeit von Galera Cluster.

Frage: Wir haben mit sehr vielen analytischen Daten zu tun, welche gefiltert und gruppiert werden müssen. Wir verwenden im Moment MySQL. Wie würde sich ein MariaDB Galera Cluster im Hinblick auf die Lesegeschwindigkeit mit großen Datenmengen Performance-Vorteile bringen?

Antwort: Da die Anfragen inklusive der Filterung und Gruppierung auf die einzelnen Nodes von MariaDB Galera Cluster verteilt werden und die einzelnen Nodes mit ihren eigenen Ressourcen (von Caches über Dateien, IO bis hin zu Hardware) arbeiten, sollten Performance-Vorteile zu erkennen sein. Zumindest wenn es aktuell Engpässe in diesen Bereichen gibt.

Frage: Wie handhabt MariaDB Galera Cluster die Wiedereinbindung eines für die Zeit x ausgefallenen Nodes?

Antwort: Beim Neustart der ausgefallenen Node gibt es zwei grundsätzlche Methoden, um die Node zu synchronisieren. Wie schon weiter oben kurz beschrieben – Siehe auch die Folien “State Transfer” und “State Snapshot” Transfer im Webseminar (http://www.skysql.com/node/1835) – wird hier zwischen IST (Incremental State Transfer) und SST (State Snapshot Transfer) unterschieden.

IST ist möglich, wenn auf einer anderen Node (Donor) im Cluster eine dafür vorhandene Datei (Gcache) noch alle Änderungen (writesets) enthält, die seit Ausfall der Node durchgeführt wurden. In diesem Fall würde also die Synchronisierung zur wiederherzustellenden Node (Joiner) über den Gcache erfolgen.

Sollte eine Synchronisierung auf diesem Weg nicht möglich sein – Node musste neu aufgesetzt werden oder Gcache enthält nicht mehr alle Writesets – dann erfolgt der Abgleich mit der Methode SST (Snapshot State Transfer). Hier wird der komplette Datenbestand über MySQLDump, rsync oder xtrabackup abgeglichen. Sobald dies geschehen ist wird die Node wieder aktiv in den Cluster aufgenommen. Für die verschiedenen Vorgehensweisen gelten einige Randbedingungen, die unter http://www.codership.com/wiki/doku.php?id=sst_mysql zu finden sind.

Frage: Macht es für ein Backup Sinn, einen der drei Server temporär runterzufahren?

Antwort: Es kommt auf die gewählte Backup-Methode an, ob eine Node aus dem Cluster genommen werden sollte oder nicht. Die Entscheidung ist also nicht unterschiedlich zu einem einzelnen MariaDB Server. Da alle Nodes den gleichen Datenstand haben, kann jede Node für das Backup verwendet werden. Für einen einfach Restore eines Galera Clusters ist es allerdings wichtig, mit dem Backup auch die Galera interne Global Transaction ID zu sichern. Daher sollte das Backup über Galera Replikations-Methoden gestartet werden (siehe auch http://www.codership.com/wiki/doku.php?id=data_backup).

Frage: Was passiert, bei 3 Nodes, wenn die Nodes mittels eines Switches verbunden sind, wenn dieser Switch ausfällt. Würde sich der Cluster komplett abschalten?

Antwort: Ein wesentlicher Grund für den Einsatz eines Datenbank-Cluster wie MariaDB Galera Cluster ist, mögliche singuläre Fehlerquellen (Single Point of Failure – SPOF) zu vermeiden. Das bedeutet, für das Gesamtsystem soll keine Abhängigkeit zu einem einzelnen Element bestehen. Galera Cluster deckt hier den Teil Datenbank Server ab, für alle anderen Elemente wie Netzwerkkarte, Netzwerkverbindungen, Switches, … sollte hier hier das Gleiche gelten.
Zur Frage selbst – Galera Cluster arbeitet nach einem Quorum-Modell. Das bedeutet z.B. bei einer Standardkonfiguration und drei Nodes, dass eine Node nur einen Cluster bilden kann wenn sie zumindest eine zweite Node erreichen kann. Ist dies nicht der Fall, akzeptiert die Node keine Anfragen mehr. Sollte also ein Switch ausfallen, würde der Cluster nicht mehr zur Verfügung stehen. Man kann in diesem Fall für eine Node die Konfiguration ändern, dass sie die Einzige im Cluster ist, um zumindest den Betrieb wieder zu ermöglichen (natürlich nur sofern die Clients über einen anderen Weg noch Zugriff haben).

Frage: Kann MariaDB Manager (GUI) ebenfalls in einer HA-Konfiguration betrieben werden?

Antwort: Ja, MariaDB Manager kann auf verschiedenen Servern gleichzeitig betrieben werden. MariaDB Manager holt sich alle benötigten Stati direkt von den einzelnen Nodes und bekommt daher auch Änderungen “von außen” mit.

Frage: Gibt es interne Sicherheitsmechanismen um dafür zu sorgen, dass sich ein nicht authorisierter Galera Server die Daten kopiert (wie der für die Replikation anzulegende Benutzer)?

Antwort: Einen allgemeinen Nutzer für die Replikation – wie von der Standard-Replikation bekannt – gibt es für Galera Cluster nicht. Es sollte allerdings für eine Server-Umgebung davon ausgegangen werden können, dass ein Zugriff auf diese Server (IP + Port) von außen nicht möglich ist. Für den SST (Statement Snapshot Transfer) wird eine Authentifizierung konfiguriert. Diese unterscheidet sich je nach gewähltem Werkzeug (XtraBackup, Dump, …). Da für jedes Aufsetzen einer neuen Node ein SST durchgeführt werden muss, kann eine Galera Node ohne diese Authentifizierung keine Daten kopieren.


Im Webinar bin ich zum Thema Loadbalancer ( Lese- und Schreib-Zugriff auf alle Nodes ermöglichen) auf die internen Möglichkeiten des JDBC Connectors eingegangen.

Hierzu noch ein Hinweis eines Teilnehmers. Danke hierfür!
“Client-seitiges Loadbalancing gibt’s nicht nur für JDBC, sondern mittlerweile auch für PHP mittels mysqlnd_ms Library, momentan meist über PECL/PEAR installierbar, bei der kommenden Ubuntu 14.04 auch bereits in der Distribution.”