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)

Viel Licht, auch Schatten?

Ein weiterer Nachteil besteht darin, dass es bei Hot-Spots (kleine Tabellen mit sehr hoher Änderungsrate) zu einer erhöhten Anzahl von Konflikten kommt. Dies äußert sich darin, dass die Applikation vermehrt Deadlock-Meldungen erhält und damit umgehen muss. Ein letzter Nachteil besteht schließlich darin, dass bei der initialen Vollsynchronisation, wenn ein Knoten neu in den Cluster aufgenommen werden soll, derjenige Knoten, welcher die Daten liefert (der sogenannte Donor-Knoten) für sämtliche Zugriffe blockiert wird. Das ist auch einer der Hauptgründe dafür, den Galera Cluster immer mit mindestens drei Knoten aufzusetzen.

Topologie und Funktion

Das empfohlene Setup für Galera Cluster besteht aus drei Knoten (Servern). Die können sowohl physischer Natur als auch virtuell sein. Sie können sich sogar über Rechenzentren hinweg verteilen, jedoch darf man dann nicht mehr mit sehr kurzen Antwortzeiten rechnen. Um das ganze System hochverfügbar zu machen, wird dem Galera Cluster ein Loadbalancer vorgeschaltet.

Die Patches der Firma Codership greifen in den Transaktions- und Replikations-Mechanismus von MySQL ein. Bei einem »COMMIT« -Befehl wird das Write Set (das heißt die Transaktion plus Metadaten) vom sogenannten Masterknoten (das ist derjenige, der die Transaktion erhält) an alle anderen Knoten (die Slaves) des Clusters übermittelt. Der Cluster generiert daraufhin eine globale Transaktions-ID. Mit der kann jeder Knoten (einschließlich des Masters) den Zertifizierungstest für das Write Set vornehmen, um festzustellen, ob das Write Set anwendbar ist oder nicht. Ist dieser Zertifizierungstest erfolgreich, wird das Write Set appliziert. Andernfalls verwirft der Slave das Write Set, und der Master führt ein Rollback durch.

Wenn der Slave-Knoten das Write Set nicht applizieren kann (zum Beispiel weil die Platte voll ist), wird er vom Cluster-Verbund ausgeschlossen und muss sich selbst beenden, um zu gewährleisten, dass keine Dateninkonsistenz auftritt. Beim Wiedereintritt in den Cluster muss er sich mit den andern Knoten durch einen sogenannten State Snapshot Transfer (SST) synchronisieren, um an einen konsistenten Datenbestand zu gelangen.

Der SST ist eine vollständige Übertragung der Daten eines sogenannten Donor-Knotens auf einen neu in den Cluster eintretenden Empfänger-Knoten. Während dieses SST ist der Donor für SQL-Anfragen nicht verfügbar. Dies ist mit ein Grund, warum sich ein Galera-Setup mit nur zwei Knoten nicht empfiehlt.

Der SST kann mittels »mysqldump« , »rsync« oder »xtrabackup« (ab 2.0) erfolgen. Bei sehr großen Datenbeständen (Faustregel: Datenmenge > RAM) ist »mysqldump« aufgrund seiner langen Laufzeit nicht mehr die geeignete SST-Methode. Die beiden anderen Methoden eignen sich dann besser.

Neu beim Galera Cluster 2.0 ist der sogenannte Incremental State Transfer (IST) hinzugekommen. Er ermöglicht dem Cluster, bei einem Neustart nur die Inkremente zu übertragen und zu applizieren, was natürlich wesentlich schneller vonstatten geht. Das ist insbesondere dann von Interesse, wenn der Galera Cluster in einem WAN betrieben wird und eine volle Übertragung der gesamten Datenmenge aufgrund der geringen Bandbreite ewig dauern würde.

Ä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