Freigeben über

  • Artikel

Replikation und Datenbankspiegelung

Die Datenbankspiegelung kann in Verbindung mit der Replikation verwendet werden, um die Verfügbarkeit der Veröffentlichungsdatenbank zu gewährleisten. Bei der Datenbankspiegelung sind zwei Kopien einer einzigen Datenbank vorhanden, die normalerweise auf verschiedenen Computern gespeichert sind. Für die Clients ist immer nur eine Kopie der Datenbank verfügbar. Diese Kopie wird als Prinzipaldatenbank bezeichnet. Aktualisierungen, die Clients an der Prinzipaldatenbank vornehmen, werden in der anderen Kopie der Datenbank angewendet, die als Spiegeldatenbank bezeichnet wird. Beim Spiegeln wird das Transaktionsprotokoll von jedem Einfüge-, Aktualisierungs- oder Löschvorgang, der an der Prinzipaldatenbank vorgenommen wird, auf die Spiegeldatenbank angewandt.

Ein Failover der Replikation zu einer Spiegeldatenbank wird nur für Veröffentlichungsdatenbanken unterstützt und nicht für Verteilungs- oder Abonnementdatenbanken. Informationen zum Wiederherstellen einer Verteilungsdatenbank oder einer Abonnementdatenbank, ohne dass dazu die Replikation neu konfiguriert werden muss, finden Sie unter Sichern und Wiederherstellen replizierter Datenbanken.

HinweisHinweis

Nach einem Failover wird die Spiegeldatenbank zur Prinzipaldatenbank. In diesem Thema bezeichnen die Begriffe "Prinzipal" und "Spiegel" immer die ursprüngliche Prinzipal- bzw. Spiegeldatenbank.

Anforderungen und Überlegungen zur Verwendung von Replikation mit Datenbankspiegelung

Beachten Sie die folgenden Anforderungen und Überlegungen, wenn Sie die Replikation zusammen mit der Datenbankspiegelung verwenden wollen:

  • Die Prinzipal- und die Spiegeldatenbank müssen einen gemeinsamen Verteiler verwenden. Es wird empfohlen, dafür einen Remoteverteiler zu verwenden, der im Falle eines ungeplanten Failovers des Verlegers eine größere Fehlertoleranz aufweist.

  • Der Verleger und der Verteiler müssen beide MicrosoftSQL Server 2005 oder eine spätere Version haben. Die Abonnenten können eine beliebige Version haben, Mergereplikations-Pullabonnements aus einer Version vor SQL Server 2005 unterstützen jedoch kein Failover. Der Agent wird in diesem Fall auf dem Abonnenten ausgeführt, und frühere Versionen des Agents sind nicht spiegelungsabhängig. Die Replikation zu solchen Teilnehmern wird fortgesetzt, wenn ein Failback der Datenbank von der Spiegel- zur Prinzipaldatenbank erfolgt.

  • Die Replikation unterstützt das Spiegeln der Veröffentlichungsdatenbank zur Mergereplikation und zur Transaktionsreplikation mit schreibgeschützten Abonnenten oder Abonnenten mit verzögerter Aktualisierung über eine Warteschlange. Sofort aktualisierbare Abonnenten, Oracle-Verleger, Verleger in einer Peer-to-Peer-Topologie und das erneute Veröffentlichen werden nicht unterstützt.

  • Metadaten und Objekte, die außerhalb der Datenbank vorhanden sind, werden nicht in die Spiegeldatenbank kopiert. Das betrifft Benutzernamen, Aufträge, Verbindungsserver usw. Wenn Sie die Metadaten in der Spiegeldatenbank benötigen, müssen Sie diese manuell kopieren. Weitere Informationen finden Sie unter Verwalten von Anmeldungen und Anmeldeaufträgen nach einem Rollenwechsel.

Konfigurieren der Replikation mit Datenbankspiegelung

Das Konfigurieren der Replikation mit Datenbankspiegelung umfasst fünf Schritte. Jeder dieser Schritte wird im folgenden Abschnitt detailliert beschrieben.

  1. Konfigurieren Sie den Verleger.

  2. Konfigurieren Sie die Datenbankspiegelung.

  3. Konfigurieren Sie die Spiegeldatenbank so, dass sie denselben Verteiler wie die Prinzipaldatenbank verwendet.

  4. Konfigurieren Sie den Replikations-Agent für das Failover.

  5. Fügen Sie die Prinzipal- und die Spiegeldatenbank zum Replikationsmonitor hinzu.

Schritt 1 und 2 können auch in umgekehrter Reihenfolge durchgeführt werden.

So konfigurieren Sie die Datenbankspiegelung für eine Veröffentlichungsdatenbank

  1. Konfigurieren Sie den Verleger:

    1. Die Verwendung eines Remoteverteilers wird empfohlen. Weitere Informationen zum Konfigurieren der Verteilung finden Sie unter Konfigurieren der Verteilung.

    2. Sie können eine Datenbank für die Snapshot- und Transaktionsveröffentlichungen und/oder für Mergeveröffentlichungen aktivieren. Bei gespiegelten Datenbanken, die mehrere Veröffentlichungstypen enthalten, müssen Sie die Datenbanken mit sp_replicationdboption für beide Typen auf demselben Knoten aktivieren. Beispielsweise können Sie die folgenden gespeicherten Prozeduraufrufe für die Prinzipaldatenbank ausführen:

      exec sp_replicationdboption @dbname='<PublicationDatabase>', @optname='publish', @value=true
exec sp_replicationdboption @dbname='<PublicationDatabase>', @optname='mergepublish', @value=true

      Weitere Informationen zum Erstellen von Veröffentlichungen finden Sie unter Veröffentlichen von Daten und Datenbankobjekten.

  2. Konfigurieren Sie die Datenbankspiegelung. Weitere Informationen finden Sie unter Vorgehensweise: Konfigurieren einer Datenbank-Spiegelungssitzung (SQL Server Management Studio) und Einrichten der Datenbankspiegelung.

  3. Konfigurieren Sie die Verteilung für die Spiegeldatenbank. Geben Sie den Namen der Spiegeldatenbank als Verleger an, und geben Sie denselben Verteiler- und Snapshotordner an, den auch die Prinzipaldatenbank verwendet. Wenn Sie z. B. eine Replikation mit gespeicherten Prozeduren konfigurieren, führen Sie auf dem Verteiler sp_adddistpublisher aus. Führen Sie anschließend auf der Spiegeldatenbank sp_adddistributor aus. Für sp_adddistpublisher:

    • Setzen Sie den Wert des @publisher-Parameters auf den Netzwerknamen der Spiegeldatenbank.

    • Setzen Sie den Wert des @working_directory-Parameters auf den Snapshotordner, der von der Prinzipaldatenbank verwendet wird.

  4. Geben Sie den Spiegeldatenbanknamen für den –PublisherFailoverPartner-Parameter des Agents an. Dieser Parameter ist für die folgenden Agents erforderlich, um die Spiegeldatenbank nach einem Failover zu identifizieren:

    • Snapshot-Agent (für alle Veröffentlichungen)

    • Protokolllese-Agent (für alle Transaktionsveröffentlichungen)

    • Warteschlangenlese-Agent (für Transaktionsveröffentlichungen mit verzögerter Aktualisierung von Abonnements)

    • Merge-Agent (für Mergeabonnements)

    • SQL Server-Replikationsüberwachung (replisapi.dll: für Mergeabonnements, die per Websynchronisierung synchronisiert werden)

    • SQL Merge-ActiveX-Steuerelement (für Mergeabonnements, die über dieses Steuerelement synchronisiert werden)

    Der Verteilungs-Agent und das Verteilungs-ActiveX-Steuerelement weisen diesen Parameter nicht auf, weil sie keine Verbindung mit dem Verleger herstellen.

    Die Änderungen der Agentparameter treten in Kraft, wenn der Agent das nächste Mal gestartet wird. Wenn der Agent ständig ausgeführt wird, müssen Sie den Agent beenden und neu starten. Parameter können in Agentprofilen und in der Befehlszeile angegeben werden. Weitere Informationen finden Sie unter:

    Es wird empfohlen, zunächst den –PublisherFailoverPartner-Parameter zu einem Agentprofil hinzuzufügen und anschließend den Spiegeldatenbanknamen im Profil anzugeben. Wenn Sie z. B. die Replikation mit gespeicherten Prozeduren konfigurieren:

    -- Execute sp_help_agent_profile in the context of the distribution database to get the list of profiles.
-- Select the profile id of the profile that needs to be updated from the result set.
-- In the agent_type column returned by sp_help_agent_profile: 
-- 1 = Snapshot Agent; 2 = Log Reader Agent; 3 = Distribution Agent; 4 = Merge Agent; 9 = Queue Reader Agent.

exec sp_help_agent_profile

-- Setting the -PublisherFailoverPartner parameter in the default Snapshot Agent profile (profile 1).
-- Execute sp_add_agent_parameter in the context of the distribution database.
exec sp_add_agent_parameter @profile_id = 1, @parameter_name = N'-PublisherFailoverPartner', @parameter_value = N'<Failover Partner Name>'

-- Setting the -PublisherFailoverPartner parameter in the default Merge Agent profile (profile 6).
-- Execute sp_add_agent_parameter in the context of the distribution database.
exec sp_add_agent_parameter @profile_id = 6, @parameter_name = N'-PublisherFailoverPartner', @parameter_value = N'<Failover Partner Name>'

  5. Fügen Sie die Prinzipal- und die Spiegeldatenbank zum Replikationsmonitor hinzu. Weitere Informationen finden Sie unter Vorgehensweise: Hinzufügen und Entfernen von Verlegern vom Replikationsmonitor aus (Replikationsmonitor).

Warten einer gespiegelten Veröffentlichungsdatenbank

Das Warten einer gespiegelten Veröffentlichungsdatenbank gleicht im Wesentlichen dem Warten einer nicht gespiegelten Datenbank, wobei jedoch die folgenden Überlegungen zu berücksichtigen sind:

  • Die Verwaltung und Überwachung muss auf dem aktiven Server erfolgen. In SQL Server Management Studio werden Veröffentlichungen nur für den aktiven Server im Ordner Lokale Veröffentlichungen angezeigt. Wenn z. B. ein Failover zur Spiegeldatenbank erfolgt ist, werden die Veröffentlichungen für die Spiegeldatenbank und nicht mehr für die Prinzipaldatenbank angezeigt. Wenn ein Failover der Datenbank zur Spiegeldatenbank erfolgt, müssen Management Studio und der Replikationsmonitor ggf. manuell aktualisiert werden, damit die Änderung berücksichtigt wird.

  • Der Replikationsmonitor zeigt Verlegerknoten in der Objektstruktur für die Prinzipaldatenbank und die Spiegeldatenbank an. Wenn der Prinzipalserver der aktive Server ist, werden die Veröffentlichungsinformationen nur unter dem Prinzipalknoten im Replikationsmonitor angezeigt.

    Wenn der Spiegelserver der aktive Server ist, geschieht Folgendes:

    • Wenn in einem Agent ein Fehler auftritt, wird der Fehler nur im Prinzipalknoten und nicht im Spiegelknoten angegeben.

    • Wenn der Prinzipalserver nicht verfügbar ist, werden für den Prinzipal- und den Spiegelknoten identische Listen von Veröffentlichungen angezeigt. Die Überwachung sollte für die Veröffentlichungen unter dem Spiegelknoten erfolgen.

  • Beim Verwenden gespeicherter Prozeduren oder Replikationsverwaltungsobjekte (RMO, Replication Management Objects) zum Verwalten der Replikation in der Spiegeldatenbank müssen Sie in Fällen, in denen Sie den Verlegernamen angeben, den Namen der Instanz angeben, auf der die Datenbank für die Replikation aktiviert wurde. Den entsprechenden Namen ermitteln Sie mithilfe der publishingservername-Funktion.

    Wenn eine Veröffentlichungsdatenbank gespiegelt wird, sind die in der gespiegelten Datenbank gespeicherten Replikationsmetadaten identisch mit den Metadaten, die in der Prinzipaldatenbank gespeichert sind. Demzufolge entspricht für Veröffentlichungsdatenbanken, die in der Prinzipaldatenbank zur Replikation aktiviert wurden, der in den Systemtabellen gespeicherte Verlegerinstanzname dem Namen der Prinzipaldatenbank und nicht dem Namen der Spiegeldatenbank. Dies wirkt sich auf die Replikationskonfiguration und -wartung aus, wenn ein Failover der Veröffentlichungsdatenbank zur Spiegeldatenbank erfolgt. Wenn Sie z. B. nach einem Failover zur Spiegeldatenbank die Replikation mit gespeicherten Prozeduren konfigurieren und ein Pullabonnement für eine Veröffentlichungsdatenbank hinzufügen wollen, die in der Prinzipaldatenbank aktiviert wurde, müssen Sie für den @publisher-Parameter von sp_addpullsubscription oder sp_addmergepullsubscription nicht den Spiegeldatenbanknamen, sondern den Prinzipaldatenbanknamen angeben.

    Wenn Sie nach einem Failover zur Spiegeldatenbank eine Veröffentlichungsdatenbank in der Spiegeldatenbank aktivieren, entspricht der Verlegerinstanzname in den Systemtabellen dem Namen der Spiegeldatenbank. In diesem Fall würden Sie den Namen der Spiegeldatenbank für den @publisher-Parameter verwenden.

    HinweisHinweis

    In einigen Fällen, z. B. bei sp_addpublication, wird der @publisher-Parameter nur für Nicht-SQL Server-Verleger unterstützt. In diesen Fällen ist er nicht relevant für die SQL Server-Datenbankspiegelung.

  • Synchronisieren Sie die Pullabonnements vom Abonnenten und die Pushabonnements vom aktiven Verleger, um ein Abonnement in Management Studio nach einem Failover zu synchronisieren.

Replikationsverhalten nach dem Entfernen der Spiegelung

Beachten Sie beim Entfernen der Spiegelung von einer veröffentlichten Datenbank Folgendes:

  • Wenn die Spiegelung der Veröffentlichungsdatenbank in der Prinzipaldatenbank deaktiviert wird, ist die Replikation unverändert für die ursprüngliche Prinzipaldatenbank funktionsfähig.

  • Wenn ein Failover der Veröffentlichungsdatenbank von der Prinzipaldatenbank zur Spiegeldatenbank erfolgt und anschließend die Spiegelungsbeziehung deaktiviert oder entfernt wird, sind die Replikations-Agents nicht für die Spiegeldatenbank funktionsfähig. Wenn die Prinzipaldatenbank dauerhaft verloren geht, deaktivieren Sie die Replikation, und konfigurieren Sie sie anschließend neu, wobei Sie die Spiegeldatenbank als Verleger angeben.

  • Wenn die Datenbankspiegelung vollständig entfernt wird, befindet sich die Spiegeldatenbank in einem Wiederherstellungsstatus und muss wiederhergestellt werden, um funktionsfähig zu werden. Das Verhalten der wiederhergestellten Datenbank im Hinblick auf die Replikation richtet sich danach, ob die KEEP_REPLICATION-Option angegeben wurde. Diese Option weist den Wiederherstellungsvorgang an, die Replikationseinstellungen beizubehalten, wenn eine veröffentlichte Datenbank auf einem Server wiederhergestellt wird, der nicht mit dem Server identisch ist, auf dem die Datenbank erstellt wurde. Verwenden Sie die KEEP_REPLICATION-Option nur dann, wenn die andere Veröffentlichungsdatenbank nicht verfügbar ist. Die Option wird nicht unterstützt, wenn die andere Veröffentlichungsdatenbank noch intakt ist und weiter repliziert. Weitere Informationen zu KEEP_REPLICATION finden Sie unter RESTORE-Argumente (Transact-SQL).

Verhalten des Protokolllese-Agents

Die folgende Tabelle beschreibt das Verhalten des Protokolllese-Agents für die verschiedenen Betriebsmodi der Datenbankspiegelung. Weitere Informationen zu den Betriebsmodi finden Sie unter Transact-SQL-Einstellungen und Datenbankspiegelungs-Betriebsmodi.

Betriebsmodus

Verhalten des Protokolllese-Agents, wenn die Spiegeldatenbank nicht verfügbar ist

Modus für hohe Sicherheit mit automatischem Failover

Wenn die Spiegeldatenbank nicht verfügbar ist, gibt der Protokolllese-Agent die Befehle an die Verteilungsdatenbank weiter. Ein Failover der Prinzipaldatenbank zur Spiegeldatenbank ist solange nicht möglich, bis die Spiegeldatenbank wieder online ist und alle Transaktionen von der Prinzipaldatenbank erhalten hat.

Modus mit hoher Leistung

Wenn die Spiegeldatenbank nicht verfügbar ist, läuft sie ungeschützt (das heißt, sie wird nicht gespiegelt). Der Protokolllese-Agent repliziert jedoch nur solche Transaktionen, die in der Spiegeldatenbank festgeschrieben wurden. Wenn der Dienst erzwungen wird und der Spiegelserver die Rolle der Prinzipaldatenbank übernimmt, arbeitet der Protokolllese-Agent für die Spiegeldatenbank und beginnt mit dem Übernehmen der neuen Transaktionen. Weitere Informationen finden Sie unter Erzwungener Dienst (mit möglichem Datenverlust).

Beachten Sie, dass die Replikationslatenzzeit steigt, wenn die Spiegeldatenbank hinter die Prinzipaldatenbank zurückfällt.

Modus für hohe Sicherheit ohne automatisches Failover

Für alle Transaktionen, für die ein Commit ausgeführt wird, wird sichergestellt, dass sie auf dem Datenträger in der Spiegeldatenbank festgeschrieben werden. Der Protokolllese-Agent repliziert jedoch nur solche Transaktionen, die in der Spiegeldatenbank festgeschrieben wurden. Wenn die Spiegeldatenbank nicht verfügbar ist, deaktiviert die Prinzipaldatenbank jede weitere Aktivität in der Datenbank, weshalb der Protokolllese-Agent keine Transaktionen replizieren muss.