Replikation und Protokollversand

  • Artikel

Aktualisiert: 14. April 2006

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. Aktualisierungen, 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-, Aktualisierungs- 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 Publikationsdatenbank, 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 replizierter Datenbanken.

ms151224.note(de-de,SQL.90).gifHinweis:
Es wird empfohlen, anstelle des Protokollversands die Datenbankspiegelung zu verwenden, um die Verfügbarkeit der Publikationsdatenbank sicherzustellen. Weitere Informationen finden Sie unter Replikation und Datenbankspiegelung.

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 Publikationsdatenbanken enthält, muss der Protokollversand aller Publikationsdatenbanken 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 Publikationsdatenbank und für die Verteilungsdatenbank festgelegt werden; beim Protokollversand für den Verleger ist nur die Einstellung für die Publikationsdatenbank relevant.

Wenn Sie diese Option für die Publikationsdatenbank festlegen, stellen Sie sicher, dass Transaktionen erst an die Verteilungsdatenbank übermittelt werden, wenn Sie in der Publikationsdatenbank gesichert wurden. Die neueste Sicherung der Publikationsdatenbank kann dann auf dem Sekundärserver wiederhergestellt werden, und es besteht keine Möglichkeit, dass die Verteilungsdatenbank Transaktionen enthält, die in der wiederhergestellten Publikationsdatenbank 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. Wartezeit 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 Wartezeit tolerieren kann, sollten Sie diese Option für die Publikationsdatenbank 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 Snapshot- 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 Publikationsdatenbank 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 Publikationsdatenbank. Weitere Informationen finden Sie unter Konfigurieren des Protokollversands.
  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 Ausführen eines Failovers zu einer sekundären Datenbank für den Protokollversand und RESTORE (Transact-SQL).
  4. Stellen Sie die msdb-Datenbank und die master-Datenbanken von der primären Datenbank zur sekundären Datenbank wieder her. Weitere Informationen finden Sie unter Überlegungen zum Wiederherstellen der model-Datenbank und der msdb-Datenbank und Überlegungen zum Wiederherstellen der master-Datenbank. 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 Publikationsdatenbank auf dem Primärserver konsistent sein.
  5. Benennen Sie auf dem Sekundärserver den Computer um, und benennen Sie dann die Microsoft SQL Server-Instanz so um, dass ihr Name zum Primärservernamen passt. Informationen zum Umbenennen des Computers finden Sie in der Windows-Dokumentation. Informationen zu diesen Optionen finden Sie unter Vorgehensweise: Umbenennen eines Computers, der eine eigenständige Instanz von SQL Server 2005 hostet und Vorgehensweise: Umbenennen eines virtuellen SQL Server 2005-Servers.
  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 Publikationsdatenbank. Weitere Informationen finden Sie unter Konfigurieren des Protokollversands.
  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 Ausführen eines Failovers zu einer sekundären Datenbank für den Protokollversand 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 Überlegungen zum Wiederherstellen der model-Datenbank und der msdb-Datenbank und Überlegungen zum Wiederherstellen der master-Datenbank. 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 Publikationsdatenbank 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 zu diesen Optionen finden Sie unter Vorgehensweise: Umbenennen eines Computers, der eine eigenständige Instanz von SQL Server 2005 hostet und Vorgehensweise: Umbenennen eines virtuellen SQL Server 2005-Servers.
    Sie erhalten möglicherweise eine Fehlermeldung vom Protokolllese-Agent, die besagt, dass die Publikationsdatenbank 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 Publikationsdatenbank 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 Vorgehensweise: 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 Datenkonsistenzfehlern angeben. Weitere Informationen finden Sie unter Überspringen von Fehlern in der Transaktionsreplikation.

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 Publikationsdatenbank. Weitere Informationen finden Sie unter Konfigurieren des Protokollversands.
  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 Ausführen eines Failovers zu einer sekundären Datenbank für den Protokollversand 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 Überlegungen zum Wiederherstellen der model-Datenbank und der msdb-Datenbank und Überlegungen zum Wiederherstellen der master-Datenbank. 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 Publikationsdatenbank 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 zu diesen Optionen finden Sie unter Vorgehensweise: Umbenennen eines Computers, der eine eigenständige Instanz von SQL Server 2005 hostet und Vorgehensweise: Umbenennen eines virtuellen SQL Server 2005-Servers.
  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 Publikationsdatenbank mit einer oder mehreren Abonnementdatenbanken. Das ermöglicht Ihnen das Uploaden jener Änderungen, die zuvor in der Publikationsdatenbank zwar vorgenommen, aber in der wiederhergestellten Sicherung nicht vorhanden sind. Welche Daten dabei geuploadet werden können, hängt davon ab, wie die Publikation gefiltert wird:
    • Wird die Publikation gar nicht gefiltert, sollten Sie die Publikationsdatenbank durch Synchronisieren mit einem aktuellen Abonnenten auf den neuesten Stand bringen.
    • Wenn die Publikation gefiltert ist, können Sie möglicherweise die Publikationsdatenbank nicht auf den aktuellen Stand bringen. Nehmen wir einmal an, es gibt eine Tabelle, die so partitioniert ist, dass jedes Abonnement nur die Kundendaten für eine der folgenden Verkaufsregionen erhält: Nord, Ost, Süd und West. Wenn für jede Datenpartition mindestens ein Abonnent vorhanden ist, würde es reichen, die Publikationsdatenbank 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 eines Abonnements.
      Wenn Sie die Publikationsdatenbank mit einem Abonnenten synchronisieren, auf dem eine frühere Version von SQL Server als SQL Server 2005 ausgeführt wird, kann das Abonnement nicht anonym sein – es muss sich um ein Clientabonnement oder ein Serverabonnement handeln (in früheren Versionen als lokales Abonnement bzw. globales Abonnement bezeichnet). Weitere Informationen finden Sie unter Synchronisieren von Daten.

Siehe auch

Konzepte

Replikation und Datenbankspiegelung

Andere Ressourcen

Implementieren der Replikation
Protokollversand

Hilfe und Informationen

Informationsquellen für SQL Server 2005