Replikation und Protokollversand
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 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 replizierter Datenbanken.
.gif "Hinweis") Hinweis |
|---|
Es wird empfohlen, anstelle des Protokollversands die Datenbankspiegelung zu verwenden, um die Verfügbarkeit der Veröffentlichungsdatenbank 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 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 Snapshot- und Transaktionsreplikation.
Konfigurieren der Transaktionsreplikation und des Protokollversands mit der "sync with backup"-Option
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).
Konfigurieren Sie den Protokollversand für die Veröffentlichungsdatenbank. Weitere Informationen finden Sie unter Bereitstellung des Protokollversands.
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).
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 zur Wiederherstellung der model- und msdb-Datenbanken 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 Veröffentlichungsdatenbank auf dem Primärserver konsistent sein.
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 hostet und Vorgehensweise: Umbenennen einer SQL Server-Failoverclusterinstanz.
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
Konfigurieren Sie den Protokollversand für die Veröffentlichungsdatenbank. Weitere Informationen finden Sie unter Bereitstellung des Protokollversands.
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).
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 zur Wiederherstellung der model- und msdb-Datenbanken 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 Veröffentlichungsdatenbank auf dem Primärserver konsistent sein.
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 hostet und Vorgehensweise: 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.
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).
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).
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).
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
Konfigurieren Sie den Protokollversand für die Veröffentlichungsdatenbank. Weitere Informationen finden Sie unter Bereitstellung des Protokollversands.
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).
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 zur Wiederherstellung der model- und msdb-Datenbanken 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 Veröffentlichungsdatenbank auf dem Primärserver konsistent sein.
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 hostet und Vorgehensweise: Umbenennen einer SQL Server-Failoverclusterinstanz.
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).
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, 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 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 eines Abonnements.
Wenn Sie die Veröffentlichungsdatenbank 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