Protokollversand und Replikation (SQL Server)

Beim Protokollversand werden zwei Kopien einer einzigen Datenbank verwendet, die normalerweise auf verschiedenen Computern gespeichert sind. Für die Clients ist immer nur eine Kopie der Datenbank verfügbar. Diese Kopie wird als primäre Datenbank bezeichnet. Updates, die von Clients an der primären Datenbank vorgenommen werden, werden durch den Protokollversand auf die andere Kopie der Datenbank übertragen, die als sekundäre Datenbank bezeichnet wird. Beim Protokollversand wird das Transaktionsprotokoll von jedem Einfüge-, Update- oder Löschvorgang, der an der primären Datenbank vorgenommen wird, auf die sekundäre Datenbank angewandt.

Der Protokollversand kann zusammen mit der Replikation verwendet werden, wobei das folgende Verhalten auftritt:

• Die Replikation wird nicht fortgesetzt, nachdem ein Failover des Protokollversands aufgetreten ist. Wenn ein Failover auftritt, stellen die Replikations-Agents keine Verbindung mit der sekundären Datenbank her, sodass keine Replikation der Transaktionen auf die Abonnenten erfolgt. Wenn ein Failback zur primären Datenbank auftritt, wird die Replikation fortgesetzt. Alle Transaktionen, die beim Protokollversand von der sekundären Datenbank zurück zur primären Datenbank kopiert werden, werden zu den Abonnenten repliziert.

• Wenn die primäre Datenbank dauerhaft verloren geht, kann die sekundäre Datenbank umbenannt werden, sodass die Replikation fortgesetzt werden kann. Im weiteren Verlaufs dieses Themas werden die Anforderungen und Prozeduren zur Behandlung dieses Falls beschrieben. Das bereitgestellte Beispiel bezieht sich auf die Veröffentlichungsdatenbank, weil bei dieser Datenbank der Protokollversand am häufigsten auftritt. Ein gleichartiger Prozess kann jedoch auch auf Abonnement- und Verteilungsdatenbanken angewendet werden.

Informationen zum Wiederherstellen von Datenbanken, die an der Replikation beteiligt sind, ohne dass dazu die Replikation neu konfiguriert werden muss, finden Sie unter Sichern und Wiederherstellen von replizierten Datenbanken.

Anforderungen und Prozeduren zum Replizieren von der sekundären Datenbank beim Ausfall der primären Datenbank

Beachten Sie die folgenden Anforderungen und Überlegungen:

• Wenn eine primäre Datenbank mehrere Veröffentlichungsdatenbanken enthält, muss der Protokollversand aller Veröffentlichungsdatenbanken zur selben sekundären Datenbank erfolgen.

• Der Installationspfad der Sekundärserverinstanz muss dem der primären Datenbank entsprechen. Die Speicherorte der Benutzerdatenbank auf dem Sekundärserver müssen denen auf dem Primärserver entsprechen.

• Sichern Sie den Diensthauptschlüssel auf der primären Datenbank. Dieser Schlüssel wird in der sekundären Datenbank wiederhergestellt. Weitere Informationen finden Sie unter BACKUP SERVICE MASTER KEY (Transact-SQL).

• Der Protokollversand garantiert keinen Schutz vor Datenverlust. Ein Ausfall der primären Datenbank kann zum Verlust der Daten führen, die noch nicht gesichert wurden oder deren Sicherungskopien bei dem Ausfall verloren gehen.

Protokollversand mit Transaktionsreplikation

Bei der Transaktionsreplikation hängt das Verhalten des Protokollversands von der sync with backup -Option ab. Diese Option kann für die Veröffentlichungsdatenbank und für die Verteilungsdatenbank festgelegt werden; beim Protokollversand für den Verleger ist nur die Einstellung für die Veröffentlichungsdatenbank relevant.

Wenn Sie diese Option für die Veröffentlichungsdatenbank festlegen, stellen Sie sicher, dass Transaktionen erst an die Verteilungsdatenbank übermittelt werden, wenn Sie in der Veröffentlichungsdatenbank gesichert wurden. Die neueste Sicherung der Veröffentlichungsdatenbank kann dann auf dem Sekundärserver wiederhergestellt werden, und es besteht keine Möglichkeit, dass die Verteilungsdatenbank Transaktionen enthält, die in der wiederhergestellten Veröffentlichungsdatenbank nicht vorhanden sind. Mit dieser Option wird die Konsistenz zwischen dem Verleger, dem Verteiler und den Abonnenten sichergestellt, wenn ein Failover des Verlegers zu einem Sekundärserver erfolgt. Latenzzeit und Durchsatz sind betroffen, da Transaktionen erst an die Verteilungsdatenbank übermittelt werden können, nachdem sie auf dem Verleger gesichert wurden. Wenn Ihre Anwendung diese Latenzzeit tolerieren kann, sollten Sie diese Option für die Veröffentlichungsdatenbank festlegen. Wenn die sync with backup -Option nicht festgelegt ist, können Abonnenten Änderungen empfangen, die nicht mehr in der wiederhergestellten Datenbank auf dem Sekundärserver enthalten sind. Weitere Informationen finden Sie unter Strategien zum Sichern und Wiederherstellen einer Momentaufnahme- und Transaktionsreplikation.

Konfigurieren der Transaktionsreplikation und des Protokollversands mit der "sync with backup"-Option

1. Wenn die "sync with backup"-Option nicht für die Veröffentlichungsdatenbank festgelegt ist, führen Sie sp_replicationdboption '<publicationdatabasename>', 'sync with backup', 'true'aus. Weitere Informationen finden Sie unter sp_replicationdboption (Transact-SQL).

2. Konfigurieren Sie den Protokollversand für die Veröffentlichungsdatenbank. Weitere Informationen finden Sie unter Konfigurieren des Protokollversands (SQL Server).

3. Bei einem Ausfall des Verlegers stellen Sie das letzte Protokoll der Datenbank mithilfe der Option KEEP_REPLICATION von RESTORE LOG auf dem Sekundärserver wieder her. Damit werden alle Replikationseinstellungen für die Datenbank beibehalten. Weitere Informationen finden Sie unter Failover zu einer sekundären Datenbank für den Protokollversand (SQL Server) und RESTORE (Transact-SQL).

4. Stellen Sie die msdb -Datenbank und die master -Datenbanken von der Primärdatenbank zur sekundären Datenbank wieder her. Weitere Informationen finden Sie unter Sichern und Wiederherstellen von Systemdatenbanken (SQL Server). Wenn die primäre Datenbank auch ein Verteiler war, stellen Sie die Verteilungsdatenbank von der primären zur sekundären Datenbank wieder her.

   Diese Datenbanken müssen im Hinblick auf die Replikationskonfiguration und auf die Einstellungen mit der Veröffentlichungsdatenbank auf dem Primärserver konsistent sein.

5. Benennen Sie auf dem Sekundärserver den Computer um, und benennen Sie dann die SQL Server -Instanz so um, dass ihr Name zum Primärservernamen passt. Informationen zum Umbenennen des Computers finden Sie in der Windows-Dokumentation. Informationen zum Umbenennen des Servers finden Sie unter Umbenennen eines Computers, der eine eigenständige Instanz von SQL Server hostet und Umbenennen einer SQL Server-Failoverclusterinstanz.

6. Stellen Sie auf dem Sekundärserver den Diensthauptschlüssel wieder her, der von der primären Datenbank gesichert wurde. Weitere Informationen finden Sie unter RESTORE SERVICE MASTER KEY (Transact-SQL).

Konfigurieren der Transaktionsreplikation und des Protokollversands ohne die "sync with backup"-Option

1. Konfigurieren Sie den Protokollversand für die Veröffentlichungsdatenbank. Weitere Informationen finden Sie unter Konfigurieren des Protokollversands (SQL Server).

2. Bei einem Ausfall des Verlegers stellen Sie das letzte Protokoll der Datenbank mithilfe der Option KEEP_REPLICATION von RESTORE LOG auf dem Sekundärserver wieder her. Damit werden alle Replikationseinstellungen für die Datenbank beibehalten. Weitere Informationen finden Sie unter Failover zu einer sekundären Datenbank für den Protokollversand (SQL Server) und RESTORE (Transact-SQL).

3. Stellen Sie die msdb -Datenbank und die master -Datenbanken von der Primärdatenbank zur sekundären Datenbank wieder her. Weitere Informationen finden Sie unter Sichern und Wiederherstellen von Systemdatenbanken (SQL Server). Wenn die primäre Datenbank auch ein Verteiler war, stellen Sie die Verteilungsdatenbank von der primären zur sekundären Datenbank wieder her.

   Diese Datenbanken müssen im Hinblick auf die Replikationskonfiguration und auf die Einstellungen mit der Veröffentlichungsdatenbank auf dem Primärserver konsistent sein.

4. Benennen Sie auf dem Sekundärserver den Computer um, und benennen Sie dann die SQL Server -Instanz so um, dass ihr Name zum Primärservernamen passt. Informationen zum Umbenennen des Computers finden Sie in der Windows-Dokumentation. Informationen zum Umbenennen des Servers finden Sie unter Umbenennen eines Computers, der eine eigenständige Instanz von SQL Server hostet und Umbenennen einer SQL Server-Failoverclusterinstanz.

   Sie erhalten möglicherweise eine Fehlermeldung vom Protokolllese-Agent, die besagt, dass die Veröffentlichungsdatenbank und die Verteilungsdatenbank nicht synchronisiert sind.

5. Stellen Sie auf dem Sekundärserver den Diensthauptschlüssel wieder her, der von der primären Datenbank gesichert wurde. Weitere Informationen finden Sie unter RESTORE SERVICE MASTER KEY (Transact-SQL).

6. Führen Sie sp_replrestart aus. Diese gespeicherte Prozedur kann dazu verwendet werden, den Protokolllese-Agent zu zwingen, alle vorhergehenden replizierten Transaktionen im Protokoll der Veröffentlichungsdatenbank zu ignorieren. Transaktionen, die nach dem Beenden der gespeicherten Prozedur angewendet werden, werden vom Protokolllese-Agent verarbeitet. Weitere Informationen finden Sie unter sp_replrestart (Transact-SQL).

7. Starten Sie den Protokolllese-Agent nach der erfolgreichen Ausführung der gespeicherten Prozedur neu. Weitere Informationen finden Sie unter Starten und Beenden eines Replikations-Agents (SQL Server Management Studio).

8. Transaktionen, die bereits an den Abonnenten verteilt wurden, können evtl. auf dem Verleger angewendet werden. Um sicherzustellen, dass der Verteilungs-Agent nicht zu einem Fehler führt, wenn versucht wird, diese Transaktionen erneut auf einen Abonnenten anzuwenden, müssen Sie das Agentprofil Fortsetzen bei Datenkonsistenzfehlernangeben.

Protokollversand mit Mergereplikation

Führen Sie die Schritte in der nachstehenden Prozedur aus, um die Mergereplikation und den Protokollversand zu konfigurieren.

So konfigurieren Sie die Mergereplikation und den Protokollversand

1. Konfigurieren Sie den Protokollversand für die Veröffentlichungsdatenbank. Weitere Informationen finden Sie unter Konfigurieren des Protokollversands (SQL Server).

2. Bei einem Ausfall des Verlegers benennen Sie den Computer auf dem Sekundärserver um, und weisen der SQL Server-Instanz dann einen Namen zu, der dem Namen des primären Servers entspricht. Informationen zum Umbenennen des Computers finden Sie in der Windows-Dokumentation. Informationen zum Umbenennen des Servers finden Sie unter Umbenennen eines Computers, der eine eigenständige Instanz von SQL Server hostet und Umbenennen einer SQL Server-Failoverclusterinstanz.

3. Stellen Sie das letzte Protokoll der Datenbank mithilfe der Option KEEP_REPLICATION von RESTORE LOG auf dem Sekundärserver wieder her. Damit werden alle Replikationseinstellungen für die Datenbank beibehalten. Weitere Informationen finden Sie unter Failover zu einer sekundären Datenbank für den Protokollversand (SQL Server) und RESTORE (Transact-SQL).

4. Stellen Sie die msdb -Datenbank und die master -Datenbanken von der Primärdatenbank zur sekundären Datenbank wieder her. Weitere Informationen finden Sie unter Sichern und Wiederherstellen von Systemdatenbanken (SQL Server). Wenn die primäre Datenbank auch ein Verteiler war, stellen Sie die Verteilungsdatenbank von der primären zur sekundären Datenbank wieder her.

   Diese Datenbanken müssen im Hinblick auf die Replikationskonfiguration und auf die Einstellungen mit der Veröffentlichungsdatenbank auf dem Primärserver konsistent sein.

5. Stellen Sie auf dem Sekundärserver den Diensthauptschlüssel wieder her, der von der primären Datenbank gesichert wurde. Weitere Informationen finden Sie unter RESTORE SERVICE MASTER KEY (Transact-SQL).

6. Synchronisieren Sie die Veröffentlichungsdatenbank mit einer oder mehreren Abonnementdatenbanken. Das ermöglicht Ihnen das Hochladen jener Änderungen, die zuvor in der Veröffentlichungsdatenbank zwar vorgenommen, aber in der wiederhergestellten Sicherung nicht vorhanden sind. Welche Daten dabei hochgeladen werden können, hängt davon ab, wie die Veröffentlichung gefiltert wird:

   • Wird die Veröffentlichung gar nicht gefiltert, sollten Sie die Veröffentlichungsdatenbank durch Synchronisieren mit einem aktuellen Abonnenten auf den neuesten Stand bringen.

   • Wenn die Veröffentlichung gefiltert ist, können Sie möglicherweise die Veröffentlichungsdatenbank nicht auf den aktuellen Stand bringen. Angenommen, eine Tabelle ist so partitioniert, dass jedes Abonnement nur die Kundendaten für eine der folgenden Regionen erhält: Nord, Ost, Süd und West. Wenn für jede Datenpartition mindestens ein Abonnent vorhanden ist, würde es reichen, die Veröffentlichungsdatenbank mit einem Abonnenten für jede Partition zu synchronisieren, um sie auf den neuesten Stand zu bringen. Wenn aber beispielsweise die Daten in der Partition West auf keinen Abonnenten repliziert wurden, können diese Daten auf dem Verleger nicht auf den aktuellen Stand gebracht werden. In diesem sollten Sie alle Abonnements initialisieren, sodass die Daten auf dem Verleger und den Abonnenten zusammengeführt werden. Weitere Informationen finden Sie unter Erneutes Initialisieren von Abonnements.

   Wenn Sie eine Synchronisierung mit einem Abonnenten durchführen, der eine Version von SQL Server vor SQL Server 2005 ausführt, kann das Abonnement nicht anonym sein. Es muss sich um ein Clientabonnement oder Serverabonnement (in früheren Versionen als lokale Abonnements und globale Abonnements bezeichnet) sein. Weitere Informationen finden Sie unter Synchronisieren von Daten.

Weitere Informationen

SQL Server-Replikation
Informationen zum Protokollversand (SQL Server)
Datenbankspiegelung und Replikation (SQL Server)