Upgraden oder Patchen replizierter Datenbanken

Gilt für:SQL Server - nur Windows

SQL Server unterstützt das Upgrade replizierter Datenbanken aus früheren Versionen von SQL Server; Es ist nicht erforderlich, aktivitäten auf anderen Knoten zu beenden, während ein Knoten aktualisiert wird.

Voraussetzungen

Stellen Sie sicher, dass die Regeln, die im Hinblick auf die in einer Topologie unterstützten Versionen gelten, eingehalten werden:

• Ein Distributor kann eine beliebige Version sein, solange sie größer oder gleich der Publisher-Version ist (in vielen Fällen ist der Distributor dieselbe Instanz wie der Publisher).

• Für den Verleger ist jede Version zulässig, die der Verteiler-Version entspricht oder niedriger als diese ist.

• Die Abonnentenversion hängt vom Publikationstyp ab:

  • 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.

  • Abonnierende für eine Mergeveröffentlichung können alle Versionen nutzen, die gleich oder niedriger sind als die Herausgeberversion. Diese werden gemäß dem Supportzeitraum für den Versionslebenszyklus unterstützt.

Upgradepfade

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 Verfügbarkeitsgruppen (Availability Groups, AGs) oder Failoverclusterinstanzen (Failover Cluster Instances, FCIs) ausgeführt werden, werden direkte Upgrades mit einem parallelen Upgrade kombiniert, um die Downtime zu minimieren.

Ein gängiger Ansatz für parallele Upgrades von Replikationstopologien besteht darin, Publisher-Abonnentenpaare in Teilen in die neue Parallelumgebung zu verschieben, im Gegensatz zu einer Bewegung der gesamten Topologie. Dieser phasenweise Ansatz trägt dazu bei, Ausfallzeiten zu steuern und die Auswirkungen für das unternehmen, das von der Replikation abhängig ist, zu minimieren.

Der größte Teil dieses Artikels ist auf das Aktualisieren der Version von SQL Server ausgerichtet. Die Vorgehensweise für direktes Upgrade sollte aber auch beim Patchen von SQL Server mit einem Service Pack oder kumulativen Update verwendet werden.

Bemerkungen

Das Upgrade einer Replikationstopologie ist ein aus mehreren Schritten bestehender Vorgang. Es wird empfohlen, ein Upgrade eines Replikats Ihrer Replikationstopologie in einer Testumgebung auszuprobieren, bevor das Upgrade in der eigentlichen Produktionsumgebung durchgeführt wird. Dies hilft dabei, jede Betriebsdokumentation auszu ironieren, die für die reibungslose Behandlung des Upgrades erforderlich ist, ohne während des tatsächlichen Upgradeprozesses teure und lange Ausfallzeiten zu verursachen. Sie können Ausfallzeiten erheblich reduzieren, indem Sie AGs und/oder FCIs für ihre Produktionsumgebungen verwenden, während sie die Replikationstopologie aktualisieren. Darüber hinaus empfehlen wir, Sicherungen aller Datenbanken einschließlich msdb, master, Verteilungsdatenbanken und der Benutzerdatenbanken zu erstellen, die an der Replikation teilnehmen, bevor Sie das Upgrade versuchen.

Wenn Sie über eine Verteilungsdatenbank in einer Failoverclusterinstanz verfügen, müssen alle beteiligten Knoten denselben Build verwenden. Es wird kein Setup empfohlen, bei dem ein Knoten eine SQL Server-Version vor SQL Server 2016 (13.x) SP2-CU3 oder SQL Server 2017 (14.x) CU6 ist und der andere Knoten eine SQL Server-Version höher als SQL Server 2016 (13.x) SP2-CU3 oder SQL Server 2017 (14.x) CU6 ist. Ab SQL Server 2016 (13.x) SP2-CU3 und SQL Server 2017 (14.x) CU6 wird Unterstützung für die Verwendung einer Verteilungsdatenbank in einer AG und für neue Objekte (Tabellen, gespeicherte Prozeduren) in Verteilungsdatenbanken hinzugefügt. Wenn sich Ihre Verteilungsdatenbank in einer Failoverclusterinstanz befindet und Sie eine stufenweise Migration durchführen, aber nicht für alle Knoten ein Upgrade auf dieselbe Version von SQL Server durchführen können, empfiehlt es sich bei einem engen Migrationszeitrahmen, Kontoaufgaben wie das Hinzufügen von neuen Abonnenten, Abonnements, Herausgebern oder die Veröffentlichung auf dem Knoten mit der aktuellsten Version von SQL Server durchzuführen.

Replikationsmatrix

Kompatibilitätsmatrix für Transaktions- und Momentaufnahmereplikation

Herausgeber	Verteiler	Abonnent
Azure SQL Managed InstanceAUTD	Azure SQL Managed InstanceAUTD	Azure SQL-Datenbank Azure SQL Managed InstanceAUTD Azure SQL Managed Instance2022 SQL Server 2022 (16.x) SQL Server 2019 (15.x)
Azure SQL Managed Instance2022	Azure SQL Managed InstanceAUTD Azure SQL Managed Instance2022	Azure SQL-Datenbank Azure SQL Managed InstanceAUTD Azure SQL Managed Instance2022 SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x)
SQL Server 2022 (16.x)	SQL Server 2022 (16.x)	Azure SQL-Datenbank Azure SQL Managed InstanceAUTD Azure SQL Managed Instance2022 SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x)
SQL Server 2019 (15.x)	SQL Server 2022 (16.x) SQL Server 2019 (15.x)	Azure SQL-Datenbank Azure SQL Managed InstanceAUTD Azure SQL Managed Instance2022 SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x)
SQL Server 2017 (14.x)	SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x)	Azure SQL Managed Instance2022 SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x)
SQL Server 2016 (13.x)	SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x)	SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x)
SQL Server 2014 (12.x)	Azure SQL Managed InstanceAUTD Azure SQL Managed Instance2022 SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x)	SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x)
SQL Server 2012 (11.x)	SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x)	SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x)
SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x)	SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x)	SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x)

²⁰²² gilt für azure SQL Managed Instance, die mit der SQL Server 2022-Updaterichtliniekonfiguriert ist. ^AUTD- Gilt für Azure SQL Managed Instance-Instanzen, die mit der Updaterichtlinie konfiguriert sind, die sicherstellt, dass die Instanzen immer auf dem neuesten Stand sind.

Kompatibilitätsmatrix für die Mergereplikation

Herausgeber	Verteiler	Abonnent
SQL Server 2022 (16.x)	SQL Server 2022 (16.x)	SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x)
SQL Server 2019 (15.x)	SQL Server 2022 (16.x) SQL Server 2019 (15.x)	SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x)
SQL Server 2017 (14.x)	SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x)	SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x)
SQL Server 2016 (13.x)	SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x)	SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x)
SQL Server 2014 (12.x)	SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x)	SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x)
SQL Server 2012 (11.x)	SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x)	SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x)
SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x)	SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x)	SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x)

Überlegungen zu Upgrades

Ausführen des Protokolllese-Agents für die Transaktionsreplikation vor dem Upgrade

Bevor Sie SQL Server aktualisieren, müssen Sie sicherstellen, dass alle zugesicherten Transaktionen aus veröffentlichten Tabellen vom Log Reader-Agent verarbeitet wurden. Führen Sie die folgenden Schritte für jede Datenbank aus, die Transaktionspublikationen enthält, um sicherzustellen, dass alle Transaktionen verarbeitet werden:

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 werden. Das Resultset dieser Prozedur sollte leer sein.

5. Führen Sie sp_replflush aus, um die Verbindung von sp_replcmds zu schließen.

6. Führen Sie das Serverupgrade auf die neueste Version von SQL Server durch.

7. Starten Sie den SQL Server-Agent und den Protokollleser-Agent neu, wenn sie nach dem Upgrade nicht automatisch gestartet werden.

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

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 es nicht erforderlich ist, Abonnements erneut zu initialisieren. 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.

Bei der Mergereplikation werden Metadaten der Veröffentlichung und des Abonnements in mehreren Systemtabellen in den Veröffentlichungs- und Abonnementdatenbanken gespeichert. Bei Ausführung des s werden die Veröffentlichungsmetadaten aktualisiert, und bei Ausführung des Merge-Agents werden die Abonnementmetadaten aktualisiert. Es ist nur erforderlich, eine Veröffentlichungsmomentaufnahme zu generieren. Wenn bei einer Mergeveröffentlichung parametrisierte Filter verwendet werden, gibt es auch für jede Partition eine Momentaufnahme. Es ist nicht erforderlich, diese partitionierten Momentaufnahmen zu aktualisieren.

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.

Upgrade auf Standard-, Arbeitsgruppen- oder Express-Editionen

Stellen Sie vor dem Upgrade von einer Edition von SQL Server auf eine andere sicher, dass die aktuell verwendete Funktionalität in der Edition unterstützt wird, auf die Sie aktualisieren. 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-Replikationen, 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.

Hinweis

Für SQL Server 2008 (10.0.x) und SQL Server 2008 R2 (10.50.x) muss das Upgrade des Herausgebers und Abonnenten gleichzeitig erfolgen, um mit der Replikationstopologie übereinzustimmen. SQL Server 2008 (10.0.x) und SQL Server 2008 R2 (10.50.x) Herausgeber oder Abonnenten können weder über einen SQL Server 2016 (13.x)-Herausgeber (oder höher) noch über einen Abonnenten verfügen. Wenn ein Upgrade zur gleichen Zeit nicht möglich ist, verwenden Sie ein Zwischenupgrade, um die SQL Server-Instanzen auf SQL Server 2014 (12.x) zu aktualisieren und dann erneut auf SQL Server 2016 (13.x) (oder höher) zu aktualisieren.

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 Distributors zu Windows Server

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 entweder für eine eigenständige SQL Server-Instanz oder eine in einer Failoverclusterinstanz (Failover Cluster Instance, FCI) ausgeführt werden.

1. Richten Sie eine neue SQL Server-Instanz (entweder eigenständig oder FCI), Edition und Version als Distributor auf Windows Server mit einem anderen Windows-Cluster- und SQL Server-FCI-Namen oder eigenständigen Hostnamen ein. Sie müssen die Verzeichnisstruktur wie beim alten Distributor beibehalten, um sicherzustellen, dass die ausführbaren Dateien der Replikationsagenten, Replikationsordner und Datenbankdateipfade im gleichen Pfad in der neuen Umgebung gefunden werden. Dies reduziert alle nach der Migration/Upgrade erforderlichen Schritte.

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, nehmen Sie die gesamte SQL Server-Rolle im Cluster-Manager offline, einschließlich des Netzwerknamens.

4. Entfernen Sie die DNS- und Active Directory-Computerobjekteinträge für die alte (aktuelle Distributorinstanz)-Umgebung.

5. Ändern Sie den Hostnamen des neuen Servers in den des alten Servers.

   1. Wenn es sich um einen SQL Server-FCI handelt, benennen Sie den neuen SQL Server FCI mit demselben virtuellen Servernamen wie die alte Instanz um.

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.

Hinweis

Um Ausfallzeiten zu reduzieren, empfehlen wir, die parallele Migration des Distributors als eine Aktivität durchzuführen und das direkte Upgrade auf SQL Server als eine andere Aktivität. Auf diese Weise können Sie einen phasenweisen Ansatz ergreifen, Risiken reduzieren und Ausfallzeiten minimieren.

Websynchronisierung für die Mergereplikation

Für die Websynchronisierungsoption für die Zusammenführungsreplikation müssen Sie den SQL Server-Replikationslistener (replisapi.dll) in das virtuelle Verzeichnis auf dem IIS-Server (Internet Information Services) kopieren, der für die Synchronisierung verwendet wird. Wenn Sie die Websynchronisierung konfigurieren, kopiert der Assistent zum Konfigurieren der Websynchronisierung die Datei in das virtuelle Verzeichnis. 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 aus 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.

Zugehörige Inhalte

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