Actian Ingres – Wiederherstellung im Katastrophenfall
Die meisten Actian Ingres-Produktionsinstallationen erfordern in gewissem Umfang Wiederherstellung im Katastrophenfall DR). Die Optionen reichen vom nächtlichen Versand von Datenbank-Checkpoints an externe Speicherorte bis hin zur Replikation nahezu in Echtzeit an einen dedizierten externen DR-Standort.
Die Actian Ingres Enterprise Hybrid-Datenbank verfügt über integrierte Checkpoint- und Journal-Shipping-Funktionen, die die grundlegenden Bausteine für die Erstellung kostengünstiger und effizienter Disaster-Recovery-Lösungen bilden. Eine solche Lösung ist IngresSync, das Fähigkeiten nativen Checkpoint-/Journal-Shipping- und inkrementellen Fähigkeiten von Actian Ingres nutzt, Fähigkeiten eine kosteneffiziente Disaster-Recovery-Lösung zu realisieren.

IngresSync basiert auf dem Konzept von Quell- und Zielinstallationen von Actian Ingres. Die Quellinstallation ist die derzeit aktive Produktionsumgebung. Das Ziel – oder bei Bedarf mehrere Ziele – wird durch einen IngresSync-Job auf dem neuesten Stand gehalten, dessen Ausführung in einem Nutzer Intervall geplant ist. Bei jedem Synchronisierungsvorgang werden nur die seit der letzten Synchronisierung erstellten Journale kopiert und diese Transaktionen auf die Ziele übertragen. Auf dem Quellknoten erstellte Checkpoints werden automatisch auf alle Ziele kopiert und dort fortgesetzt.
Beispiel
Nehmen wir an, wir haben eine Umgebung, in der die Produktionsinstallation auf dem Knoten „corp“ gehostet wird und wir zwei DR-Standorte namens „dreast“ und „drwest“ einrichten müssen.
Die DR-Knoten benötigen jeweils:
- Eine Ingres-Installation mit derselben Version und demselben Patch-Stand wie die Unternehmensversion.
- Passwortloses SSH zwischen den anderen Knoten wurde eingerichtet.
- Ingres/Net-VNODE-Einträge an die anderen Knoten.

Um diese Umgebung zu konfigurieren, müssen wir zunächst die Quell- und Zielhosts festlegen und den neuesten Quell-Checkpoint auf die Ziele anwenden.
ingresSync --source=corp --target=dreast,drwest --database=corpdb --iid=II --ckpsync --restart

Die beiden Zielinstallationen sind nun mit der Quelle synchronisiert, und die Zieldatenbanken befinden sich im Status „Inkrementeller Rollforward“ (INCR_RFP). Dieser Status ermöglicht es, Journale inkrementell zu übernehmen, um die Ziele mit der Quelle synchron zu halten. Der inkrementelle Rollforward wird wie folgt durchgeführt:
ingresSync --hosts=corp,dreast,drwest --database=corpdb --iid=II --jnlsync
Bei der Ausführung werden das aktuelle Journal auf der Quelle geschlossen, neue Journale auf die Ziele kopiert und diese Journale auf die Ziele übertragen. Der Schritt zur Journalsynchronisierung sollte so konfiguriert werden, dass er in regelmäßigen Abständen über den Systemplaner, beispielsweise Cron, ausgeführt wird. Eine häufige Ausführung sorgt für minimale Synchronisierungsverzögerungen zwischen der Quelle und den Zielen.
Die Zielinstallationen bei dreast und drwest sind nun mit der Quellinstallation bei corp synchronisiert. Sollte es in der corp-Umgebung zu einem Hardware- oder Softwareausfall kommen, können wir einen der Zielknoten als neue Quelle festlegen und die Client-Verbindungen an diesen Knoten umleiten. In diesem Fall werden wir drwest als neue Quelle festlegen, während dreast als Ziel (DR-Standort) erhalten bleibt.
ingresSync --target=drwest --database=corpdb --iid=II --incremental_done
Dadurch wird die Datenbank „drwest corpdb“ aus dem inkrementellen Rollforward-Modus genommen; die Datenbank führt nun sowohl Lese- als auch Aktualisierungstransaktionen aus und ist die neue Quelle. Die Datenbank „dreast“ befindet sich weiterhin im inkrementellen Rollforward-Modus und fungiert weiterhin als DR-Zielknoten.

Da der Corp-Knoten nicht mehr verfügbar ist, muss der Journal-Synchronisierungsjob entweder auf drwest oder dreast gestartet werden. Der Journal-Synchronisierungsjob kann mithilfe des Flags –strict so konfiguriert und geplant werden, dass er auf allen drei Knoten ausgeführt wird. In diesem Fall prüft der Job, ob er auf dem aktuellen Quellknoten ausgeführt wird; ist dies der Fall, wird er normal ausgeführt. Wird er auf einem Zielknoten ausgeführt, wird der Job einfach beendet. Diese Konfiguration ermöglicht es, die Synchronisierung auch dann fortzusetzen, wenn sich die Rollen der Knoten ändern.
Sobald der Server wieder online ist, kann er wieder als DR-Ziel in die Konfiguration aufgenommen werden.
ingresSync --source=drwest --target=corp --database=corpdb --iid=II --ckpsync --restart

Möglicherweise müssen wir irgendwann wieder zur ursprünglichen Konfiguration zurückkehren, bei der „corp“ als Quelle dient. Die Schritte lauten wie folgt:
- Alle Datenbankverbindungen zu drwest beenden
-
Synchronisieren
Corp
mit
drwest
um sicherzustellen, dass
Corp
ist aktuell ingresSync --source=drwest --target=corp --database=corpdb --iid=II --jnlsync
-
Knotenrollen neu zuweisen ingresSync --target=corp --database=corpdb --iid=II --incremental_done ingresSync --source=corp --target=drwest --database=corpdb --iid=II --ckpsync --restart

Zusammenfassung
IngresSync ist ein Mechanismus zur Implementierung einer DR-Lösung. Er eignet sich im Allgemeinen für Fälle, in denen eine gewisse Verzögerung akzeptabel ist und die Zielinstallationen nur geringe oder gar keine Nutzer aufweisen. Die Zieldatenbanken können für Read-only Anwendungen Read-only genutzt werden, wobei zu beachten ist, dass inkrementelle Rollforwards nicht ausgeführt werden können, solange aktive Datenbankverbindungen bestehen. Der Rollforward-Prozess holt den Rückstand im ersten Aktualisierungszyklus auf, wenn keine aktiven Datenbankverbindungen bestehen.
Die wichtigsten Vor- und Nachteile der alternativen Methoden zur Wiederherstellung im Katastrophenfall Actian Ingres sind im Folgenden aufgeführt:
| Funktion | Checkpoint Versand | IngresSync | Replikation |
| Geltungsbereich | Datenbank | Datenbank | Tabelle |
| Granularität | Datenbank | Zeitschrift | Transaktion |
| Synchronisationsfrequenz | Kontrollpunkt | Nutzer | Transaktion |
| Zieldatenbank | Lesen/Schreiben(1) | Read-only | Lesen/Schreiben(2) |
- Die Zieldatenbank unterstützt Lese- und Schreibvorgänge, doch alle Änderungen gehen bei der nächsten Checkpoint-Aktualisierung verloren.
- Die Zieldatenbank unterstützt Lese- und Schreibvorgänge, es kann jedoch zu Aktualisierungskonflikten kommen, die manuell gelöst werden müssen.
Hinweis: IngresSync läuft derzeit unter Linux und Microsoft Windows. In Windows-Umgebungen sind das Cygwin-Basispaket und rsync erforderlich.