Upgraden von Always On-Verfügbarkeitsgruppen-ReplikatsinstanzenUpgrading Always On Availability Group Replica Instances

DIESES THEMA GILT FÜR:jaSQL Server (ab 2016)neinAzure SQL-DatenbankneinAzure SQL Data Warehouse neinParallel Data WarehouseTHIS TOPIC APPLIES TO: yesSQL Server (starting with 2016)noAzure SQL DatabasenoAzure SQL Data Warehouse noParallel Data Warehouse

Wenn eine SQL ServerSQL Server -Always On-Verfügbarkeitsgruppe auf eine neue SQL Server 2017SQL Server 2017 -Version oder ein neues SQL ServerSQL Server-Service Pack aktualisiert wird, können Sie die Downtime für das primäre Replikat auf ein einzelnes manuelles Failover reduzieren. Führen Sie dazu ein paralleles Upgrade aus (oder zwei manuelle Failover, falls Sie einen Failback auf das ursprüngliche primäre Replikat ausführen). Diese Vorgehensweise funktioniert auch, wenn eine kumulative Aktualisierung durchgeführt wird, beim Installieren auf einem neuen Windows Service Pack oder bei der kumulativen Aktualisierung.When upgrading a SQL ServerSQL Server Always On Availability Group to a new SQL Server 2017SQL Server 2017 version, to a new SQL ServerSQL Serverservice pack or cumulative update, or when installing to a new Windows service pack or cumulative update, you can reduce downtime for the primary replica to only a single manual failover by performing a rolling upgrade (or two manual failovers if failing back to the original primary). Während des Upgradevorgangs steht ein sekundäres Replikat weder für ein Failover noch für schreibgeschützte Vorgänge zur Verfügung. Nach dem Upgrade kann es etwas dauern, bis das sekundäre Replikat auf dem gleichen Stand ist, wie der primäre Replikatknoten. Dies ist vom Ausmaß der Aktivität auf dem Primären Replikatknoten (erwarten Sie also viel Netzwerkverkehr) abhängig.During the upgrade process, a secondary replica will not be available for failover or for read-only operations, and, after the upgrade, it may take some time for the secondary replica to catch up with the primary replica node depending upon the volume of activity on the primary replica node (so expect high network traffic).

Hinweis

In diesem Thema wird nur das Upgraden des SQL Servers selbst behandelt.This topic limits the discussion to the upgrade of SQL Server itself. Es behandelt nicht das Upgraden des Betriebssystems, das den WSFC-Cluster (Windows Server Failover Clusting) beinhaltet.It does not cover upgrading the operating system containing the Windows Server Failover Clusting (WSFC) cluster. Das Upgraden des Windows-Betriebssystems, das den Failovercluster hostet, wird für ältere Betriebssysteme als Windows Server 2012 R2 nicht unterstützt.Upgrading the Windows operating system hosting the failover cluster is not supported for operating systems before Windows Server 2012 R2. Weitere Informationen über das Upgraden eines Clusterknotens, der auf Windows Server 2012 R2 ausgeführt wird, finden Sie unter Cluster Operating System Rolling Upgrade(Paralleles Upgraden für Clusterbetriebssysteme)To upgrade a cluster node running on Windows Server 2012 R2, see Cluster Operating System Rolling Upgrade

Erforderliche KomponentenPrerequisites

Lesen Sie die folgenden wichtigen Informationen, bevor Sie beginnen:Before you begin, review the following important information:

  • Supported Version and Edition Upgrades: Prüfen Sie, dass Sie von Ihrer Version des Windows-Betriebssystems und Ihrer Version des SQL Servers auf SQL Server 2016 upgraden können.Supported Version and Edition Upgrades: Verify that you can upgrade to SQL Server 2016 from your version of the Windows operating system and version of SQL Server. Sie können beispielsweise nicht direkt von einer SQL Server 2005-Instanz auf SQL Server 2017SQL Server 2017upgraden.For example, you cannot upgrade directly from a SQL Server 2005 instance to SQL Server 2017SQL Server 2017.

  • Choose a Database Engine Upgrade Method: Wählen Sie die passende Upgrademethode und die Schritte aus, die sowohl auf Ihrer Betrachtung der unterstützten Version und Editionsupgrades als auch auf den anderen in Ihrer Umgebung installierten Komponenten basieren, um die Komponenten in der richtigen Reihenfolge upzugraden.Choose a Database Engine Upgrade Method: Select the appropriate upgrade method and steps based on your review of supported version and edition upgrades and also based on other components installed in your environment to upgrade components in the correct order.

  • Planen und Testen des Upgradeplans für das Datenbankmodul: Überprüfen Sie die Anmerkungen zu dieser Version, die bekannten Upgradeprobleme und die Prüfliste vor dem Upgrade. Entwickeln und testen Sie den Upgradeplan.Plan and Test the Database Engine Upgrade Plan: Review the release notes and known upgrade issues, the pre-upgrade checklist, and develop and test the upgrade plan.

  • Hardware- und Softwareanforderungen für die Installation von SQL Server 2016: Überprüfen Sie die Softwareanforderungen für die Installation von SQL Server 2017SQL Server 2017.Hardware and Software Requirements for Installing SQL Server 2016: Review the software requirements for installing SQL Server 2017SQL Server 2017. Falls zusätzliche Software erforderlich ist, installieren Sie diese auf jedem Knoten, bevor Sie mit dem Upgradevorgang beginnen, um die Downtime zu minimieren.If additional software is required, install it on each node before you begin the upgrade process to minimize any downtime.

Bewährte Verfahren für parallele Upgrades von Always On-VerfügbarkeitsgruppenRolling Upgrade Best Practices for Always On Availability Groups

Beachten Sie beim Ausführen von Serverupgrades oder -aktualisierungen die folgenden bewährten Verfahren, um die Downtime und Datenverluste für Ihre Verfügbarkeitsgruppen zu minimieren:The following best practices should be observed when performing server upgrades or updates in order to minimize downtime and data loss for your availability groups:

  • Vor dem Start des parallelen Upgrades:Before starting the rolling upgrade,

    • Führen Sie zu Übungszwecken ein manuelles Failover für mindestens eine der Replikatinstanzen mit synchronem Commit aus.Perform a practice manual failover on at least one of your synchronous-commit replica instances

    • Schützen Sie Ihre Daten, indem Sie eine vollständige Datenbanksicherung für jede Verfügbarkeitsdatenbank ausführen.Protect your data by performing a full database backup on every availability database

    • Führen Sie DBCC CHECKDB für jede Verfügbarkeitsdatenbank aus.Run DBCC CHECKDB on every availability database

  • Führen Sie das Upgrade zuerst immer für die sekundären Remotereplikatinstanzen und dann für die lokalen sekundären Replikatinstanzen und zuletzt für die primäre Replikatinstanz durch.Always upgrade the remote secondary replica instances first, then local secondary replica instances next, and the primary replica instance last.

  • Von einer Datenbank, für die gerade ein Upgrade ausgeführt wird, kann keine Sicherung erstellt werden.Backups cannot occur on a database that is in the process of being upgraded. Vor dem Aktualisieren der sekundären Replikate konfigurieren Sie die Voreinstellung für die automatisierte Sicherung, um Sicherungen nur auf dem primären Replikat auszuführen.Prior to upgrading the secondary replicas, configure the automated backup preference to run backups only on the primary replica. Während eines Versionsupgrades sind keine Replikate lesbar oder für Sicherungen verfügbar.During a version upgrade, no replicas will be readable or available for backups. Während eines Upgrades ohne Versionswechsel können Sie automatische Sicherungen konfigurieren, die auf den sekundären Replikaten ausgeführt werden, bevor das primäre Replikat upgegradet wird.During a non-version upgrade, you can configure automated backups to run on secondary replicas prior to upgrading the primary replica.

  • Während eines Versionsupgrades können lesbare sekundäre Replikate zwischenzeitlich nicht gelesen werden. Dieser Zeitraum der Nicht-Lesbarkeit beginnt, nachdem das Upgrade auf das sekundäre Replikat durchgeführt wurde, und hält an, bis für das primäre Replikat ein Failover an ein upgegradetes sekundäres Replikat durchgeführt wurde oder das primäre Replikat selbst upgegradet wurde.During a version upgrade, readable secondaries cannot be read after an upgrade of the readable secondary and before either the primary replica is failed over to an upgraded secondary or the primary replica is upgraded.

  • Damit für die Verfügbarkeitsgruppe während des Upgrades kein unbeabsichtigtes Failover ausgeführt wird, entfernen Sie den Verfügbarkeitsfailover zunächst von allen Replikaten mit synchronem Commit.To prevent the availability group from unintended failovers during the upgrade process, remove availability failover from all synchronous-commit replicas before you begin.

  • Führen Sie für die primäre Replikatinstanz kein Upgrade durch, bevor Sie für die Verfügbarkeitsgruppe nicht ein Failover auf eine upgegradete Instanz mit einem sekundären Replikat ausgeführt haben.Do not upgrade the primary replica instance before failing over the availability group to an upgraded instance with a secondary replica first. Andernfalls kann sich die Downtime von Clientanwendungen während des Upgrades auf der primären Replikatinstanz verlängern.Otherwise, client applications may suffer extended downtime during the upgrade on the primary replica instance.

  • Führen Sie für die Verfügbarkeitsgruppe immer ein Failover auf eine sekundäre Replikatinstanz mit synchronem Commit aus.Always fail over the availability group to a synchronous-commit secondary replica instance. Falls Sie ein Failover auf eine sekundäre Replikatinstanz mit asynchronem Commit ausführen, treten in den Datenbanken Datenverluste auf, und die Datenverschiebung wird automatisch so lange angehalten, bis Sie den Vorgang manuell fortsetzen.If you fail over to an asynchronous-commit secondary replica instance, the databases will suffer data loss, and data movement is automatically suspended until you manually resume data movement.

  • Führen Sie für die primäre Replikatinstanz kein Upgrade durch, bevor Sie nicht eine der anderen sekundären Replikatinstanzen upgegradet oder aktualisiert haben.Do not upgrade the primary replica instance before upgrading or updating any other secondary replica instance. Ein primäres Replikat, für das ein Upgrade ausgeführt wurde, kann keine Protokolle mehr an sekundäre Replikate versenden, deren SQL Server 2017SQL Server 2017 -Instanz noch nicht auf die gleiche Version aktualisiert wurde.An upgraded primary replica can no longer ship logs to any secondary replica whose SQL Server 2017SQL Server 2017 instance that has not yet been upgraded to the same version. Wenn eine Datenverschiebung zu einem sekundären Replikat angehalten wurde, kann für dieses Replikat kein automatisches Failover ausgeführt werden, und die Verfügbarkeitsdatenbanken sind anfällig für Datenverluste.When data movement to a secondary replica is suspended, no automatic failover can occur for that replica, and your availability databases are vulnerable to data loss.

  • Bevor Sie ein Failover für eine Verfügbarkeitsgruppe ausführen, sollten Sie überprüfen, ob der Synchronisierungsstatus des Failoverziels SYNCHRONIZED lautet.Before failing over an availability group, verify that the synchronization state of the failover target is SYNCHRONIZED.

Prozess des parallelen UpgradesRolling Upgrade Process

Die genauen Schritte hängen von Faktoren wie der Bereitstellungstopologie der Verfügbarkeitsgruppen und dem Commitmodus der einzelnen Replikate ab.In practice, the exact process will depend on factors such as the deployment topology of your availability groups and the commit mode of each replica. Im einfachsten Szenario ist ein paralleles Upgrade jedoch ein mehrstufiger Prozess, der in seiner einfachsten Form aus den folgenden Schritten besteht:But in the simplest scenario, a rolling upgrade is a multi-stage process that in its simplest form involves the following steps:

Szenario für ein Upgrade von Verfügbarkeitsgruppen in HADRAvailability Group Upgrade in HADR Scenario

  1. Deaktivieren des automatischen Failovers für alle Replikate mit synchronem CommitRemove automatic failover on all synchronous-commit replicas

  2. Upgraden aller sekundären Remotereplikatinstanzen, auf denen sekundäre Replikate mit asynchronem Commit ausgeführt werdenUpgrade all remote secondary replica instances running asynchronous-commit secondary replicas

  3. Upgraden für alle lokalen sekundären Replikatinstanzen, auf denen das primäre Replikat derzeit nicht ausgeführt wirdUpgrade the all local replica secondary instances that are not currently running the primary replica

  4. Ausführen eines manuellen Failovers der Verfügbarkeitsgruppe auf ein lokales sekundäres Replikat mit synchronem CommitManually fail over the availability group to a local synchronous-commit secondary replica

  5. Upgraden oder Aktualisieren der lokalen Replikatinstanz, von der das primäre Replikat zuvor gehostet wurdeUpgrade or update the local replica instance that formerly hosted the primary replica

  6. Konfigurieren automatischer Failoverpartner nach BedarfConfigure automatic failover partners as desired

    Falls erforderlich, können Sie einen zusätzlichen manuellen Failover ausführen, um die ursprüngliche Konfiguration der Verfügbarkeitsgruppe wiederherzustellen.If necessary, you can perform an extra manual failover to return the availability group to its original configuration.

Verfügbarkeitsgruppe mit einem sekundären RemotereplikatAvailability Group with One Remote Secondary Replica

Wenn Sie eine Verfügbarkeitsgruppe ausschließlich zur Notfallwiederherstellung bereitgestellt haben, müssen Sie für die Verfügbarkeitsgruppe u. U. ein Failover auf ein sekundäres Replikat mit asynchronem Commit ausführen.If you have deployed an availability group only for disaster recovery, you may need to fail over the availability group to an asynchronous-commit secondary replica. Diese Konfiguration wird in der folgenden Abbildung dargestellt:Such configuration is illustrated by the following figure:

Szenario für ein Upgrade von Verfügbarkeitsgruppen in DRAvailability Group Upgrade in DR Scenario

In diesem Fall müssen Sie für die Verfügbarkeitsgruppe während des parallelen Upgrades ein Failover auf das sekundäre Replikat mit asynchronem Commit ausführen.In this situation, you must fail over the availability group to the asynchronous-commit secondary replica during the rolling upgrade. Zur Vermeidung von Datenverlusten ändern Sie den Commitmodus in den synchronen Commitmodus und warten mit dem Failover der Verfügbarkeitsgruppe, bis das sekundäre Replikat synchronisiert ist.To prevent data loss, change the commit mode to synchronous commit and wait for the secondary replica to be synchronized before you fail over the availability group. Der Prozess zum Durchführen eines parallelen Upgrades kann somit folgendermaßen aussehen:Therefore, the rolling upgrade process may look as follows:

  1. Upgraden der sekundären Replikatinstanz am RemotestandortUpgrade the secondary replica instance on the remote site

  2. Ändern des Commitmodus in den synchronen CommitmodusChange the commit mode to synchronous commit

  3. Warten, bis der Synchronisierungsstatus SYNCHRONIZED lautetWait until synchronization state is SYNCHRONIZED

  4. Ausführen eines Failovers für die Verfügbarkeitsgruppe an ein sekundäres Replikat am RemotestandortFail over the availability group to the secondary replica on the remote site

  5. Upgraden oder Aktualisieren der lokalen (am primären Standort) ReplikatinstanzUpgrade or update the local (primary site) replica instance

  6. Ausführen eines Failovers der Verfügbarkeitsgruppe zurück auf den primären StandortFail over the availability group back to the primary site

  7. Ändern des Commitmodus in den asynchronen CommitmodusChange the commit mode to asynchronous commit

    Der synchrone Commitmodus ist für die Datensynchronisierung mit einem Remotestandort nicht zu empfehlen. Nachdem die Einstellung geändert wurde, verzeichnen die Clientanwendungen möglicherweise einen sofortigen Anstieg der Datenbanklatenz.Since the synchronous-commit mode is not a recommended setting for data synchronization to a remote site, client applications may notice an immediate increase in database latency after the setting change. Darüber hinaus führt ein Failover dazu, dass alle unbestätigten Protokollmeldungen verworfen werden.Moreover, performing a failover will cause all unacknowledged log messages to be discarded. Die Anzahl der verworfenen Protokollmeldungen kann aufgrund hoher Netzwerklatenz zwischen den beiden Standorten deutlich erhöht sein, was auf den Clients zu einer hohen Rate von Transaktionsfehlern führt.The amount of discarded log messages can be quite large due to the high network latency between the two sites, causing clients to experience a high volume of transactional failure. Sie können die Auswirkungen auf die Clientanwendungen anhand der folgenden Maßnahmen minimieren:You can minimize impact to client applications by doing the following:

  • Festlegen des Wartungsfensters auf Zeiten mit geringem ClientdatenverkehrCarefully select a maintenance window during low client traffic

  • Ändern Sie den Verfügbarkeitsmodus während des Upgradens oder Aktualisierens von SQL Server 2017SQL Server 2017 am primären Standort zurück in den asynchronen Commitmodus, und kehren Sie zu synchronen Commits zurück, wenn Sie wieder bereit für ein Failover auf den primären Standort sind.While upgrading or updating SQL Server 2017SQL Server 2017 on the primary site, change the availability mode back to asynchronous commit, then revert to synchronous commit when you are ready to fail over to the primary site again

Verfügbarkeitsgruppe mit Failoverclusterinstanz-KnotenAvailability Group with Failover Cluster Instance Nodes

Falls eine Verfügbarkeitsgruppe Failoverclusterinstanz-Knoten (Failover Cluster Instance; FCI) beinhaltet, sollten Sie die inaktiven Knoten vor den aktiven Knoten upgraden.If an availability group contains failover cluster instance (FCI) nodes, you should upgrade the inactive nodes before you upgrade the active nodes. In der folgenden Abbildung ist ein gängiges Verfügbarkeitsgruppenszenario mit FCIs dargestellt. Es basiert auf FCIs, die auf lokale Hochverfügbarkeit und asynchrone Commits zur Remote-Notfallwiederherstellung ausgelegt sind, und veranschaulicht die Schritte zum Ausführen des Upgrades.The figure below illustrates a common availability group scenario with FCIs for local high availability and asynchronous commit between the FCIs for remote disaster recovery, and the upgrade sequence.

Szenario für ein Upgrade von Verfügbarkeitsgruppen mit FCIsAvailability Group Upgrade with FCIs

  1. Upgraden oder Aktualisieren von REMOTE2 (Remote2)Upgrade or update REMOTE2

  2. Failover von FCI2 auf REMOTE2Fail over FCI2 to REMOTE2

  3. Upgraden oder Aktualisieren von REMOTE1 (Remote1)Upgrade or update REMOTE1

  4. Upgraden oder Aktualisieren von PRIMARY2 (Primär2)Upgrade or update PRIMARY2

  5. Failover von FCI1 auf PRIMARY2Fail over FCI1 to PRIMARY2

  6. Upgraden oder Aktualisieren von PRIMARY1 (Primär1)Upgrade or update PRIMARY1

Upgraden oder Aktualisieren von SQL Server-Instanzen mit mehreren VerfügbarkeitsgruppenUpgrade Update SQL Server Instances with Multiple Availability Groups

Falls Sie mehrere Verfügbarkeitsgruppen mit primären Replikaten auf verschiedenen Serverknoten ausführen (eine Aktive-/Aktive Konfiguration), umfasst der Upgradepfad mehr Failoverschritte, um die hohe Verfügbarkeit während des Vorgangs zu sichern.If you are running multiple availability groups with primary replicas on separate server nodes (an Active/Active configuration), the upgrade path involves more failover steps to preserve high availability in the process. Angenommen, Sie führen drei Verfügbarkeitsgruppen auf drei Serverknoten aus (vgl. die folgende Tabelle) und alle sekundären Replikate werden im synchronen Commitmodus ausgeführt.Suppose you are running three availability groups on three server nodes as shown in the following table, and all secondary replicas are running in synchronous-commit mode.

VerfügbarkeitsgruppeAvailability Group Knoten1Node1 Knoten2Node2 Knoten3Node3
VG1AG1 PrimärPrimary
VG2AG2 PrimärPrimary
VG3AG3 PrimärPrimary

In diesem Fall kann es von Vorteil sein, ein paralleles Upgrade mit Lastenausgleich in der folgenden Reihenfolge durchzuführen:It may be appropriate in your situation to perform a load-balanced rolling upgrade in the following sequence:

  1. Failover von VG2 auf Knoten3 (um Knoten2 freizugeben)Fail over AG2 to Node3 (to free up Node2)

  2. Upgraden oder Aktualisieren von Knoten2Upgrade or update Node2

  3. Failover von VG1 auf Knoten2 (um Knoten1 freizugeben)Fail over AG1 to Node2 (to free up Node1)

  4. Upgraden oder Aktualisieren von Knoten1Upgrade or update Node1

  5. Failover sowohl von VG2 als auch von VG3 auf Knoten1 (um Knoten3 freizugeben)Fail over both AG2 and AG3 to Node1 (to free up Node3)

  6. Upgraden oder Aktualisieren von Knoten3Upgrade or update Node3

  7. Failover von VG3 auf Knoten3Fail over AG3 to Node3

    Bei dieser Art von Upgrade beträgt die durchschnittliche Downtime weniger als zwei Failover pro Verfügbarkeitsgruppe.This upgrade sequence has an average downtime of less than two failovers per availability group. Die resultierende Konfiguration ist in der folgenden Tabelle dargestellt.The resulting configuration is shown in the table below.

VerfügbarkeitsgruppeAvailability Group Knoten1Node1 Knoten2Node2 Knoten3Node3
VG1AG1 PrimärPrimary
VG2AG2 PrimärPrimary
VG3AG3 PrimärPrimary

Je nach Ihrer spezifischen Implementierung kann der Upgradepfad abweichen. Das Gleiche gilt für die Downtime der Clientanwendungen.Based on your specific implementation, your upgrade path may vary, and the downtime that client applications experience may vary as well.

Hinweis

In vielen Fällen wird nach Fertigstellung des parallelen Upgrades ein Failback auf das primäre Replikat durchgeführt.In many cases, after the rolling upgrade is completed, you will failback to the original primary replica.

Siehe auchSee Also

Aktualisieren auf SQL Server 2016 mithilfe des Installations-Assistenten (Setup) Upgrade to SQL Server 2016 Using the Installation Wizard (Setup)
Installieren von SQL Server 2016 von der EingabeaufforderungInstall SQL Server 2016 from the Command Prompt