Das Live-Backup einer MySQL-Datenbank erlaubt kurze Ausfallzeiten bei aktuellem Datenbestand. Läuft MySQL im Master- und im Slave-Modus, sorgt die Datenbank auf dem zweiten Rechner selbst dafür, dass sie auf dem neuesten Stand ist. Mit mehreren Slaves lässt sich zudem eine einfache Lastverteilung realisieren.
Wer die MySQL-Datenbank in einem produktiven Umfeld betreibt, muss für hohe Ausfallsicherheit sorgen. Dazu reicht es nicht, lediglich ein aktuelles Backup auf Band oder CD vorzuhalten. Besser ist eine Konstruktion aus zwei Rechnern, die als Master und Slave zusammenarbeiten. Der Slave erhält stets ein Live-Update der Datenbank und kann beim Ausfall des Masters schnell übernehmen. Zwar ist die Konfiguration dieses Modus relativ einfach, doch ist zu beachten, dass die einzelnen Schritte in einer bestimmten Reihenfolge durchzuführen sind.
Mit einem Slave lässt sich auch die Last in einem Netzwerk praktisch verteilen. Kommt MySQL auf einer Website zum Einsatz, die mit einer Volltextsuche ausgestattet ist, blockieren die Suchvorgänge sehr schnell den Datenbankserver. Übernimmt hingegen der Slave die anstrengende Suche nach Texten, kann der Master-Rechner mit voller Leistung seine eigentlichen Pflichten erfüllen. Im schlimmsten Fall blockieren sich die Suchenden lediglich selbst.
Ein weiterer Vorteil ist außerdem, dass eine Master-Slave-Konfiguration nur wenig Wartung verlangt und somit auch kaum die stets knappen Ressourcen der Administratoren in Anspruch nimmt.
Der Master- und Slave-Modus ist seit der MySQL-Version 3.23.15 implementiert. Wegen diverser Bugs empfehlen die Macher jedoch mindestens die Version 3.23.30 einzusetzen. Der Modus erlaubt eine Topologie aufzubauen, in der sich eine MySQL-Datenbank auf einem primären Server auf weitere MySQL-Server abbilden lässt. Diese Replikation funktioniert automatisch, was den Modus mehrfach interessant macht. Das Live-Backup auf einem zweiten Rechner dient als Failover, das der Administrator jedoch manuell anfahren muss. Auch Cluster profitieren, da sich durch das Setup die Last geschickt zwischen den einzelnen Nodes aufteilen lässt.
Das Replikationsmodell bei MySQL unterstützt die Ein-Weg-Replikation: Ein Server fungiert als Master und beliebig viele andere Rechner agieren als Slave. Ein Slave kann seinerseits auch wieder Master sein. Soll die Datenbank also besonders ausfallsicher sein, dient eine Kette von Servern dazu, das Master-Slave-Modell zu übernehmen und somit zu jeder Zeit die aktuellen Daten online vorzuhalten.
Als einziger Sicherheitsmechanismus reicht ein Slave-Rechner nicht aus. Zwar ist ein Slave das perfekte Backup, wenn der Master aufgrund eines Hardwarefehlers ausfällt. Allerdings können Softwarefehler Desaster auslösen. Da der Slave alle Updates des Masters live mitführt, lösen falsche SQL-Instruktionen entsprechende Katastrophen aus. Ein irrtümlich abgesetztes »delete from members;« auf dem Master führt dazu, dass die Mitgliedertabelle auch auf dem Slave sofort verschwunden ist. Ein konventionelles Backup ist also auch im Master-Slave-Betrieb Pflicht.
Alle Rezensionen aus dem Linux-Magazin
Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...
