DB2 HADR (Teil I) -
High Availability Disaster Recovery

Die von Informix unter dem Namen High Availability Data Replication bekannte Replikation ist ab der Version 8.2 von DB2 unter dem Namen HADR verfügbar. Im ersten Teil dieses Artikels wollen wir die generelle Funktionsweise vorstellen. Der zweite Teil beschäftigt sich dann mit der praktischen Umsetzung.

Übersicht

HADR ist eine Datenbankreplikation, die vor dem Ausfall eines Datenbankservers schützt. Abbildung 1 zeigt die generelle Arbeitsweise einer HADR. Die Datenbank wird dabei den Clients innerhalb sehr kurzer Zeit ohne Datenverlust auf einem anderen Server zur Verfügung gestellt.

Abb. 1: Die Arbeitsweise des High Availability Disaster Recoverys..

Dafür werden zwei Server mit gleicher Hard- und Softwareausstattung benötigt. Auf beiden Servern wird eine Datenbank erzeugt. Die Datenbank, mit der im normalen Betrieb gearbeitet wird, ist die Primärdatenbank. Die andere, die für den Fehlerfall verwendet wird, die Bereitschafts- oder Standby-Datenbank.

Der Anwender greift immer auf die Primärdatenbank zu. Die Änderungen auf der Primärdatenbank werden auf der Standby-Datenbank nachgefahren. Dazu werden die Protokolldateien von der Primärdatenbank zur Standby-Datenbank übertragen und dort nachgefahren. Die Standby-Datenbank befindet sich permanent im Status „Aktualisierende Wiederherstellung wird ausgeführt“.

Wenn die primäre Datenbank ausfällt, übernimmt die Standby-Datenbank die Funktion der Primärdatenbank. Über die automatische Client-Weiterleitung kann dies für die Clients transparent erfolgen.

Systemvoraussetzungen

Die Rechner, auf denen die Primärdatenbank und die Standby-Datenbank laufen, müssen auf der gleichen Hard- und Software aufgebaut sein. Insbesondere, da die Standby-Datenbank nach der Übernahme zur Primärdatenbank wird. Bei der Hardware müssen Produkte des gleichen Herstellers mit der gleichen Architektur verwendet werden. Die Versionen und Korrekturstände des Betriebsystems müssen dieselben sein.

Zwischen beiden Rechnern wird eine schnelle TCP-IP Netzwerkverbindung benötigt. HADR unterstützt nur das Netzwerkprotokoll TCP/IP.

DB2 Voraussetzungen

Auf beiden Rechnern muss dieselbe DB2 Version mit gleichem Stand der Fix Packs installiert sein. Ein Mischen z. B. von 32 und 64 Bit Versionen ist nicht möglich.

Tablespaces und Container müssen identisch im Bezug auf Typ (DMS oder SMS), Größe, Pfad und Dateityp angelegt werden. Durch die Verwendung von virtuellen Pfaden ist es möglich, auf beiden Maschinen auch unterschiedliche physikalische Pfade zu verwenden. Übersichtlicher ist es aber auf jeden Fall, beide Maschinen auch physikalisch identisch aufzubauen.

Da alle Operationen sowohl im Bufferpool der Primärdatenbank als auch im Bufferpool der Standby-Datenbank wiederholt werden, müssen die Bufferpools auf beiden Maschinen dieselbe Größe haben.

Einschränkungen

HADR wird nur von der DB2 UDB Enterprise Server Edition (ESE) unterstützt. Die Datenbanksysteme dürfen nicht partitioniert sein.

Da sich die Standby-Datenbank immer im Status „Aktualisierende Wiederherstellung wird ausgeführt“ befindet, können Clients nur auf die Primärdatenbank zugreifen. Daher ist es nicht möglich, eine Online-Sicherung der Standby-Datenbank und ihrer Protokolldateien zu erstellen.

Änderungen, die an der Datenbankmanager- bzw. Datenbankkonfiguration vorgenommen werden, werden nicht repliziert und müssen manuell auf beiden Systemen vorgenommen werden.

Datenbankkonfiguration

Die Datenbankkonfigurationsparameter auf der Primärdatenbank und der Standby-Datenbank müssen identisch sein. Ansonsten kann es beim Nachfahren der Protokolldateien auf der Standby-Datenbank zu Fehlern kommen.

Änderungen an den Konfigurationsparametern müssen manuell auf beiden Datenbanken vorgenommen werden. Bei dynamischen Parametern ist kein Neustart der Datenbank erforderlich. Bei nicht dynamischen Parametern muss die Datenbank neu gestartet werden. Durch ein schrittweises Upgrade ist es möglich, auch dies ohne große Ausfallzeit durchzuführen.

Die Standby-Datenbank empfängt alle Protokolldateien in ihrem „Log Receive Buffer“. Die Standardeinstellung für die Größe des Puffers ist die doppelte Größe von LOGBUFSZ. Um an dieser Stelle Engpässe zu vermeiden, ist es sinnvoll, die Größe des Log Receive Buffers zu erhöhen. Dies wird über die Variable
DB2_HADR_BUF_SIZE der DB2 Profile Registry vorgenommen.

Konfigurationsparameter

Für HADR gibt es spezielle Parameter in der Datenbankkonfiguration. Durch das Setzen der Parameter wird eine Datenbank aber noch nicht zu einer HADR-Datenbank. Dies muss mit den entsprechenden Kommandos (HADR START und HADR STOP) vorgenommen werden. Die zu setzenden Parameter sind in Abbildung 2 beschrieben.

Status der Standby-Datenbank

Nach dem Starten der Standby-Datenbank durchläuft die Datenbank die in Abbildung 3 dargestellten Modi.

Abb. 3: Status der Standby-Datenbank..

Lokales Catch-up

Nach dem Starten der Datenbank versucht diese, die Protokolldateien in ihrem lokalen Protokollverzeichnis zu lesen und nachzufahren. Dazu ist keine Verbindung zur Primärdatenbank erforderlich. Ein Zugriff auf die Datenbank ist in diesem Modus nicht möglich.

Sind alle Protokolle nachgefahren und ist keine Verbindung zur Primärdatenbank vorhanden, wechselt die Standby-Datenbank in den Status „Fernes Catch-up anstehend“. Sobald eine Verbindung zur Primärdatenbank vorhanden ist, wechselt sie in den Status „Fernes Catch-up“.

Fernes Catch-up

Die Primärdatenbank liest ihre Protokolldateien und überträgt diese zur Standby-Datenbank. Die Standby-Datenbank fährt die Protokolle nach. Wenn alle Protokolle übertragen und nachgefahren sind, wechseln beide Datenbanken in den „Peerstatus“.

Peerstatus

Im Peerstatus überträgt die Primärdatenbank, sobald eine Protokoll-Page auf die Platte ge­schrie­ben wird, diese an die Standby-Datenbank. Die Standby-Datenbank schreibt die Protokoll-Pages in ihre Protokolldateien. Dadurch ist sichergestellt, dass die Reihenfolge der Protokolleinträge in beiden Datenbanken identisch sind. Danach werden die Transaktionen aus den Protokollen in der Standby-Datenbank nachgefahren.

Der Status der Datenbank kann mit folgendem Kommando ermittelt werden: db2 get snapshot for database on sample

Synchronisationsmodi

Über den Konfigurationsparameter HADR_SYNCMODE kann der Modus der Replikation eingestellt werden.

Über den Modus wird festgelegt, wann eine Transaktion auf der Primärdatenbank nach einem COMMIT die Bestätigung erhält, dass die Transaktion festgeschrieben wurde.

Durch den Modus wird zum einen die Transaktionsantwortzeit und zum anderen die Sicherheit beeinflusst. Wobei mit besserer Transak­tionsantwortzeit die Sicherheit abnimmt.

Im einzelnen gibt es die drei folgenden Synchronisationsmodi:

SYNC (synchron)

Der Synchronisationsmodus SYNC bietet die höchste Sicherheit gegen Datenverlust, hat aber die längsten Transaktionsantwortzeiten.

Eine Transaktion auf dem Primärrechner wird erst dann als festgeschrieben betrachtet, wenn die Protokolleinträge auf dem Primärrechner in die Protokolldatei geschrieben wurden, die Protokolleinträge zur Standby-Datenbank übertragen wurden und auch dort in die Protokolldatei geschrieben wurden.

Dadurch wird sichergestellt, dass Protokolleinträge einer festgeschriebenen Transaktion auf beiden Datenbanken vorhanden sind.

NEARSYNC (fast synchron)

Der Synchronisationsmodus NEARSYNC hat etwas kürzere Transaktionsantwortzeiten aber auch weniger Sicherheit.

Eine Transaktion auf dem Primärrechner wird erst dann als festgeschrieben betrachtet, wenn die Protokolleinträge auf dem Primärrechner in die Protokolldatei geschrieben wurden, die Protokolleinträge zur Standby-Datenbank übertragen wurden und dort im Hauptspeicher angekommen sind.

Bei einem gleichzeitigen Ausfall der Systeme, kann es vorkommen, dass Protokolleinträge verloren gehen, wenn danach nur noch die Standby-Datenbank zur Verfügung steht.

ASYNC (asynchron)

Der Synchronisationsmodus ASYNC bietet die kürzesten Transaktionsantwortzeiten, aber auch die geringste Sicherheit.

Eine Transaktion auf dem Primärrechner wird erst dann als festgeschrieben betrachtet, wenn die Protokolleinträge auf dem Primärrechner in die Protokolldatei geschrieben wurden und an die TCP-Schicht des Rechners übergeben wurden. Auch hier ist es möglich, dass Protokolldateien verloren gehen.

Das Hauptproblem beim Verlust von Protokolldateien ist, dass die ursprüngliche Primärdatenbank, nicht mehr als Standby-Datenbank verwendet werden kann. In ihr sind Transaktionen festgeschrieben, die auf der ursprünglichen Standby-Datenbank nicht festgeschrieben waren, als diese die Funktion der Primärdatenbank übernommen hat.

Um die ursprüngliche Primärdatenbank wieder als Standby-Datenbank zu verwenden, ist es notwendig, einen kompletten Restore durchzuführen.

Automatische Client-Weiterleitung

Bei der Funktionsübernahme verlieren die Clients die Verbindung zur Datenbank. Bei einem Zugriff auf die Datenbank kommt es zu einer Fehlermeldung. Dies kann mit der automatischen Client-Weiterleitung verhindert werden. Auch hier geht die aktuelle Verarbeitung verloren, nur der Verbindungsaufbau zur Standby-Datenbank erfolgt automatisch.

Auf der Primärdatenbank kann ein alternativer Server für eine Datenbank hinterlegt werden. Die wird mit dem Kommando UPDATE ALTERNATE SERVER FOR DATABASE vorgenommen. Im folgenden Beispiel wird für die Datenbank sample der Rechner rechner2 und der Netzwerkport 50000 als Alternative eingetragen:

db2 update alternate server for database sample using hostname rechner2 port 50000

Der Client bekommt diese Information dann beim Verbindungsaufbau zur Datenbank mitgeteilt.

Ausblick

Der zweite Teil des Artikels zeigt an einem kleinen Beispiel, wie HADR aufzusetzen und zu konfigurieren ist.

Holger Demuth (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen