Die im Artikel beschriebene Vorgehensweise, um eine MySQL-Datenbank hochverfügbar zu machen, geht vom Standard-Beispiel aus: Ein simpler Fail-Over-Cluster, in dem MySQL die Hauptanwendung ist. In der Praxis funktioniert dieses Prinzip zwar sehr verlässlich, bringt allerdings auch ein großes Problem mit sich. Der Grund hierfür liegt tief in den Strukturen der InnoDB-Engine, die MySQL standardmäßig verwendet und welche die mit Abstand meistgenutzte Engine überhaupt ist. Im Anschluss an einen Crash prüft MySQL die vorhandenen Datenbanken auf ihre Konsistenz und nimmt falls nötig entsprechende Korrekturen vor. Je größer die vorhandene Datenmenge ist, desto länger dauert dieser Vorgang. Dem Cluster-Manager vermeldet der Resource-Agent für MySQL zwar kurz nach dem Aufruf mit »start« den erfolgreichen Start, bis die Datenbank aber tatsächlich wieder auf Anfragen antwortet, dauert es bisweiligen einige Minuten. Obwohl der Clusterstack selbst also in kurzer Zeit einen brauchbaren Zustand wiederherstellt, dauert es sehr viel länger, bis die durch einen Fail-Over verursachte Downtime endet.

Es lohnt sich durchaus, die Frage zu stellen, ob es im Falle eines Falles tatsächlich eine Datenbank braucht, bei der unter allen Umständen sicher ist, dass niemals auch nur ein einzelner Eintrag verloren geht. Es stehen sich zwei grundlegende Betriebsmuster gegenüber: Eine Fail-Over-Lösung wie oben beschrieben, die tatsächlich "transaction safe" ist, also vor Datenverlust im Falle eines Ausfalls schützt ( Abbildung 3 ). Ist es andererseits denkbar, dass im Rahmen eines Ausfalls eines Servers einzelne Records verloren gehen, ist die Situation entspannter. Beispiele aus der Praxis sind Webstores oder Foren: Hier können Admins es meistens eher verschmerzen, dass Einträge verloren gehen, die kurz vor dem Crash erstellt worden sind, als dass eine Datenbank wegen InnoDB-Recoverys 20 oder mehr Minuten gar nicht zur Verfügung steht.

Abbildung 3: Dieses Setup ist ein klassisches MySQL-Setup, das zwar nie einen Eintrag verliert, möglicherweise aber beim Fail-Over sehr lange braucht.

Beide Szenarien lassen sich mit Pacemaker abbilden. Die sichere Lösung war im Rahmen dieses Artikels bereits Thema – das berühmte Schema F mit einem von Pacemaker verwalteten MySQL auf DRBD. Aber auch die Variante 2 lässt sich mit Pacemaker realisieren. Auch für diese Variante braucht es mindestens zwei Server. Der Unterschied zur Standard-Variante: Durch die Möglichkeit, dass einzelne Datensätze verloren gehen, erkauft sich der Admin die Möglichkeit des nahezu sofortigen Fail-Overs ohne lange Wartezeit. Denn in diesem Szenario gibt es einen MySQL-Master und einen MySQL-Slave, die ihren Inhalt auf MySQL-Ebene permanent synchron halten. Fällt der aktuelle Master aus, "befördert" pacemaker den verbliebenen Knoten vom Slave zum Master ( Abbildung 4 und 5 ). So steht sofort ein neuer Masterserver zur Verfügung. Anstelle von DRBD kommt in diesem Szenario also vor allem die in MySQL vorhandene Replikationsfunktion zum Einsatz.

Abbildung 5: … und verliert dabei möglicherweise einzelne Einträge, bietet dafür aber nahezu sofortigen Fail-Over.

Abbildung 4: In diesem Szenario kommen hingegen dynamische MySQL Master und Slaves zum Einsatz. Stirbt ein Master-Server, übernimmt ein anderer die Rolle …

Dieses Szenario ist nicht auf zwei Server beschränkt, sondern kann letztlich aus beliebig vielen MySQL-Slave-Servern bestehen. Pacemaker hilft bei der Administration: Mittels »clone« -Ressourcen weiß es zu jedem Zeitpunkt, auf welchen Mitgliedern eines Clusters ein MySQL läuft und welche Rolle – Master oder Slave – dieses MySQL gerade hat. Fällt der aktuelle Master-Server aus, befördert Pacemaker automatisch einen anderen Slave zum Master. indem eine Service-IP jeweils mittels »Colocation-Constraint« auf den Rechner fixiert wird, auf dem auch die aktuelle Master-Instanz von MySQL läuft. So gibt es immer ein funktionierendes MySQL, das auf der definierten IP-Adresse lauscht.

Die genaue Beschreibung eines Master-Slave-Setups mit Pacemaker und MySQL hätte den Rahmen dieses Artikels gesprengt. Wer Interesse an einem solchen Setup hat, richtet zunächst zwei MySQL-Datenbanken mit Replikation ein – eine Anleitung dazu findet sich in der Doku von MySQL unter [1] . Anschließend fehlt noch die passende Konfiguration für Pacemaker, die auf der Wiki-Seite des »mysql« -OCF-RAs unter [2] zu finden ist.