Teilen über

Neu starten einer Instance mit einem von Benutzer*innen initiierten manuellen Failover – Azure SQL Managed Instance

  • Artikel

Gilt für: Azure SQL Managed Instance

In diesem Artikel wird erläutert, wie Sie Azure SQL Managed Instance neu starten, indem Sie ein manuelles von Benutzer*innen initiiertes Failover auf einen sekundären Serverknoten mithilfe von PowerShell, Azure CLI oder der REST-API ausführen.

Es ist möglich, ein Failover eines primären Knoten auf der universellen Dienstebene (GP) und der unternehmenskritischen Dienstebene (BC) auszuführen und ein Failover eines sekundären schreibgeschützten Replikatsknoten auf der Dienstebene BC manuell auszuführen.

Hinweis

In diesem Artikel bezieht sich Failover auf das Starten des SQL Server-Datenbank-Engine-Prozesses auf einem sekundären Knoten und steht nicht im Zusammenhang mit dem regionsübergreifenden Failover einer Failovergruppe.

Verwendungszwecke für ein manuelles Failover

Verfügbarkeit, ein grundlegender Bestandteil der SQL Managed Instance-Plattform, funktioniert transparent für Ihre Datenbankanwendungen, indem lokale Standby-Serverknoten zum Hosten des SQL Server-Datenbank-Engine-Prozesses bereitgestellt werden. Ein Failover tritt auf, wenn der SQL Server-Datenbank-Engine-Prozess offline auf dem primären Serverknoten ausgeführt und auf einem sekundären Serverknoten online gestellt wird. In der Regel werden Failover zwischen SQL Managed Instance-Serverknoten automatisch ausgeführt und von der Plattform verwaltet, wenn ein Fehler erkannt wird, ein Knoten beeinträchtigt wurde oder während regelmäßiger monatlicher Softwareupdates.

Der gesamte Failovervorgang besteht darin, den SQL Server-Datenbank-Engine-Prozess auf einem sekundären Knoten online zu stellen, den Datenbankstatus zu validieren und schließlich die Clientverbindungen an den neuen primären Knoten umzuleiten. Clientverbindungen schlagen nur für einen kurzen Zeitraum, in der Regel unter einer Minute, während des letzten Schritts des Failovervorgangs fehl.

Sie können ein manuelles Failover ausführen, um den Engineprozess auf einem anderen Knoten aus den folgenden Gründen neu zu starten:

  • Fehlgeschlagene Anmeldungen oder Langsamkeit aufgrund von Leistungsproblemen.
  • Testen der Anwendung auf Failoverresilienz vor dem Bereitstellen in der Produktion.
  • Testen von End-to-End-Systemen auf Fehlerresilienz bei automatischen Failovern.
  • Testen der Auswirkungen von Failovern auf vorhandene Datenbanksitzungen.
  • Leistungsbeeinträchtigung der Abfrage (Neustart der Instance kann dazu beitragen, das Leistungsproblem zu beheben).

Wenn Sie sicherstellen, dass Ihre Anwendungen vor der Bereitstellung in der Produktion sicher vor Failovers sind, verringern Sie das Risiko von Anwendungsfehlern in der Produktion und tragen zur Verfügbarkeit der Anwendungen für Ihre Kunden bei. Erfahren Sie mehr über das Testen Ihrer Anwendungen für die Cloudbereitschaft im folgenden Video:

In der folgenden Tabelle wird das erwartete Verhalten der SQL Managed Instance während eines Failovervorgangs basierend auf der Dienstebene und dem Verfügbarkeitsmodell beschrieben:

Dienstebene Verfügbarkeitsmodell Erwartetes Failoververhalten Potenzielles Failoververhalten (Ausnahmen)
Universell Lokale Redundanz
(Einzelne Verfügbarkeitszone)		 Der SQL-Prozess wird auf derselben VM neu gestartet. Der SQL-Prozess wird auf einer anderenVM neu gestartet.
Universell Zonenredundanz (Vorschau)
(Mehrere Verfügbarkeitszonen)		 Der SQL-Prozess wird auf derselben VM neu gestartet. Der SQL-Prozess wird auf einer anderenVM neu gestartet.
Unternehmenskritisch Lokale Redundanz
(Einzelne Verfügbarkeitszone)		 Zufälliges sekundäres Replikat wird auf primär höhergestuft. N/V
Unternehmenskritisch Zonenredundanz
(Mehrere Verfügbarkeitszonen)		 Das zufällige sekundäre Replikat wird entweder in derselben oder in einer anderen Verfügbarkeitszone auf primär höhergestuft. N/V

Berechtigungen

Benutzer, die einen Failover initialisieren, müssen über eine der folgenden Azure-Rollen verfügen:

  • Rolle „Besitzer der Subscription“ oder
  • Rolle als Mitwirkender für SQL Managed Instance oder
  • Benutzerdefinierte Rolle mit der folgenden Berechtigung:
    • Microsoft.Sql/managedInstances/failover/action

Neu starten einer Instance mit einem manuellen Failover

Sie können eine Instance durch ein manuelles Failover mithilfe der Rest-API, Azure CLI oder PowerShell neu starten.

Az.Sql muss mindestens in Version v2.9.0 vorliegen. Verwenden Sie die Azure Cloud Shell im Azure-Portal – dort finden Sie immer die neueste PowerShell-Version.

Verwenden Sie vorab das folgende PowerShell-Skript, um die erforderlichen Azure-Module zu installieren. Wählen Sie außerdem die Subscription aus, in dem sich die SQL Managed Instance befindet, für die das Failover ausgeführt werden soll.

$subscription = 'enter your subscription ID here'
Install-Module -Name Az
Import-Module Az.Accounts
Import-Module Az.Sql

Connect-AzAccount
Select-AzSubscription -SubscriptionId $subscription

Verwenden Sie den PowerShell-Befehl Invoke-AzSqlInstanceFailover mit dem folgenden Beispiel, um ein Failover des primären Knotens zu initiieren. Dies gilt sowohl für die Dienstebene „Unternehmenskritisch“ als auch für die Ebene „Universell“.

$ResourceGroup = 'enter resource group of your MI'
$ManagedInstanceName = 'enter MI name'
Invoke-AzSqlInstanceFailover -ResourceGroupName $ResourceGroup -Name $ManagedInstanceName

Verwenden Sie den folgenden PowerShell-Befehl, um ein Failover des sekundären schreibgeschützten Knotens auszuführen. Dies gilt nur die Dienstebene „Unternehmenskritisch“.

$ResourceGroup = 'enter resource group of your MI'
$ManagedInstanceName = 'enter MI name'
Invoke-AzSqlInstanceFailover -ResourceGroupName $ResourceGroup -Name $ManagedInstanceName -ReadableSecondary

Überwachen des Failovers

Die Überwachung des Status eines von Benutzer*innen initiierten Failovers unterscheidet sich für Instances in den unternehmenskritischen und universellen Dienstebenen.

Um den Status eines von Benutzer*innen initiierten Failovers zu überwachen, verwenden Sie:

  • sys.dm_os_sys_info, um die Systembetriebszeit für die universelle Dienstebene zu überprüfen.
  • sys.dm_hadr_fabric_replica_states, um verfügbare Replikate für die unternehmenskritische Dienstebene zu überprüfen.

Der letzte Schritt des Failoverprozesses ist die Umleitung von Clientverbindungen an den neuen primären Knoten. Der kurze Verlust der Konnektivität mit Ihrem Client während des Failovers, der in der Regel weniger als eine Minute dauert, ist unabhängig von der Dienstebene ein Hinweis auf den Erfolg des Failovers.

Universelle Dienstebene

Das folgende T-SQL-Beispiel zeigt die Betriebszeit für den SQL-Prozess auf dem Knoten für die universelle Dienstebene:

SELECT sqlserver_start_time, sqlserver_start_time_ms_ticks FROM sys.dm_os_sys_info

Die Startzeit des SQL-Prozesses ist die Zeit, zu der der SQL Server-Datenbank-Engine-Prozess auf dem Knoten gestartet wurde. Die Zeit wird nach Abschluss des Failovers neu gestartet. Führen Sie diese Abfrage vor und nach dem Initiieren eines Failovers einer Instance auf der universellen Dienstebene aus, um den Status des Failovervorgangs zu überwachen.

Dienstebene „Unternehmenskritisch“

Im folgenden T-SQL-Beispiel wird angegeben, welcher Knoten derzeit das primäre Replikat für die unternehmenskritische Dienstebene ist:

SELECT DISTINCT replication_endpoint_url, fabric_replica_role_desc FROM sys.dm_hadr_fabric_replica_states

Der Knoten, der das primären Replikat hostet, ändert sich, nachdem das Failover abgeschlossen wurde. Führen Sie diese Abfrage vor und nach dem Initiieren eines Failovers einer Instance auf der unternehmenskritischen Dienstebene aus, um den Status des Failovervorgangs zu überwachen.

Hinweis

Der vollständige Failoverprozess kann während hochintensiver Workloads mehrere Minuten dauern, da die Instance-Engine sicherstellt, dass Transaktionen auf dem sekundären Knoten vor Initiieren des Failovers am gleichen Stand wie die Transaktionen des primären Knoten sind.

Begrenzungen

Berücksichtigen Sie folgende funktionsbezogene Einschränkungen bei von Benutzer*innen initiierten manuellen Failovers:

  • Auf ein und derselben SQL Managed Instance kann alle 15 Minuten immer nur ein (1) Failover initiiert werden.
  • Failovers sind nicht zulässig:
    • Bis die erste vollständige Sicherung für eine neue Datenbank durch automatisierte Backupsysteme abgeschlossen ist.
    • wenn gerade eine Datenbankwiederherstellung ausgeführt wird.
  • Für Instances in der unternehmenskritischen Dienstebene:
    • Es muss ein Quorum von Replikaten vorhanden sein, damit die Failoveranforderung angenommen wird.
    • Es kann nicht angegeben werden, auf welchem lesbaren sekundären Replikat das Failover initiiert werden soll.

Zugehöriger Inhalt