Warten einer AlwaysOn-Veröffentlichungsdatenbank (SQL Server)

In diesem Thema werden besondere Überlegungen zum Verwalten einer Veröffentlichungsdatenbank bei Verwendung von AlwaysOn-Verfügbarkeitsgruppen erläutert.

In diesem Thema:

• Verwalten einer veröffentlichten Datenbank in einer Verfügbarkeitsgruppe

• Entfernen einer veröffentlichten Datenbank aus einer Verfügbarkeitsgruppe

• Verwandte Aufgaben

Verwalten einer veröffentlichten Datenbank in einer Verfügbarkeitsgruppe

Die Wartung einer AlwaysOn-Veröffentlichungsdatenbank entspricht im Wesentlichen der Wartung einer standardmäßigen Veröffentlichungsdatenbank, wobei jedoch die folgenden Überlegungen zu berücksichtigen sind:

• Die Verwaltung muss beim primären Replikathost erfolgen. In SQL Server Management Studio werden Veröffentlichungen unter dem Ordner Lokale Veröffentlichungen für den primären Replikathost und auch für lesbare sekundäre Replikate angezeigt. Nach einem Failover müssen Sie unter Umständen Management Studio manuell aktualisieren, um die Änderung widerzuspiegeln, wenn das sekundäre Replikat, das zum primären Replikat höher gestuft wurde, nicht lesbar war.

• Der Replikationsmonitor zeigt immer Veröffentlichungsinformationen unter dem ursprünglichen Verleger an. Diese Informationen können jedoch von einem beliebigen Replikat aus im Replikationsmonitor angezeigt werden, indem der ursprüngliche Verleger als Server hinzugefügt wird.

• Bei Verwendung von gespeicherten Prozeduren oder Replikationsverwaltungsobjekten (RMO, Replication Management Objects) zum Verwalten der Replikation im primären Replikat 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 einer Verfügbarkeitsgruppe beitritt, sind die in den sekundären Datenbankreplikaten gespeicherten Replikationsmetadaten mit denen im primären Replikat identisch. Demzufolge entspricht für Veröffentlichungsdatenbanken, die in der primären Replikatdatenbank zur Replikation aktiviert wurden, der in den Systemtabellen des sekundären Replikats gespeicherte Verlegerinstanzname dem Namen der primären Replikatdatenbank und nicht dem Namen der sekundären Replikatdatenbank. Dies wirkt sich auf die Replikationskonfiguration und -wartung aus, wenn ein Failover der Veröffentlichungsdatenbank zur sekundären Replikatdatenbank erfolgt. Wenn Sie z. B. die Replikation mit gespeicherten Prozeduren bei einem sekundären Replikat nach einem Failover konfigurieren und Sie ein Pullabonnement für eine Veröffentlichungsdatenbank möchten, die bei einem anderen Replikat aktiviert wurde, müssen Sie den Namen des ursprünglichen Verlegers statt des aktuellen Verlegers als @publisher-Parameter von sp_addpullsubscription oder sp_addmergepulllsubscription angeben. Wenn Sie jedoch eine Veröffentlichungsdatenbank nach einem Failover aktivieren, entspricht der in den Systemtabellen gespeicherte Verlegerinstanzname dem Namen des aktuellen primären Hosts. In diesem Fall würden Sie den Hostnamen des aktuellen primären Replikats für den @publisher-Parameter verwenden.

  Hinweis
  Bei einigen Prozeduren, z. B. sp_addpublication, wird der @publisher-Parameter nur für Verleger unterstützt, die keine Instanzen von SQL Server sind. In diesen Fällen ist er für SQL Server-AlwaysOn nicht relevant.

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

[Nach oben]

Entfernen einer veröffentlichten Datenbank aus einer Verfügbarkeitsgruppe

Berücksichtigen Sie die folgenden Probleme, wenn eine veröffentlichte Datenbank aus einer Verfügbarkeitsgruppe entfernt wird, oder wenn eine Verfügbarkeitsgruppe, die eine veröffentlichte Elementdatenbank aufweist, gelöscht wird.

• Wenn die Veröffentlichungsdatenbank beim ursprünglichen Verleger aus einem primären Replikat der Verfügbarkeitsgruppe entfernt wird, müssen Sie sp_redirect_publisher ausführen, ohne einen Wert für den @redirected\_publisher-Parameter anzugeben, um die Umleitung für das Verleger-/Datenbankpaar zu entfernen.

  EXEC sys.sp_redirect_publisher 
      @original_publisher = 'MyPublisher',
      @published_database = 'MyPublishedDB';
  

  Die Datenbank wird auf dem primären Replikat im Wiederherstellungsstatus belassen und muss wiederhergestellt werden. Sobald Sie dies tun, sollte die Replikation unverändert mit dem ursprünglichen Verleger funktionieren.

• Wenn für die Veröffentlichungsdatenbank ein Failover vom ursprünglichen Verleger zu einem Replikat ausgeführt und die Datenbank aus dem primären Replikat der Verfügbarkeitsgruppe entfernt wird, führen Sie die gespeicherte Prozedur sp_redirect_publisher aus, um den ursprünglichen Verleger zum neuen Verleger umzuleiten. Die Datenbank wird im Wiederherstellungsstatus belassen und muss wiederhergestellt werden. Sobald Sie dies tun, sollte die Replikation weiterhin so funktionieren wie zuvor in der Verfügbarkeitsgruppe.

  EXEC sys.sp_redirect_publisher 
      @original_publisher = 'MyPublisher',
      @published_database = 'MyPublishedDB',
      @redirected_publisher = 'MyNewPublisher';
  

  Entfernen Sie den Remoteserver für den ursprünglichen Verleger selbst dann nicht aus dem Verteiler, wenn nicht mehr auf den Server zugegriffen werden kann. Die Servermetadaten für den ursprünglichen Verleger werden beim Verteiler benötigt, um Abfragen von Veröffentlichungsmetadaten beantworten zu können

• Wenn eine vollständige Verfügbarkeitsgruppe entfernt wird, wirkt sich dies auf eine replizierte Mitgliedsdatenbank auf die gleiche Weise aus, wie das Entfernen einer veröffentlichten Datenbank aus einer Verfügbarkeitsgruppe. Die Replikation kann vom letzten primären Replikat fortgesetzt werden, sobald die Datenbank wiederhergestellt und die Umleitung geändert wurde. Wenn die Datenbank auf ihrem ursprünglichen Verleger wiederhergestellt wird, sollte die Umleitung entfernt werden. Wenn die Datenbank bei einem anderen Host wiederhergestellt wird, sollte Umleitung explizit an den neuen Host umgeleitet werden.

  Hinweis

  Wenn eine Verfügbarkeitsgruppe entfernt wird, die über veröffentlichte Mitgliedsdatenbanken verfügt, oder wenn eine veröffentlichte Datenbank aus einer Verfügbarkeitsgruppe entfernt wird, werden alle Kopien der veröffentlichten Datenbanken im Wiederherstellungsstatus belassen. Nach der Wiederherstellung wird jede Datenbank als veröffentlichte Datenbank angezeigt. Nur eine Kopie sollte mit Veröffentlichungsmetadaten beibehalten werden. Um die Replikation für eine veröffentlichte Datenbankkopie zu deaktivieren, entfernen Sie zuerst alle Abonnements und Veröffentlichungen aus der Datenbank.

  Führen Sie sp_dropsubscription aus, um die Veröffentlichungsabonnements zu entfernen. Vergessen Sie nicht, den Parameter @ignore\_distributributor auf 1 festzulegen, um die Metadaten beim Verteiler für die aktive Veröffentlichungsdatenbank beizubehalten.

  USE MyDBName;
  GO
  
  EXEC sys.sp_dropsubscription 
      @subscriber = 'MySubscriber',
      @publication = 'MyPublication',
      @article = 'all',
      @ignore_distributor = 1;
  

  Führen Sie sp_droppublication aus, um alle Veröffentlichungen zu entfernen. Auch hier dürfen Sie nicht vergessen, den Parameter @ignore\_distributor auf 1 festzulegen, um die Metadaten beim Verteiler für die aktive Veröffentlichungsdatenbank beizubehalten.

  EXEC sys.sp_droppublication 
      @publication = 'MyPublication',
      @ignore_distributor = 1;
  

  Führen Sie sp_replicationdboption aus, um die Replikation für die Datenbank zu deaktivieren.

  EXEC sys.sp_replicationdboption
      @dbname = 'MyDBName',
      @optname = 'publish',
      @value = 'false';
  

  An diesem Punkt kann die Kopie der veröffentlichten Datenbank beibehalten oder gelöscht werden.

[Nach oben]

Verwandte Aufgaben

• Konfigurieren der Replikation für AlwaysOn-Verfügbarkeitsgruppen (SQL Server)

• Replikation, Änderungsnachverfolgung, Change Data Capture und AlwaysOn-Verfügbarkeitsgruppen (SQL Server)

• Verwaltung (Replikation)

• Replikationsabonnenten und AlwaysOn-Verfügbarkeitsgruppen (SQL Server)

[Nach oben]

Siehe auch

Konzepte

Voraussetzungen, Einschränkungen und Empfehlungen für AlwaysOn-Verfügbarkeitsgruppen (SQL Server)

Übersicht über AlwaysOn-Verfügbarkeitsgruppen (SQL Server)

AlwaysOn-Verfügbarkeitsgruppen: Interoperabilität (SQL Server)

SQL Server-Replikation