Datenbankspiegelung und Replikation (SQL Server)

Gilt für:SQL Server

Die Datenbankspiegelung kann in Verbindung mit der Replikation verwendet werden, um die Verfügbarkeit der Veröffentlichungsdatenbank zu verbessern. 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. Updates, 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-, Update- oder Löschvorgang, der an der Prinzipaldatenbank vorgenommen wird, auf die Spiegeldatenbank angewandt.

Ein Replikationsfailover auf eine Spiegeldatenbank wird für Veröffentlichungsdatenbanken vollständig unterstützt, für Abonnementdatenbanken jedoch nur eingeschränkt. Die Datenbankspiegelung wird für die Verteilerdatenbank nicht unterstützt. Informationen zum Wiederherstellen einer Verteilungsdatenbank oder einer Abonnementdatenbank, ohne dass dazu die Replikation neu konfiguriert werden muss, finden Sie unter Sichern und Wiederherstellen von replizierten Datenbanken.

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.

• Die Replikation unterstützt das Spiegeln der Veröffentlichungsdatenbank bei der Mergereplikation und bei der Transaktionsreplikation mit schreibgeschützten Abonnenten oder Abonnenten mit Aktualisierung über Warteschlangen. Abonnenten mit sofortigem Update, Oracle-Verleger, Verleger in einer Peer-zu-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 und Objekte auf dem Spiegelserver benötigen, müssen Sie sie manuell kopieren. Weitere Informationen finden Sie unter Verwaltung von Anmeldenamen und Aufträgen nach einem Rollenwechsel (SQL Server).

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 Distributor wie die Prinzipaldatenbank verwendet.

4. Konfigurieren Sie die Replikations-Agenten für ein Failover.

5. Fügen Sie den Hauptserver und den Spiegelserver 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 Momentaufnahme- 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_replicationdboptionfür beide Typen auf demselben Knoten aktivieren. Zum Beispiel könnten Sie die folgenden Aufrufe gespeicherter Prozeduren auf dem Prinzipal 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 Einrichten einer Datenbankspiegelungssitzung mithilfe der Windows-Authentifizierung (SQL Server Management Studio) und unter Einrichten der Datenbankspiegelung (SQL Server).

3. Konfigurieren Sie die Verteilung für den Spiegel. Geben Sie den Namen der Spiegeldatenbank als Verleger an, und geben Sie denselben Verteiler- und Momentaufnahmeordner an, den auch die Prinzipaldatenbank verwendet. Wenn Sie beispielsweise eine Replikation mit gespeicherten Prozeduren konfigurieren, führen Sie auf dem Verteiler sp_adddistpublisher aus; führen Sie dann auf dem Spiegelserver sp_adddistributor aus. Für sp_adddistpublisher:

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

   • Legen Sie den Wert des @working_directory-Parameters auf den Snapshot-Ordner fest, den der Prinzipal verwendet.

4. Geben Sie den Spiegelnamen für den Agentparameter -PublisherFailoverPartner an. Agent Dieser Parameter ist für die folgenden Agenten erforderlich, um den Spiegel nach einem Failover zu identifizieren:

   • Snapshot-Agent (für alle Publikationen)

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

   • Warteschlangenlese-Agent (für Transaktionsveröffentlichungen, die Abonnments mit verzögertem Update über eine Warteschlange unterstützen)

   • Merge-Agent (für Merge-Abonnements)

   • SQL Server-Replikationslistener (replisapi.dll: für Mergeabonnements, die mithilfe der 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 kontinuierlich ausgeführt wird, müssen Sie den Agenten beenden und neu starten. Parameter können in Agentprofilen und in der Befehlszeile angegeben werden. Weitere Informationen finden Sie unter

   • Anzeigen und Ändern von Befehlszeilenparametern des Replikations-Agents (SQL Server Management Studio)

   • Ausführbare Konzepte für die Programmierung von Replikations-Agent

   Wir empfehlen, -PublisherFailoverPartner einem Agentprofil hinzuzufügen und dann den Spiegelnamen 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 den Hauptserver und den Spiegelserver zum Replikationsmonitor hinzu. Weitere Informationen finden Sie unter Publisher im Replikationsmonitor hinzufügen und entfernen.

Wartung einer gespiegelten Publikationsdatenbank

Die Wartung einer gespiegelten Publikationsdatenbank entspricht im Wesentlichen der Wartung einer nicht gespiegelten Datenbank, wobei Folgendes zu beachten ist:

• Die Verwaltung und Überwachung muss auf dem aktiven Server erfolgen. In SQL Server Management Studiowerden Veröffentlichungen nur für den aktiven Server im Ordner Lokale Veröffentlichungen angezeigt. Wenn z. B. ein Failover auf die Spiegeldatenbank erfolgt, werden die Veröffentlichungen bei der Spiegeldatenbank angezeigt und nicht mehr bei der Prinzipaldatenbank. 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 bei einem Agenten ein Fehler auftritt, wird dieser nur auf dem primären Knoten, nicht auf dem Spiegelknoten angezeigt.

  • Wenn der Prinzipalknoten nicht verfügbar ist, zeigen der Prinzipalknoten und die Spiegelknoten identische Listen von Veröffentlichungen an. Die Veröffentlichungen unter dem Spiegelknoten sollten überwacht werden.

• 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 ist bei Veröffentlichungsdatenbanken, die beim Prinzipal für die Replikation aktiviert sind, der in den Systemtabellen auf dem Spiegel gespeicherte Name der Publisher-Instanz der Name des Prinzipals und nicht der des Spiegels. 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_addmergepullsubscriptionnicht 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.

  Hinweis

  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 für die SQL Server-Datenbankspiegelung nicht relevant.

• So synchronisieren Sie ein Abonnement in Management Studio nach einem Failover: Synchronisieren Sie Pullabonnements vom Abonnenten und Pushabonnements vom aktiven Publisher.

Replikationsverhalten nach dem Entfernen der Spiegelung

Beachten Sie die folgenden Punkte, wenn die Datenbankspiegelung aus einer veröffentlichten Datenbank entfernt wird:

• Wenn die Veröffentlichungsdatenbank auf dem Prinzipal nicht mehr gespiegelt wird, funktioniert die Replikation unverändert mit dem ursprünglichen Prinzipal weiter.

• Wenn für die Veröffentlichungsdatenbank ein Failover von der primären Datenbank zur Spiegeldatenbank erfolgt und die Spiegelungsbeziehung anschließend deaktiviert oder entfernt wird, funktionieren die Replikations-Agenten nicht mit der Spiegeldatenbank. 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 Publikationsdatenbank noch intakt ist und weiterhin repliziert wird. Weitere Informationen zu KEEP_REPLICATION finden Sie unter RESTORE (Transact-SQL).

Verhalten des Protokolllese-Agents

Die folgende Tabelle beschreibt das Verhalten des Protokolllese-Agents für die verschiedenen Betriebsmodi der Datenbankspiegelung.

Siehe auch

SQL Server-Replikation
Protokollversand und Replikation (SQL Server)