Upgraden oder Patchen replizierter Datenbanken

Gilt für: SQL Server - nur Windows

SQL Server unterstützt das Aktualisieren replizierter Datenbanken von früheren Versionen von SQL Server. Während der Aktualisierung eines Knotens müssen die auf anderen Knoten ausgeführten Aktivitäten nicht beendet werden. Stellen Sie sicher, dass die Regeln, die im Hinblick auf die in einer Topologie unterstützten Versionen gelten, eingehalten werden:

• Für den Verteiler ist jede Version zulässig, die der Verleger-Version entspricht oder höher als diese ist. (In vielen Fällen gehören Verteiler und Verleger derselben Instanz an.)
• Für den Verleger ist jede Version zulässig, die der Verteiler-Version entspricht oder niedriger als diese ist.
• Die Abonnenten-Version ist vom Veröffentlichungstyp abhängig:
  • Ein Abonnent einer Transaktionsveröffentlichung kann einer der beiden Versionen im Rahmen der Verlegerversion angehören. Zum Beispiel: Ein SQL Server 2012-Verleger (11.x) kann SQL Server 2014-Abonnenten (12.x) und SQL Server 2016-Abonnenten (13.x) vorweisen. Ein SQL Server 2016-Verleger (13.x) kann SQL Server 2014-Abonnenten (12.x) und SQL Server 2012-Abonnenten (11.x) vorweisen.
  • Ein Abonnent für eine Mergeveröffentlichung kann alle Versionen, die gleich oder niedriger sind als die Verlegerversion, benutzen. Diese werden gemäß dem Supportzeitraums für den Versionenlebenszyklus unterstützt.

Der Upgradepfad für SQL Server unterscheidet sich je nach Bereitstellungsmuster. Grundsätzlich stehen zwei Upgradepfade für SQL Server zur Verfügung:

• Parallel: Stellen Sie eine parallele Umgebung bereit, und verschieben Sie Datenbanken gemeinsam mit den zugehörigen Objekten auf Instanzebene, z.B. Anmeldenamen, Aufträge usw., in die neue Umgebung.
• Direktes Upgrade: Führen Sie das Upgrade der vorhandenen SQL Server-Installation mithilfe des SQL Server-Installationsmediums durch. Dazu werden die SQL Server-Bits ersetzt und die Datenbankobjekte aktualisiert. Für Umgebungen, in denen Always On-Verfügbarkeitsgruppen oder Failoverclusterinstanzen ausgeführt werden, werden direkte Upgrades mit einem parallelen Upgrade kombiniert, um die Downtime zu minimieren.

Das Verschieben von Verleger-Abonnenten-Paaren in Teilen in die neue parallele Umgebung wurde anstelle der Verschiebung der gesamten Topologie als gängige Methode für parallele Upgrades für Replikationstopologien eingeführt. Mithilfe eines solchen inkrementellen Ansatzes lässt sich die Downtime steuern, und die Auswirkungen auf das Unternehmen, das auf die Replikation angewiesen ist, lassen sich zumindest bis zu einem gewissen Grad minimieren.

Der Großteil dieses Artikels bezieht sich auf das Upgrade der SQL Server-Version. Die Vorgehensweise für direktes Upgrade sollte aber auch beim Patchen von SQL Server mit einem Service Pack oder kumulativen Update verwendet werden.

Replikationsmatrix

Kompatibilitätsmatrix für Transaktions- und Momentaufnahmereplikation

Kompatibilitätsmatrix für die Mergereplikation

Führen Sie den Protokolllese-Agent für die Transaktionsreplikation vor dem Upgrade aus.

Bevor Sie SQL Serveraktualisieren, müssen Sie sich vergewissern, dass alle Transaktionen mit ausgeführtem Commit von veröffentlichten Tabellen vom Protokolllese-Agent verarbeitet wurden. Um sicherzustellen, dass alle Transaktionen verarbeitet wurden, führen Sie die folgenden Schritte für jede Datenbank aus, die Transaktionsveröffentlichungen enthält:

1. Stellen Sie sicher, dass der Protokolllese-Agent für die Datenbank ausgeführt wird. Standardmäßig wird der Agent ununterbrochen ausgeführt.
2. Beenden Sie die Benutzeraktivität auf veröffentlichten Tabellen.
3. Warten Sie eine gewissen Zeit, bis der Protokolllese-Agent die Transaktionen in die Verteilungsdatenbank kopiert hat, und beenden Sie dann den Agent.
4. Führen Sie sp_replcmds aus, um zu überprüfen, ob alle Transaktionen verarbeitet wurden. Das Resultset dieser Prozedur sollte leer sein.
5. Führen Sie sp_replflush aus, um die Verbindung von „sp_replcmds“ zu trennen.
6. Führen Sie das Serverupgrade auf die neueste Version von SQL Server durch.
7. Starten Sie den SQL Server -Agent und den Protokolllese-Agent neu, wenn sie nach dem Upgrade nicht automatisch starten.

Ausführen von Agents nach dem Upgrade für die Mergereplikation

Führen Sie nach dem Upgrade für jede Mergeveröffentlichung den Momentaufnahme-Agent und für jedes Abonnement den Merge-Agent aus, um die Replikationsmetadaten zu aktualisieren. Sie müssen die neue Momentaufnahme nicht anwenden, da sie für die erneute Initialisierung der Abonnements nicht benötigt wird. Die Metadaten des Abonnements werden aktualisiert, sobald der Merge-Agent zum ersten Mal nach dem Upgrade ausgeführt wird. Dies bedeutet, dass die Abonnementdatenbank während des Upgrades des Verlegers online und aktiv bleiben kann.

Die Mergereplikation speichert die Metadaten der Veröffentlichung und des Abonnements in einer Reihe von Systemtabellen in den Veröffentlichungs- und Abonnement-Datenbanken. Bei Ausführung des s werden die Veröffentlichungsmetadaten aktualisiert, und bei Ausführung des Merge-Agents werden die Abonnementmetadaten aktualisiert. Der Agent wird nur benötigt, um eine Momentaufnahme der Veröffentlichung zu generieren. Wenn bei einer Mergeveröffentlichung parametrisierte Filter verwendet werden, gibt es auch für jede Partition eine Momentaufnahme. Diese partitionierten Momentaufnahmen zu aktualisieren, ist nicht erforderlich.

Die Agents werden in SQL Server Management Studio, im Replikationsmonitor oder in der Befehlszeile ausgeführt. Weitere Informationen zum Ausführen des Momentaufnahme-Agents finden Sie in den folgenden Artikeln:

• Erstellen und Anwenden der Anfangsmomentaufnahme
• Starten und Beenden eines Replikations-Agents (SQL Server Management Studio)
• Erstellen und Anwenden der Anfangsmomentaufnahme
• Ausführbare Konzepte für die Programmierung von Replikations-Agent

Weitere Informationen zum Ausführen des Merge-Agents finden Sie in den folgenden Artikeln:

• Synchronisieren eines Pullabonnements
• Synchronisieren eines Pushabonnements

Nach dem Upgrade von SQL Server in einer Topologie, in der die Mergereplikation verwendet wird, müssen Sie den Kompatibilitätsgrad aller Veröffentlichungen ändern, um neue Funktionen verwenden zu können.

Aktualisieren auf die Standard Edition, Workgroup Edition oder Express Edition

Bevor eine Edition von SQL Server auf eine andere Edition aktualisiert wird, sollten Sie überprüfen, ob die derzeit verwendete Funktionalität in der Edition, die Ziel des Upgrades ist, unterstützt wird. Weitere Informationen finden Sie im Abschnitt zur Replikation im Thema Editionen und unterstützte Funktionen von SQL Server 2022.

Schritte für das Upgrade einer Replikationstopologie

In diesen Schritten wird die Reihenfolge dargestellt, in der Upgrades für Replikationstopologien durchgeführt werden sollten. Dieselben Schritte gelten sowohl für die Transaktions- als auch für die Mergereplikation. Diese Schritte gelten jedoch nicht für Peer-zu-Peer-Replikation, Abonnements mit verzögertem Update über eine Warteschlange und Abonnements mit sofortigem Update.

Direktes Upgrade

1. Aktualisieren Sie den Verteiler.
2. Aktualisieren Sie den Verleger und den Abonnenten. Diese Upgrades können Sie in beliebiger Reihenfolge durchführen.

Paralleles Upgrade

1. Aktualisieren Sie den Verteiler.
2. Konfigurieren Sie die Verteilung in der neuen SQL Server-Instanz neu.
3. Aktualisieren Sie den Verleger.
4. Aktualisieren Sie den Abonnenten.
5. Konfigurieren Sie alle Verleger-Abonnenten-Paare, einschließlich der erneuten Initialisierung des Abonnenten, neu.

Schritte für die parallele Migration des Verteilers zu Windows Server 2012 R2

Wenn Sie ein Upgrade Ihrer SQL Server-Instanz auf SQL Server 2016 (oder höher) planen und Ihr aktuelles Betriebssystem Windows Server 2008 (oder 2008 R2) ist, müssen Sie für das Betriebssystem ein paralleles Upgrade auf Windows Server 2012 R2 oder höher ausführen. Der Grund für dieses zwischengeschaltete Betriebssystemupgrade ist, dass SQL Server 2016 nicht auf einem Server mit Windows Server 2008/2008 R2 installiert werden kann und für Windows Server 2008/2008 R2 kein direktes Upgrade auf Windows Server 2016 möglich ist. Obwohl ein direktes Upgrade von Windows Server 2008/2008 R2 auf Windows Server 2012 und anschließend auf Windows Server 2016 möglich ist, wird dies aufgrund der Ausfallzeit und der höheren Komplexität, die einen einfachen Rollbackpfad verhindern, generell nicht empfohlen. Ein paralleles Upgrade ist der einzige Upgradepfad, der für zu einem Failovercluster gehörige SQL Server-Instanzen verfügbar ist. Die folgenden Schritte können Sie sowohl in einer eigenständigen SQL Server-Instanz als auch innerhalb einer Always On-Failoverclusterinstanz (FCI) ausführen.

1. Richten Sie eine neue SQL Server-Instanz (entweder eigenständig oder in einem Always On-Failovercluster) mit der gleichen Edition und Version des Windows Server 2012 R2/2016-Verteilers und einem anderen Windows-Cluster sowie SQL Server-FCI-Namen bzw. eigenständigen Hostnamen. Führen Sie keine Änderungen an der Verzeichnisstruktur durch, um sicherzustellen, dass sich die ausführbaren Replikations-Agents, Replikationsordner und Datenbankdateipfade in der neuen Umgebung im gleichen Pfad befinden. Damit werden die erforderlichen Schritte nach der Migration bzw. dem Upgrade reduziert.
2. Stellen Sie sicher, dass Ihre Replikation synchronisiert ist, und beenden Sie dann alle Replikations-Agents.
3. Beenden Sie die aktuelle SQL Server-Verteilerinstanz. Wenn es sich dabei um eine eigenständige Instanz handelt, fahren Sie den Server herunter. Wenn es sich um eine SQL Server-FCI handelt, stellen Sie die gesamte SQL Server-Rolle und den Netzwerknamen im Cluster-Manager offline.
4. Entfernen Sie die Einträge für die DNS- und AD-Computerobjekte für die alte Umgebung (aktuelle Verteilerinstanz).
5. Ändern Sie den Hostnamen des neuen Servers in den des alten Servers.
   1. Wenn es sich dabei um eine SQL Server-FCI handelt, geben Sie der neuen SQL Server-FCI den gleichen virtuellen Servernamen wie der alten Instanz.
6. Kopieren Sie die Datenbankdateien aus der vorherigen Instanz mithilfe einer SAN-Umleitung, Speicherkopie oder Dateikopie.
7. Stellen Sie die neue SQL Server-Instanz online.
8. Starten Sie alle Replikations-Agents neu, und überprüfen Sie, ob die Agents erfolgreich ausgeführt werden.
9. Prüfen Sie, ob die Replikation erwartungsgemäß funktioniert.
10. Verwenden Sie die SQL Server-Setupmedien zum Ausführen eines direkten Upgrades Ihrer SQL Server-Instanz auf die neue Version von SQL Server.

Websynchronisierung für die Mergereplikation

Bei der Websynchronisierung für die Mergereplikation ist es erforderlich, dass die SQL Server -Replikationsüberwachung (replisapi.dll) in das virtuelle Verzeichnis auf dem Server mit Internetinformationsdienste (Internet Information Services, IIS) kopiert wird, der für die Synchronisierung verwendet wird. Wenn Sie die Websynchronisierung konfigurieren, wird die Datei vom Assistenten zum Konfigurieren der Websynchronisierung in das virtuelle Verzeichnis kopiert. Wenn Sie die auf dem IIS-Server installierten SQL Server -Komponenten aktualisieren, müssen Sie replisapi.dll manuell vom Verzeichnis COM in das virtuelle Verzeichnis auf dem IIS-Server kopieren. Weitere Informationen zur Konfiguration der Websynchronisierung finden Sie unter Konfigurieren der Websynchronisierung.

Wiederherstellen einer replizierten Datenbank von einer früheren Version

Um sicherzustellen, dass die Replikationseinstellungen beibehalten werden, wenn die Sicherung einer replizierten Datenbank mithilfe einer früheren Version wiederhergestellt wird, stellen Sie die Sicherung auf einem Server und in einer Datenbank wieder her, deren Namen mit den Namen des Servers und der Datenbank übereinstimmen, von dem bzw. der die Sicherung erstellt wurde.

Weitere Informationen

SQL Server-Replikation
Häufig gestellte Fragen für Replikationsadministratoren
Abwärtskompatibilität von Replikationen
Unterstützte Versions- und Editionsupgrades
Aktualisieren von SQL Server
Upgrading a Replication Topology to SQL Server 2016 (Upgrade der Replikationstopologie auf SQL Server 2016)