Heute stelle ich euch eine technisch besonders interessante Möglichkeit vor, wie ihr euren GREYHOUND nahezu ausfallsicher betreiben könnt und das ganze System stark in Richtung Hochverfügbarkeit trimmt. Hochverfügbarkeit bedeutet in diesem Zusammenhang, das Ausfälle des aktiven MySQL Datenbanksystems innerhalb von einer Minute kompensiert werden können und der Betriebszustand nicht erst aus einem hoffentlich vorhandenen Backup wiederhergestellt werden muss.
Für dieses Ziel richten wir neben dem sogenannten Live-System (das Serversystem auf dem euer MySQL-Server aktuell läuft) ein HotSpare-System ein, welches eine identische Kopie des Live-Systems darstellt und im Fehlerfall die Aufgabe von diesem übernehmen soll. Im Datenbankumfeld spricht man dann auch von einer Master-Master Replikation im sogenannten Aktiv-Passiv Modus. Hierbei stellen beide Datenbankserver eigentlich einen Master (also ein Live-System) dar, wobei einer passiv geschaltet ist und von keiner Anwendung genutzt wird und auch nicht genutzt werden darf, da es sonst zu Dateninkonsistenzen kommt.
Der hier verwendete Trick besteht darin, dass beide Systeme sich gegenseitig replizieren und somit immer beide Datenbanken auf exakt demselben Stand sind. Fällt nun ein Datenbankserver aus, können wir einfach aus dem passiven HotSpare-System das aktuelle Live-System machen, indem wir im GREYHOUND Admin einfach die Datenbankverbindung auf den anderen Server umbiegen. Wir sind innerhalb Sekunden wieder "Live" und können in Ruhe das ehemalige Master System reparieren, was dann später wieder zum HotSpare oder Slave wird.
1. Voraussetzungen
- Das GREYHOUND System wird inhouse betrieben und befindet sich im lokalen Netzwerk
- Das GREYHOUND System wird mit einer externen MySQL Datenbank betrieben, die sich auf einem separaten Server befindet (siehe hierzu auch: Anleitung: Umzug von embedded MySQL auf eine externe Datenbank)
- Ein zweiter Datenbank-Server mit ähnlichen Leistungsdaten und mindestens gleichem freien Speicherplatz wie das Live-System ist vorhanden
- Auf beiden Datenbank-Servern ist exakt die gleiche MySQL Version installiert und die MySQL-Konfiguration ist bereits an GREYHOUND angepasst.
- Beide Datenbank-Server stehen nur im internen Netz und sollten von außen aus Sicherheitsgründen nicht erreichbar sein, da wir hier das Rechte-und Sicherheitsmodell von MySQL nicht weiter vertiefen und von einem einfachen Szenario ausgehen wollen
- Beide Datenbank-Server können per TCP/IP auf Port 3306 miteinander kommunizieren und können ebenfalls beide vom GREYHOUND Server aus auf Port 3306 erreicht werden.
2. Vorbereitende Maßnahmen
Als erstes Stoppen wir mit Hilfe des GREYHOUND Admins den laufenden GREYHOUND Server Prozess und beenden alle zugehörigen GREYHOUND Programme/Tools/Instanzen. Anschließend beenden wir auf beiden Datenbank-Servern den MySQL Dienst.
Wir versichern uns, dass wir ein frisches Backup sowohl vom GREYHOUND Server System als auch von der aktuellen Live-Datenbank haben. Sofern das nicht der Fall ist, erstellen wir zunächst ein Backup.
3. Einrichtung der Replikation
Nun konfigurieren wir zunächst unseren aktuellen (Live) Master Datenbank-Server für die Replikation. Dafür öffnen wir mit einem Texteditor die my.ini, die sich unterhalb des Installationsverzeichnises von MySQL befindet. Hier fügen wir folgenden Abschnitt ein:
- #Konfiguration der Replikation
- server_id=1
- log_bin="C:/MySQL Server 5.1/Data/mysql-bin"
- relay_log="C:/MySQL Server 5.1/Data/mysql-relay-bin"
- log_slave_updates=1
- #read_only=1
- #sync_binlog=1
Die Verzeichnisse müssen evtl. an die aktuellen Gegebenheiten angepasst werden. Im nächsten Schritt machen wir selbiges für den zweiten (Slave, HotSpare) Datenbank-Server und achten dabei aber auf die unterschiedliche server_id:
- #Konfiguration der Replikation
- server_id=2
- log_bin="C:/MySQL Server 5.1/Data/mysql-bin"
- relay_log="C:/MySQL Server 5.1/Data/mysql-relay-bin"
- log_slave_updates=1
- #read_only=1
- #sync_binlog=1
Um die Sicherheit des Ganzen zu erhöhen, kann bei dem Slave oder HotSpare System noch die Option read_only=1 auskommentiert werden. Dadurch wird sichergestellt, das keine Anwendung außer dem MySQL Replikationsthread schreibend auf die Datenbanken zugreifen kann, wir erinnern uns: Es darf einzig und allein auf das aktuelle Live System geschrieben werden, sonst gibt es Inkonsistenzen.
Bevor wir die MySQL Systeme wieder starten, müssen wir noch dafür Sorge tragen, dass beide Systeme den gleichen konsistenten Datenbestand aufweisen. Dieses machen wir mit einer Hilfe einer sogenannten kalten Kopie, da dieses Verfahren hier die einfachste und effizienteste Variante darstellt. Kalte Kopie bedeutet: Beide System sind offline und die Datenverzeichnisse von MySQL werden einfach vom aktuellen Master auf das Slave System kopiert, um für beide Maschinen die gleichen Ausgangsbasis zu bekommen.
Je nach persönlichem Sicherheitsbedürfnis können wir die Replikation mit dem bereits voreingestellten root User von MySQL durchführen oder aber einen separaten Benutzer mit minimalen Rechten hierfür einrichten. Dieser User muss dann aber auf beiden Datenbank-Servern eingerichtet werden. Also starten wir auf beiden Systemen zunächst wieder MySQL über die Windows Dienstesteuerung und richten optional den Replikationsuser über die MySQL Shell oder ein MySQL GUI Tool ein:
- GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO repl@'192.168.0.%' IDENTIFIED BY 'p4ssword';
Auch hier bitte wieder die IP-Adresse bzw. den Username "repl" und das Password "p4ssword" den eigenen Bedürfnissen anpassen.
4. Replikation aktivieren
Der nächste Schritt besteht darin, dass wir dem Slave mitteilen, wie er sich mit dem anderen Master-Server verbinden und seine Binärlogs abspielen soll. Dieses machen wir über die MySQL Anweisung "CHANGE MASTER TO". Diese Anweisung setzt die entsprechenden Einstellungen in einer Datei namens master.info. Folgende Kommandos führen wir wieder auf beiden Datenbank-Servern in der MySQL Shell aus:
- CHANGE MASTER TO MASTER_HOST="192.168.0.100", MASTER_USER="repl", MASTER_PASSWORD="p4ssword", MASTER_LOG_FILE="mysql-bin.000001", MASTER_LOG_POS=0;
Wobei wir darauf achten, die korrekten Daten für die Benutzerauthentifizierung einzugeben und die IP-Adresse/Hostname des jeweils anderen Server-Systems zu verwenden. Führe ich dieses Kommando also auf dem aktuellen Live-System aus gebe ich für den Parameter MASTER_HOST die IP-Adresse des Slave (HotSpare) Systems an.
Um die Replikation nun zu starten, führen wir auf beiden Datenbank-Servern den MySQL Befehl "START SLAVE" aus:
Mit Hilfe der Befehle "SHOW SLAVE STATUS", "SHOW MASTER STATUS", "SHOW PROCESSLIST", können wir nun schauen, was das System macht und ob die Replikation erfolgreich gestartet wurde. Als letzten Test sollten wir auf dem Live-Server mit der MySQL Shell oder einem GUI Tool einen neuen Datensatz in einer beliebigen Tabelle anlegen oder ändern und überprüfen, ob die Änderung zeitnah auf dem Slave-System ausgeführt wird. Ist dieses der Fall, können wir den GREYHOUND mittels des Admins wieder starten und in Betrieb nehmen.
5. Ausfall des Live-Systems bzw. Wechseln der Master
Wir wollen nicht hoffen, dass es soweit kommt, aber sollte der aktuelle Live Datenbank-Server sich einmal verabschieden oder einen Defekt aufweisen, können wir nun relativ einfach unser GREYHOUND System mit wenigen Schritten wieder online bringen und die Vorteile dieser Master-Master Replikations-Topologie nutzen.
Aufgrund der symmetrischen Konfiguration ist es relativ einfach, die Rollen der beiden Systeme zu vertauschen, ohne dass wir Gefahr laufen, widersprüchliche Aktualisierungen zu erhalten:
- Stoppen aller Schreiboperationen auf dem aktiven Server. Dafür beenden wir den GREYHOUND Server über den Admin und stellen sicher, dass auch sonst niemand auf den MySQL Server zugreift
- Wir führen den MySQL Befehl "SHOW MASTER STATUS" auf dem aktiven Server aus, und merken uns die Binärlog-Koordinaten. Das geht natürlich nur noch, sofern der Master noch irgendwie funktioniert und nicht total abgestürzt ist.
- Auf dem passiven System führen wir nun den Befehl "SELECT MASTER_POS_WAIT()" mit den Binärlog-Koordinaten des aktiven Servers aus. Dieser Befehl blockiert, bis die Slave Prozesse zum aktiven Server aufgeholt haben. Damit stellen wir 100% sicher, dass beide System nun konsistent sind und der Slave zum Master keinen Rückstand hat.
- Wir konfigurieren im GREYHOUND Admin die Datenbankverbindung auf den bisherigen passiven Server um und starten den GREYHOUND Server wieder.
6. Ausblick
Das Thema Replikation ist je nach Szenario recht umfangreich und ich empfehle jedem, der ernsthaft über den Einsatz einer solchen Lösung im produktiven Umfeld nachdenkt, sich intensiv mit der Materie zu beschäftigen und vorab die verschiedenen "Notsituationen" durchzuspielen, um im Fall der Fälle auch wirklich den Vorteil einer solchen Topologie nutzen zu können.
Für das tiefergehende Verständnis und weitere Details empfehle ich dem Interessierten das Buch "High Performance MySQL, Optimierung, Datensicherung, Replikation & Lastverteilung" aus dem OReilly Verlag in der zweiten Auflage.