Anstatt SSL per Compilierung in MySQL zu integrieren
Workshop: »MySQL«-Datenbanken sicher replizieren
Fortsetzung des Artikels von Teil 2
RSA-Keys anstatt von Passwort-Eingabe
An diesem Punkt stellt sich die Frage, ob der IT-Verwalter nicht lieber Preshared-RSA-Keys verwendet, anstatt ein Passwort einzugeben. Kommen Schlüssel zum Einsatz, kann der Admin Watchdog-Shell-Skripts verwenden, um zu überwachen, ob der SSH-Tunnel besteht. Im Fehlerfall wird dann der Tunnel neu gestartet.
Der Administrator sollte sich auch überlegen, ob er einen Cron-Job auf dem Master aufsetzt, der die Tabelle mit dem aktuellen Unix-Zeitstempel versieht. Auf dem Slave kann es dann einen Cron-Job geben, der diese Werte überprüft. Liegt der Wert des Slaves zu weit hinter der Zeitmarke, dann funktioniert die Replizierung vermutlich nicht mehr. Der IT-Verwalter bekommt dann etwa eine E-Mail zur Information.
Schwierigkeiten bei der Replizierung
Es gibt zwei wichtige Sachen, die es bei der Mysql-Replizierung zu bedenken gilt. Zum einen ist es das Problem, dass sich fehlerhafte Befehle direkt auch auf die Replik auswirken, was für ein Desaster-Recovery nicht gut ist. Auf dem Slave wird jeder Befehl wiederholt, der auf dem Master Daten ändert. Gibt der Admin aus Versehen etwa den Befehl »DELETE FROM mytables« ein und vergisst eine »WHERE«-Klausel anzugeben, dann gehen die Daten auf beiden Systemen verloren.
Zum anderen muss sicher sein, dass Daten immer nur auf dem Master geändert werden. Denn es ist natürlich auf möglich, dass dies auf dem Client passiert. Dann sind aber Master- und Slave-Tabellen nicht mehr konsistent. So etwas kann bei der Programmierung leicht passieren. Anwendungen müssen daher vor dem Schreiben prüfen, dass sie nicht auf dem inaktiven Slave sind und so nicht in die replizierten Tabellen schreiben.
- Workshop: »MySQL«-Datenbanken sicher replizieren
- Die Replizierung aufsetzen
- RSA-Keys anstatt von Passwort-Eingabe
Lesen Sie mehr zum Thema
