MySQL verteilen und sichern: Master und Slave

Replika als Backup

Ein "live" mitgeführter Slave-Rechner stellt parallel ein wertvolles Backup des Masters dar. Fällt dieser aus - etwa auf Grund eines Hardware-Defekts, liegt immer ein vollständig auf dem aktuellen Stand der Daten befindlicher Server vor, der mit wenigen Handgriffen die Aufgaben des Masters übernehmen kann: Ein MySQL-Slave ist somit stets auch ein vollwertiger MySQL-Server. Statt den Slave zum Master umzubauen, können Sie einfach einen neuen Server aufsetzen und diesen mit den Daten aus dem Slave bestücken. Letztlich kommt es ja nur darauf an, einen möglichst aktuellen Datenbestand vorzuhalten.

Das Live-Update des Slave ist jedoch nicht ohne Tücken: Da der Slave alle Änderungen am Server praktisch in Echtzeit mitführt, machen sich auch Fehler bei der Wartung des Masters direkt bemerkbar. Wird die Datenbasis auf dem Server durch ein fehlerhaftes SQL-Query irrtümlich gelöscht (etwa durch ein "delete from TableName"), dann sind die Daten anschließend auch auf dem Slave verschwunden. Es empfiehlt sich also nicht, ein Master/Slave-Setup als einzigen Backup-Mechanismus zu verwenden. Tut man dies doch, so ist einem Desaster Tür und Tor geöffnet.

Auch mehrere Slaves lösen dieses Problem nicht: Letztlich spielt es keine Rolle, auf wie vielen Systemen die Daten gleichzeitig gelöscht werden: Sind die Daten weg, dann sind sie weg. Sicherlich könnte man mehrere Slaves verwenden, die sich zeitversetzt mit dem Master verbinden und wieder getrennt werden: Ein echtes Backup sollten Sie trotzdem auf jeden Fall zur Verfügung haben.