Vom Benutzer initiiertes manuelles Failover für SQL Managed Instance

  • Artikel

Gilt für:Azure SQL Managed Instance

In diesem Artikel wird erläutert, wie ein primärer Knoten auf den Dienstebenen SQL Managed Instance General Purpose (GP) und Business Critical (BC) und ein sekundärer schreibgeschützter Replikationsknoten nur auf der Dienstebene BC manuell ausgefallen werden kann.

Hinweis

Dieser Artikel steht nicht im Zusammenhang mit regionsübergreifenden Failovern in Failovergruppen.

Verwendungszwecke für ein manuelles Failover

Hochverfügbarkeit ist ein wesentlicher Bestandteil der SQL Managed Instance-Plattform und transparent für Ihre Datenbankanwendungen. Failovervorgänge vom primären auf den sekundären Knoten können erfolgen, wenn ein Knoten beeinträchtigt ist oder ein Fehler erkannt wird oder während die regelmäßigen monatlichen Softwareupdates ausgeführt werden. Dies alles sind erwartete Verhaltensweisen für alle Anwendungen mit SQL Managed Instance in Azure.

In folgenden Fällen sollten Sie allerdings ein manuelles Failover in SQL Managed Instance in Erwägung ziehen:

  • Testen der Anwendung auf Failoverresilienz vor dem Bereitstellen in der Produktion
  • Testen von End-to-End-Systemen auf Fehlerresilienz bei automatischen Failovervorgängen
  • Testen der Auswirkungen von Failovervorgängen auf vorhandene Datenbanksitzungen
  • Überprüfen, ob ein Failover aufgrund von Änderungen bei der Netzwerklatenz die End-to-End-Leistung verändert
  • Wenn die Abfrageleistung beeinträchtigt ist, kann ein manuelles Failover in einigen Fällen die Leistungsprobleme mindern.

Hinweis

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 mit der Videoaufzeichnung Testing App Cloud Readiness for Failover Resiliency with SQL Managed Instance (Testen der App-Cloudbereitschaft für Failoverresilienz mit SQL Managed Instance).

Initiieren eines manuellen Failovers in SQL Managed Instance

Erforderliche Azure RBAC-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

PowerShell

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

Verwenden von CLI

Stellen Sie sicher, dass die neuesten CLI-Skripts installiert sind.

Verwenden Sie den CLI-Befehl „az sql mi failover“ 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“.

az sql mi failover -g myresourcegroup -n myinstancename

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

az sql mi failover -g myresourcegroup -n myinstancename --replica-type ReadableSecondary

Verwenden der REST-API

Erfahrene Benutzer, die Failovervorgänge ihrer SQL Managed Instances zur Implementierung einer Pipeline für kontinuierliche Tests oder zur automatisierten Minimierung von Leistungsproblemen automatisieren müssen, können zur Initiierung auch einen API-Aufruf verwenden. Weitere Informationen finden Sie unter SQL Managed Instances – REST-API für Failover.

Wenn Sie ein Failover über einen REST-API-Aufruf initiieren möchten, generieren Sie zunächst mithilfe eines API-Clients Ihrer Wahl das Authentifizierungstoken. Das generierte Authentifizierungstoken wird als Autorisierungseigenschaft im Header der API-Anforderung verwendet und ist obligatorisch.

Der folgende Code ist ein Beispiel für den aufzurufenden API-URI:

POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Sql/managedInstances/{managedInstanceName}/failover?api-version=2019-06-01-preview

Die folgenden Eigenschaften müssen im API-Aufruf übergeben werden:

API-Eigenschaft Parameter
subscriptionId Die ID der Subscription, in dem die Managed Instance bereitgestellt wird
resourceGroupName Die Ressourcengruppe, die die Managed Instance enthält
managedInstanceName Der Name der Managed Instance
replicaType (Optional, „Primary“ oder „ReadableSecondary“). Diese Parameter repräsentieren den Replikattyp, für den das Failover ausgeführt werden soll: primäres oder lesbares sekundäres Replikat. Wenn hier kein Wert angegeben ist, wird das Failover standardmäßig im primären Replikat initiiert.
api-version Statischer Wert und muss derzeit "2019-06-01-preview" lauten.

Die API antwortet mit einem der folgenden beiden Werte:

  • 202 Akzeptiert
  • Einer der Anforderungsfehler vom Typ 400.

Der Status des Vorgangs kann anhand der API-Antworten in Antwortheadern nachverfolgt werden. Weitere Informationen finden Sie unter Status asynchroner Vorgänge in Azure.

Überwachen des Failovers

Um den Fortschritt eines vom Benutzer initiierten Failovervorgangs für Ihre unternehmenskritische Instanz zu überwachen, führen Sie die folgende T-SQL-Abfrage in der SQL Managed Instance in Ihrem bevorzugten Client aus (z. B. in SSMS). Die Abfrage liest die Systemsicht „sys.dm_hadr_fabric_replica_states“ und meldet die in der Instanz verfügbaren Replikate. Führen Sie dieselbe Abfrage nach dem Initiieren des manuellen Failovers erneut aus.

SELECT DISTINCT replication_endpoint_url, fabric_replica_role_desc FROM sys.dm_hadr_fabric_replica_states

Vor dem Initiieren des Failovers gibt die Ausgabe das aktuelle primäre Replikat in der Dienstebene „Unternehmenskritisch“ an, die ein primäres und drei sekundäre Replikate in der Always On-Verfügbarkeitsgruppe enthält. Nach einem Failover müsste bei der erneuten Ausführung der Abfrage eine Änderung des primären Knotens angezeigt werden.

In der Dienstebene „Universell“ erhalten Sie eine andere Ausgabe als in der Dienstebene „Unternehmenskritisch“. Das liegt daran, dass die Dienstebene „Universell“ auf einem einzelnen Knoten basiert. Sie können eine alternative T-SQL-Abfrage verwenden, die den Zeitpunkt anzeigt, zu dem der SQL-Prozess auf dem Knoten für die Instanz der Dienstebene „Universell“ begonnen hat:

SELECT sqlserver_start_time, sqlserver_start_time_ms_ticks FROM sys.dm_os_sys_info

Der kurze Verlust der Konnektivität mit Ihrem Client während des Failovers, der in aller Regel weniger als eine Minute dauert, ist unabhängig von der Dienstebene ein Hinweis auf die Ausführung des Failovers.

Hinweis

Bei Workloads mit hoher Intensität kann die vollständige Ausführung eines Failovervorgangs (nicht die kurze Nichtverfügbarkeit) mehrere Minuten dauern. Das liegt daran, dass die Instanz-Engine alle aktuellen Transaktionen auf dem primären Knoten ausführen und den sekundären Knoten auf den neuesten Stand bringen muss, bevor das Failover ausgeführt werden kann.

Wichtig

Folgende funktionsbezogene Einschränkungen gelten bei vom Benutzer initiierten manuellen Failovervorgängen:

  • Auf ein und derselben SQL Managed Instance kann alle 15 Minuten immer nur ein (1) Failover initiiert werden.
  • Bei unternehmenskritischen Instanzen muss ein Quorum mit Replikaten vorhanden sein, damit die Failoveranforderung akzeptiert wird.
  • Bei unternehmenskritischen Instanzen kann nicht angegeben werden, auf welchem lesbaren sekundären Replikat das Failover initiiert werden soll.
  • Das Failover ist erst zulässig, wenn die erste vollständige Sicherung für eine neue Datenbank durch automatisierte Sicherungssysteme abgeschlossen ist.
  • Ein Failover ist nicht zulässig, wenn eine Datenbankwiederherstellung ausgeführt wird.

Nächste Schritte