Kategorie:StandBy: Unterschied zwischen den Versionen
Sed (Diskussion | Beiträge) |
Sed (Diskussion | Beiträge) |
||
| Zeile 15: | Zeile 15: | ||
Folgende Punkte sind dabei zu beachten: | Folgende Punkte sind dabei zu beachten: | ||
| − | # Das Master-System legt während des Backups/Snapshots ein Lock-File an (<code>$ | + | # Das Master-System legt während des Backups/Snapshots ein Lock-File an (<code>$SITEPARK_BACKUP/.iesadmin_backup.lock</code>). Dieses sollte abgefragt werden, damit nicht während eines Backups Datensätze eingelesen werden |
# Das StandBy-System würde jedes ''Recover'' mit dem Einspielen des vollständigen Dumps beginnen. Das führt zu einer sehr hohen Last. | # Das StandBy-System würde jedes ''Recover'' mit dem Einspielen des vollständigen Dumps beginnen. Das führt zu einer sehr hohen Last. | ||
# Das StandBy-System würde die Datei mit den Backup-Definitionen schreiben. Das hat indirekt auch Einfluss auf die Routinen des Master-Systems | # Das StandBy-System würde die Datei mit den Backup-Definitionen schreiben. Das hat indirekt auch Einfluss auf die Routinen des Master-Systems | ||
Version vom 28. Oktober 2009, 15:31 Uhr
IES Standby (noch in der frühen Entwicklungsphase )
Konzept
Das Konzept zur Realisierung eines Warm-StandBy-Systems basiert auf den Regeln zum Kategorie:Backup. Im Prinzip gibt es ein System, welches für unterschiedliche Mandanten als sog. Warm-StandBy-System agiert. Das bedeutet, dass dort alle Daten eines Master-Systems regelmäßig synchronisiert werden. Dieses Warm-StandBy-System kann zwar gestartet sein, aber die entsprechenden Mandanten müssen deaktiviert sein, da sonst Inkonsistenten auf Datenbank-Ebene entstehen würden. Im Bedarfsfall (z.B. Ausfall des Master-Systems, oder umfangreiche Wartungsarbeiten) kann das Warm-StandBy-System (z.B. über Änderung des NATing) verwendet werden. Dabei sind jedoch die entsprechenden Mandanten zu aktivieren. In diesem Fall wird die weitere Synchronisation dauerhaft abgebrochen und kann nur durch manuelle Synchronisation (via Vollbackup) mit dem Master-System aufgebaut werden. IES StandBy Mechanismen sind jedoch noch in der frühen Entwicklungsphase.
Alternative
Bis zur Bereitstellung von Warm-StandBy-Mechanismen im IES kann jedoch unter bestimmten Voraussetzungen folgender Ansatz verwendet werden.
- Das IES-Backup-Verzeichnis des Master-Systems wird transparent über das Netzwerk auf dem StandBy-System eingebunden
- Der Master generiert in regelmäßigen Zyklen automatisch Snapshots
- Das StandBy-System importiert in regelmäßigen Zyklen den jeweils letzten Snapshot
Folgende Punkte sind dabei zu beachten:
- Das Master-System legt während des Backups/Snapshots ein Lock-File an (
$SITEPARK_BACKUP/.iesadmin_backup.lock). Dieses sollte abgefragt werden, damit nicht während eines Backups Datensätze eingelesen werden - Das StandBy-System würde jedes Recover mit dem Einspielen des vollständigen Dumps beginnen. Das führt zu einer sehr hohen Last.
- Das StandBy-System würde die Datei mit den Backup-Definitionen schreiben. Das hat indirekt auch Einfluss auf die Routinen des Master-Systems
Der Aufruf auf dem StandBy-System könnte wie folgt aussehen:
iesadmin recover <client> -d /network/sitepark/backup current
Diese Kategorie enthält zurzeit keine Seiten oder Medien.