Freigeben über

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

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 vom Benutzer initiiertes Failover mithilfe von PowerShell, der Azure CLI oder REST-API ausführen.

Es ist möglich, ein Failover für einen primären Knoten in den Dienstebenen „Universell“ (General Purpose, GP) und „Unternehmenskritisch“ (Business Critical, BC) durchzuführen und ein manuelles Failover für einen sekundären schreibgeschützten Replikatknoten auf der BC-Dienstebene durchzuführen.

Hinweis

Failover in diesem Artikel bezieht sich auf den Neustart des SQL Server-Datenbankmodulprozesses und ist nicht mit dem regionsübergreifenden Failover einer Failovergruppe verknüpft.

Wann manuelles Failover verwenden

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-Datenbankmodulprozess offline geschaltet und auf demselben oder einem anderen Computeknoten online gestellt wird. In der Regel werden Failover automatisch und von der Azure-Plattform verwaltet, wenn ein Fehler erkannt wird, ein Knoten beeinträchtigt wurde oder während Dienstupdates.

Der gesamte Failovervorgang besteht darin, den SQL Server-Datenbankmodulprozess online zu bringen, den Datenbankstatus zu überprüfen und dann schließlich die Clientverbindungen an den neuen SQL-Prozess 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 Engine-Prozess 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, wie sich ein Failover auf vorhandene Datenbanksitzungen auswirkt.
  • 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.
Allzweck Zonenredundanz
(Mehrere Verfügbarkeitszonen)		 Der SQL-Prozess wird auf derselben VM neu gestartet. Der SQL-Prozess wird auf einer anderenVM neu gestartet.
Geschäftskritisch Lokale Redundanz
(Einzelne Verfügbarkeitszone)		 SQL-Prozesse werden auf dem primären Replikat neu gestartet, oder ein beliebiges sekundäres Replikat wird zum primären Replikat hochgestuft. –
Geschäftskritisch Zonenredundanz
(Mehrere Verfügbarkeitszonen)		 SQL-Prozesse werden auf dem primären Replikat neu gestartet, oder ein zufälliges sekundäres Replikat wird entweder in derselben oder einer anderen Verfügbarkeitszone zum primären Replikat befördert. –

Berechtigungen

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

  • Rolle „Besitzer des Abonnements“ oder
  • Rolle 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 Instanz mit einem manuellen Failover mithilfe von PowerShell, der Azure CLI oder der REST-API 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 der sich die SQL Managed Instance befindet, auf 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 für den sekundären Knoten mit Lesezugriff ein Failover durchzuführen. Dieser Befehl gilt nur für 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.

Dienstebene für allgemeine Zwecke

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-Datenbankmodulprozess auf dem Knoten gestartet wurde, der nach jedem Failover aktualisiert wird. 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 Instanzen auf der Dienstebene „Unternehmenskritisch“:
    • Replikate müssen über ein Quorum verfügen, bevor eine Failoveranforderung akzeptiert wird.
    • Der Befehl Invoke-AzSqlInstanceFailover führt zu einem Failover für das primäre Replikat, es sei denn, -ReadableSecondary wird angegeben; in diesem Fall wird ein Failover für das lesbare sekundäre Replikat ausgeführt. Die nicht lesbaren sekundären Replikate schlagen nicht fehl, wenn dieser Befehl ausgegeben wird.

Zugehöriger Inhalt

  • Last updated on