Upgrade von gespiegelten Instanzen

  • Artikel

Gilt für:SQL Server

Wenn für eine gespiegelte SQL Server-Instanz ein Upgrade auf eine neue Version, ein neues SQL Server Service Pack oder kumulatives Update oder auf ein neues Windows Service Pack oder kumulatives Update ausgeführt wird, können Sie die Downtime für jede gespiegelte Datenbank auf ein einziges manuelles Failover reduzieren, indem Sie ein paralleles Upgrade ausführen (oder zwei manuelle Failover, falls Sie ein Failback auf das ursprüngliche primäre Replikat ausführen). Ein paralleles Upgrade ist ein mehrstufiger Prozess, bei dem im einfachsten Fall die gegenwärtig als Spiegelserver in einer Spiegelungssitzung verwendete SQL Server-Instanz aktualisiert, anschließend ein manuelles Failover auf die gespiegelte Datenbank ausgeführt, die vorherige SQL Server-Prinzipalinstanz aktualisiert und die Spiegelung wieder aufgenommen wird. In der Praxis hängt der genaue Prozess vom Betriebsmodus und der Anzahl und dem Layout der Spiegelungssitzung auf den zu aktualisierenden SQL Server-Instanzen ab.

Hinweis

Für Informationen zur Verwendung von Datenbankspiegelung mit Protokollversand während der Migration verwenden, laden Sie dieses Whitepaper zur Datenbankspiegelung und zum Protokollversandherunter.

Voraussetzungen

Lesen Sie die folgenden wichtigen Informationen, bevor Sie beginnen:

  • Unterstützte Versions- und Editionsupgrades: Überprüfen Sie, ob Sie von Ihrer Version des Windows-Betriebssystems und Ihrer Version von SQL Server auf SQL Server upgraden können. So ist es beispielsweise nicht möglich, von einer SQL Server 2005-Instanz direkt auf die neueste Version von SQL Server zu aktualisieren.

  • Auswählen einer Upgrademethode für die Datenbank-Engine: Wählen Sie basierend auf Ihrer Prüfung der unterstützten Versions- und Editionsupgrades sowie basierend auf den anderen in Ihrer Umgebung installierten Komponenten die passende Upgrademethode und die passenden Upgradeschritte aus, um das Upgrade der Komponenten in der richtigen Reihenfolge durchzuführen.

  • Planen und Testen des Upgradeplans für die Datenbank-Engine: Überprüfen Sie die Anmerkungen zu dieser Version, die bekannten Upgradeprobleme und die Prüfliste vor dem Upgrade. Entwickeln und testen Sie dann den Upgradeplan.

  • Hardware- und Softwareanforderungen für die Installation von SQL Server 2016: Überprüfen Sie die Softwareanforderungen für die Installation von SQL Server. Falls zusätzliche Software erforderlich ist, installieren Sie diese auf jedem Knoten, bevor Sie mit dem Upgradevorgang beginnen, um die Downtime zu minimieren.

Vor dem Start eines parallelen Upgrades sollten Sie Folgendes ausführen:

  1. Führen Sie zu Übungszwecken ein manuelles Failover für mindestens eine der Spiegelungssitzungen aus:

    Hinweis

    Informationen zum Verwalten des potenziellen Datenverlusts finden Sie unter Rollenwechsel während einer Datenbank-Spiegelungssitzung (SQL Server).

  2. Schützen Sie Ihre Daten:

    1. Führen Sie für jede Prinzipaldatenbank eine vollständige Datenbanksicherung aus:

      Erstellen einer vollständigen Datenbanksicherung (SQL Server).

    2. Führen Sie den DBCC CHECKDB-Befehl für jede Prinzipaldatenbank aus.

Phasen eines parallelen Upgrades

Die einzelnen Schritte bei einem parallelen Upgrade hängen vom Betriebsmodus der Spiegelungskonfiguration ab. Die grundlegenden Phasen sind jedoch identisch.

Hinweis

Weitere Informationen zu den Betriebsmodi finden Sie unter Betriebsmodi der Datenbankspiegelung.

Die folgende Abbildung zeigt ein Flussdiagramm mit den Grundstufen eines parallelen Upgrades für jeden Betriebsmodus. Die entsprechenden Prozeduren finden Sie nach der Abbildung.

Flussdiagramm mit den Schritten eines parallelen Upgrades

Wichtig

Eine Serverinstanz kann bei gleichzeitigen Spiegelungssitzungen verschiedene Spiegelungsrollen (Prinzipalserver, Spiegelserver oder Zeuge) ausführen. In diesem Fall müssen Sie den grundlegenden Prozess für das parallele Upgrade entsprechend anpassen. Weitere Informationen finden Sie unter Rollenwechsel während einer Datenbank-Spiegelungssitzung (SQL Server).

Hinweis

In vielen Fällen wird nach Fertigstellung des parallelen Upgrades ein Failback auf den ursprünglichen Prinzipalserver durchgeführt.

So ändern Sie den Modus einer Sitzung vom Modus für hohe Leistung in den Modus für hohe Sicherheit

  1. Ändern Sie den Betriebsmodus in den Modus für hohe Sicherheit ohne automatisches Failover, wenn sich eine Spiegelungssitzung vor der Ausführung eines parallelen Upgrades im Modus für hohe Leistung befindet.

    Wichtig

    Wenn der Spiegelserver vom Prinzipalserver geografisch entfernt ist, ist ein paralleles Upgrade möglicherweise nicht geeignet.

So entfernen Sie einen Zeugen aus einer Sitzung

  1. Wenn ein Zeuge an einer Spiegelungssitzung beteiligt ist, sollte der Zeuge vor der Ausführung eines parallelen Upgrades entfernt werden. Andernfalls hängt die Datenbankverfügbarkeit beim Upgrade der Spiegelserverinstanz von dem Zeugen ab, der weiterhin mit der Prinzipalserverinstanz verbunden bleibt. Nachdem Sie den Zeugen entfernt haben, ist ein Upgrade jederzeit während des parallelen Upgrades ohne Gefahr eines Datenbankausfalls möglich.

    Hinweis

    Weitere Informationen finden Sie unter Quorum: Auswirkungen eines Zeugen auf die Datenbankverfügbarkeit (Datenbankspiegelung).

So führen Sie das parallele Upgrade aus

  1. Zur Minimierung der Ausfallzeit wird Folgendes empfohlen: Starten Sie das parallele Upgrade mit dem Aktualisieren aller Spiegelungspartner, die aktuell als Spiegelserver in allen Spiegelungssitzungen fungieren. Möglicherweise müssen an dieser Stelle mehrere Serverinstanzen aktualisiert werden.

    Hinweis

    Ein Zeuge kann jederzeit während der Ausführung des parallelen Upgrades aktualisiert werden. Wenn beispielsweise eine Serverinstanz in Sitzung 1 als Spiegelserver und in Sitzung 2 als Zeuge fungiert, können Sie die Serverinstanz nun aktualisieren.

    Welche Serverinstanz zuerst aktualisiert wird, hängt von der aktuellen Konfiguration der Spiegelungssitzungen ab, und zwar wie folgt:

    • Wenn eine Serverinstanz bereits als Spiegelserver in allen Spiegelungssitzungen fungiert, aktualisieren Sie die Serverinstanz auf die neue Version.

    • Wenn alle Serverinstanzen aktuell als Prinzipalserver in allen Spiegelungssitzungen fungieren, wählen Sie eine Serverinstanz aus, die zuerst aktualisiert werden soll. Führen Sie dann ein manuelles Failover für alle Prinzipaldatenbanken aus, und aktualisieren Sie die Serverinstanz.

    Nach dem Upgrade schließt sich eine Serverinstanz automatisch wieder den zugehörigen Spiegelungssitzungen an.

  2. Warten Sie bei jeder Spiegelungssitzung, deren Serverinstanz gerade aktualisiert wurde, ab, bis die Sitzung synchronisiert ist. Stellen Sie dann eine Verbindung mit der Prinzipalserverinstanz her, und führen Sie manuell ein Failover zur Sitzung aus. Beim Failover wird die aktualisierte Serverinstanz zum Prinzipalserver dieser Sitzung, und der frühere Prinzipalserver wird zum Spiegelserver.

    Ziel dieses Schritts ist es, dass eine andere Serverinstanz zum Spiegelserver in jeder Spiegelungssitzung wird, an der sie als Partner beteiligt ist.

    Einschränkungen nach einem Failover zu einer aktualisierten Serverinstanz

    Nachdem ein Failover von einer früheren Serverinstanz auf eine SQL Server-Serverinstanz ausgeführt wurde, wird die Datenbanksitzung angehalten. Sie kann erst dann fortgesetzt werden, wenn der andere Partner aktualisiert wurde. Der Prinzipalserver nimmt jedoch nach wie vor Verbindungen an und lässt den Datenzugriff auf die und Änderungen an der Prinzipaldatenbank zu.

    Hinweis

    Damit eine neue Spiegelungssitzung eingerichtet werden kann, muss auf allen Serverinstanzen dieselbe Version von SQL Serverausgeführt werden.

  3. Nach dem Failover sollten Sie den DBCC CHECKDB -Befehl für die Prinzipaldatenbank ausführen.

  4. Aktualisieren Sie alle Serverinstanzen, die nun als Spiegelserver in allen Spiegelungssitzungen fungieren, in denen sie als Partner beteiligt sind. Möglicherweise müssen an dieser Stelle mehrere Server aktualisiert werden.

    Wichtig

    Es ist möglich, dass in einer komplexen Spiegelungskonfiguration manche Serverinstanz nach wie vor der ursprüngliche Prinzipalserver in mindestens einer Spiegelungssitzung ist. Wiederholen Sie die Schritte 2 bis 4 für diese Serverinstanzen, bis alle beteiligten Instanzen aktualisiert wurden.

  5. Setzen Sie die Spiegelungssitzung fort.

    Hinweis

    Ein automatisches Failover ist erst möglich, wenn der Zeuge aktualisiert und der Spiegelungssitzung erneut hinzugefügt wurde.

  6. Aktualisieren Sie die verbleibenden Serverinstanzen, die als Zeuge in allen zugehörigen Spiegelungssitzungen fungieren. Nachdem sich ein aktualisierter Zeuge wieder einer Spiegelungssitzung angeschlossen hat, ist das Ausführen eines automatischen Failovers wieder möglich. Möglicherweise müssen an dieser Stelle mehrere Server aktualisiert werden.

So ändern Sie den Modus einer Sitzung wieder in den Modus für hohe Leistung

  1. Sie haben die folgenden Möglichkeiten, um den Modus einer Sitzung wieder in den Modus für hohe Leistung zu ändern:

    • In SQL Server Management Studio: Ändern Sie im Dialogfeld Datenbankeigenschaften auf der Seite Spiegelung die Option Betriebsmodus in Hohe Leistung (asynchron) .

    • In Transact-SQL: Verwenden Sie ALTER DATABASE, um die Transaktionssicherheit auf OFF festzulegen.

So fügen Sie einen Zeugen einer Spiegelungssitzung erneut hinzu

  1. Im Modus für hohe Sicherheit können Sie den Zeugen in jeder Spiegelungssitzung wiederherstellen.

    So fügen Sie einen Zeugen wieder hinzu

Weitere Informationen

Aktualisieren auf SQL Server 2016 mithilfe des Installations-Assistenten (Setup)
Installieren von SQL Server 2016 von der Eingabeaufforderung
ALTER DATABASE-Datenbankspiegelung (Transact-SQL)
BACKUP (Transact-SQL)
Anzeigen des Status einer gespiegelten Datenbank (SQL Server Management Studio)
Datenbankspiegelung (SQL Server)
Rollenwechsel während einer Datenbank-Spiegelungssitzung (SQL Server)
Erzwingen des Diensts in einer Datenbank-Spiegelungssitzung (Transact-SQL)
Starten des Datenbankspiegelungs-Monitors (SQL Server Management Studio)
Database Mirroring Operating Modes