saftmeister
Nutze den Saft!
Die Informationen hätten mal eher kommen sollen. Hiernach sehe ich vollkommen ein, das eine Replikation der DB Kanonen-auf-Spatzen ist. DB-Dump+Import genügt vollends. Ich bin davon aus, das jede Menge Laufzeit-Daten verwendet und damit hohe Datenbank-Fluktuation statt findet. Gewaltig getäuscht.
Zu den Punkten: Lässt sich alles prima mit Bordmitteln erledigen.
Du solltest aber für alle Server einen separaten Benutzer in der MySQL-DB für den Dump- und Import-Prozess anlegen, der auf den jeweiligen Umgebungen jeweils nur die entsprechenden Rechte hat, wenn du bspw. verbieten willst, das ein INSERT-INTO auf dem Master möglich ist.
Für den Fail-over-switch solltest du dir Gedanken machen, ob kompletter Hardware-Ausfall auch abgefangen werden soll. In diesem Falle empfehle ich, eine Monitoring-Komponente auf einer anderen dedizierten Maschine zu installieren, die alle Server überwacht und ggf. eine weitere Flag-Spalte umsetzt oder den neuen Master definiert => hier sehe ich erstmal größeren Aufwand auf grund von Eintragungen im Nameserver (IP tauschen, neu starten, DNS-Tabelle replizieren lassen, etc). Letztendlich könntest du eine Ausfallzeit von ca. 15-30 Min haben aufgrund von DNS-Caches, Nameservice-Replikation und so weiter. Durch bereits erwähntes Round-Robin wäre es möglich, das abzufangen, allerdings verstößt das gegen die anderen Bedingungen des Konzepts, das z.B. keine Eintragungen von Daten an den Slaves möglich sein soll.
Außerdem kann es aufwendig werden, den Fail-Over zu testen. Der Fail-Over besteht prinzipiell aus folgenden Einzelschritten, die vom Monitor erledigt werden müssten:
1. Neu-Definieren des Masters aufgrund der Tabelle, die (auch/nur) auf der Monitoring-Einheit vorhanden ist
2. Connect zum Nameserver und austausch der IP-Addresse für Domain xyz.tld
3. [Schritt abhängig von der Sicherheitsstufe der Benutzer-Einstellung in der MySQL-DB]
- Neu-Setzen der Privilegien für den Laufzeit-Benutzer der Scripts für Dump auf dem neuen Master (INSERT INTO jetzt verboten)
4. Anlegen der Cron-Jobs für Sonntag (Dump+Dateien) - Für Dateien empfehle ich rsync - ist mehrfach erprobt und kommt gut mit großen und kleinen Mengen zurecht
5. Auf der DB des neuen Masters muss der (noch nicht konzipierte) Zugriff für den Administrator gewährt werden, das könnte man so erledigen, das bei jedem Login am Admin-Panel die Monitoring-Komponente gefragt wird, wer der aktuelle Master ist (mysql_connect() zur Monitoring-Komponente, Abfragen etc.); Hat den Vorteil, das dies ab dem Zeitpunkt möglich wäre, an dem die Monitoring-Komponente den Ausfall bemerkt hat und die Rollen neu verteilt wurden. Nachteil ist der Traffic zwischen zwei verschiedenen Maschinen bei Login am AP muss sichergestellt werden.
Zu deiner Frage mit dem Config-File: Ich glaube nicht, das dies notwendig ist, denn sämtliche Tasks beim Fail-Over erfordern ohnehin Änderungen am System. Ob man jetzt ein Konfig-File anpasst, oder Links neu im Dateisystem verlegt, ist dann erstmal egal. Beim Config-File wäre mir die Gefahr zu hoch, das eine Änderung das System im Ganzen kaputt macht. Die Monitoring-Komponente kann vorgefertige Scripte auf dem neuen Server über HTTP aufrufen, welche die entsprechenden Tasks ausführt, die im Fail-Over definiert sind.
So, das war erst mal ein bisschen Input. Du kannst mit den Vorschlägen verfahren wie du willst, evtl. hast du dadurch noch bessere Ideen.
Zu den Punkten: Lässt sich alles prima mit Bordmitteln erledigen.
Du solltest aber für alle Server einen separaten Benutzer in der MySQL-DB für den Dump- und Import-Prozess anlegen, der auf den jeweiligen Umgebungen jeweils nur die entsprechenden Rechte hat, wenn du bspw. verbieten willst, das ein INSERT-INTO auf dem Master möglich ist.
Für den Fail-over-switch solltest du dir Gedanken machen, ob kompletter Hardware-Ausfall auch abgefangen werden soll. In diesem Falle empfehle ich, eine Monitoring-Komponente auf einer anderen dedizierten Maschine zu installieren, die alle Server überwacht und ggf. eine weitere Flag-Spalte umsetzt oder den neuen Master definiert => hier sehe ich erstmal größeren Aufwand auf grund von Eintragungen im Nameserver (IP tauschen, neu starten, DNS-Tabelle replizieren lassen, etc). Letztendlich könntest du eine Ausfallzeit von ca. 15-30 Min haben aufgrund von DNS-Caches, Nameservice-Replikation und so weiter. Durch bereits erwähntes Round-Robin wäre es möglich, das abzufangen, allerdings verstößt das gegen die anderen Bedingungen des Konzepts, das z.B. keine Eintragungen von Daten an den Slaves möglich sein soll.
Außerdem kann es aufwendig werden, den Fail-Over zu testen. Der Fail-Over besteht prinzipiell aus folgenden Einzelschritten, die vom Monitor erledigt werden müssten:
1. Neu-Definieren des Masters aufgrund der Tabelle, die (auch/nur) auf der Monitoring-Einheit vorhanden ist
2. Connect zum Nameserver und austausch der IP-Addresse für Domain xyz.tld
3. [Schritt abhängig von der Sicherheitsstufe der Benutzer-Einstellung in der MySQL-DB]
- Neu-Setzen der Privilegien für den Laufzeit-Benutzer der Scripts für Dump auf dem neuen Master (INSERT INTO jetzt verboten)
4. Anlegen der Cron-Jobs für Sonntag (Dump+Dateien) - Für Dateien empfehle ich rsync - ist mehrfach erprobt und kommt gut mit großen und kleinen Mengen zurecht
5. Auf der DB des neuen Masters muss der (noch nicht konzipierte) Zugriff für den Administrator gewährt werden, das könnte man so erledigen, das bei jedem Login am Admin-Panel die Monitoring-Komponente gefragt wird, wer der aktuelle Master ist (mysql_connect() zur Monitoring-Komponente, Abfragen etc.); Hat den Vorteil, das dies ab dem Zeitpunkt möglich wäre, an dem die Monitoring-Komponente den Ausfall bemerkt hat und die Rollen neu verteilt wurden. Nachteil ist der Traffic zwischen zwei verschiedenen Maschinen bei Login am AP muss sichergestellt werden.
Zu deiner Frage mit dem Config-File: Ich glaube nicht, das dies notwendig ist, denn sämtliche Tasks beim Fail-Over erfordern ohnehin Änderungen am System. Ob man jetzt ein Konfig-File anpasst, oder Links neu im Dateisystem verlegt, ist dann erstmal egal. Beim Config-File wäre mir die Gefahr zu hoch, das eine Änderung das System im Ganzen kaputt macht. Die Monitoring-Komponente kann vorgefertige Scripte auf dem neuen Server über HTTP aufrufen, welche die entsprechenden Tasks ausführt, die im Fail-Over definiert sind.
So, das war erst mal ein bisschen Input. Du kannst mit den Vorschlägen verfahren wie du willst, evtl. hast du dadurch noch bessere Ideen.