Gerade bei größeren Projekten ist die Frage nach einer Datenbank-Hochverfügbarkeit eine elementare Frage. Wenn bei einem Webshop der Datenbankserver wegbricht, entgeht dem Händler Umsatz. Vom Imageschaden ganz zu schweigen. Aus diesem Grund wird kaum ein größeres Webprojekt ohne einen Hot- oder Cold-Stand-By Datenbankserver auskommen.
Warum langt eine Datenbanksicherung nicht?
Im Artikel „MySQL Datenbank oder einzelne Tabelle kopieren“ habe ich eine Datenbanksicherung mit MySQL-Boardmitteln beschrieben. Prinzipiell ist dies schon mal ein guter Ansatz. Die Datenbank als Sicherung räumlich getrennt auf einem externen Datenträger aufzubewahren, kann im Bedarfsfall viel Arbeit ersparen. Löst aber unser Problem nicht. Wenn ein Datenbankserver ausfällt, muss sofort ein anderer Server die Arbeit übernehmen, so dass man keine Offline-Zeit hat und ich Ruhe sich um den ausgefallenen Server kümmern kann.
Was ist ein Cluster-System?
Cluster oder Clustering bezieht sich auf den Gedanken, die Verfügbarkeit von Systemen und Anwendungen über standardisierte und preiswerte Hardware zu erhöhen. Heißt also nichts anderes, als dass mehrere Standard-Rechner einen Verbund bilden, aber nach außen als ein Rechner oder Datenbank sich zu erkennen geben. Steigt die Last, teilt sich diese auf die einzelnen Maschinen (Cluster-Member oder Knoten genannt) auf. Fällt ein Cluster-Member aus, steigt die Last der verbleibenden Member, aber das System (Datenbank) bleibt nach außen verfügbar.
Was ist Hot-Stand-By, was ist Cold-Stand-By und was ist der Unterschied?
Ein Cluster ist der Königsweg, keine Frage. Je nach Projekt und Verfügbarkeit kann man sich auch mit einer Hot- oder Cold-Stand-By-Lösung behelfen. Beide Lösungen setzen auf einen zweiten Server auf. Während bei einer Hot-Stand-By-Lösung der zweite Server ständig in Betrieb ist und die Daten mit dem Master-Server ständig repliziert (also die Daten in Realzeit aktuell hält), ist der zweite Server bei einer Cold-Stand-By-Lösung aus. Erst im Bedarfsfall wird der zweite Server eingeschaltet und auf den aktuellen Stand gebracht (einige Lösungen gleichen sich zu definierten Zeitpunkten automatisiert ab). Beiden Lösungen gemein ist, dass die eigentliche Arbeit der Master-Server macht, der Slave-Server nur bei Ausfall des Masters ins Spiel kommt.
MySQL-Replikation, Überlegungen zur Hochverfügbarkeit
In diesem Artikel möchten wir folgenden Fall beschreiben: Wir haben eine Master-MySQL-Datenbank sowie mehrere Slave-Datenbanken. Die Aufbereitung der Daten auf dem Master-Server ist so aufwändig und CPU-hungrig, dass zu mehreren Zeitpunkten untertags ein Webzugriff auf die Datenbank nicht oder nur schwer möglich ist. Aus diesem Grund soll die fertige Datenbank auf einen Slave-Datenbank-Server gespiegelt werden; der Zugriff der Webfrontend-Server soll nur auf die gespiegelten Slave-Server erfolgen. Somit kann bei der Datenbankaufbereitung der Master-Server seine volle Leistung nutzen und kein Webzugriff stört ihn. Nachteil dieser Lösung: Die Daten der Slave-Server hinken in der Aktualität dem Master-Server hinterher, was aber in unserer Lösung akzeptiert werden kann.
Ferner muss sichergestellt werden, dass die Berechnungen durch die Replikation nicht noch von den Slave-Servern durchgeführt wird. Diese sollen nur das fertige Ergebnis replizieren. Dies kann durch die Einschränkungen der Replikation aus Datenbanken und Tabellen sichergestellt werden.
Wir replizieren also die Datenbank auf mehrere Slave-Server. Jeder Slave-Server ist zugleich ein Webfrontend-Server. Per Network-Load-Balancing (NLB) werden die Web-Besucher auf die einzelnen Webfrontend-Server, also auf unsere MySQL-Slave-Server, verwiesen.
Im nächsten Teil („MySQL Replikation (Master/Slave) einrichten“ #######) beschäftigen wir uns nach soviel Vorüberlegung mit der eigentlichen Einrichtung der MySQL-Replikation.