Redémarrer une instance avec un basculement manuel initié par l’utilisateur - Azure SQL Managed Instance

S’applique à :Azure SQL Managed Instance

Cet article explique comment redémarrer Azure SQL Managed Instance en effectuant un basculement manuel initié par l’utilisateur en utilisant PowerShell, Azure CLI ou API REST.

Il est possible d’effectuer un basculement d’un nœud principal dans les niveaux de service Usage général (GP) et Critique pour l’entreprise (BC), ainsi que d’effectuer manuellement le basculement d’un nœud de réplica secondaire en lecture seule dans le niveau de service BC.

Remarque

Dans cet article, le basculement désigne le redémarrage du processus du moteur de base de données de SQL Server et n’a aucun lien avec le basculement interrégional de groupes de basculement.

Quand utiliser le basculement manuel

La disponibilité, une partie fondamentale de la plateforme SQL Managed Instance, fonctionne de manière transparente pour vos applications de base de données en fournissant des nœuds de calcul locaux en attente pour héberger le processus du moteur de base de données SQL Server. Un basculement survient lorsque le processus du moteur de base de données SQL Server est mis hors ligne puis remis en ligne sur le même nœud de calcul ou sur un autre. En général, les basculements sont automatiques et gérés par la plateforme Azure lorsqu’une défaillance est détectée, qu’un nœud s’est dégradé ou lors de mises à jour de service.

L’ensemble de l’opération de basculement consiste à mettre en ligne le processus du moteur de base de données SQL Server, valider l’état de la base de données, puis enfin rediriger les connexions clients vers le nouveau processus SQL. Les connexions de clients échouent uniquement pendant une courte période, généralement moins d’une minute, pendant la dernière étape de l’opération de basculement.

Vous pouvez effectuer un basculement manuel pour redémarrer le processus moteur pour les raisons suivantes :

  • échec ou lenteur des connexions en raison de problèmes de performances ;
  • Application de test de la résilience au basculement avant le déploiement en environnement de production.
  • Test de la résilience aux pannes des systèmes de bout en bout lors de basculements automatiques.
  • Tester l’impact du basculement sur les sessions de base de données existantes.
  • détérioration des performances des requêtes (le redémarrage de l’instance peut aider à atténuer le problème de performances).

Veiller à ce que vos applications soient résilientes en cas de basculement avant leur déploiement en production contribue à atténuer le risque de défaillances applicatives en production et à garantir la disponibilité de vos applications pour vos clients. Pour en savoir plus sur le test de vos applications pour la préparation au cloud, regardez la vidéo suivante :

Le tableau suivant décrit le comportement attendu de SQL Managed Instance pendant une opération de basculement basée sur le niveau de service et le modèle de disponibilité :

Niveau de service Modèle de disponibilité Comportement de basculement attendu Comportement potentiel de basculement (exceptions)
Usage général Redondance locale
(Zone de disponibilité unique)		 Le processus SQL redémarre sur la même machine virtuelle. Le processus SQL redémarre sur une autre machine virtuelle.
Usage général Redondance de zone
(Plusieurs zones de disponibilité)		 Le processus SQL redémarre sur la même machine virtuelle. Le processus SQL redémarre sur une autre machine virtuelle.
Critique pour l’entreprise Redondance locale
(Zone de disponibilité unique)		 Le processus SQL redémarre sur la réplique primaire, ou une réplique secondaire aléatoire est promue en réplique primaire. N/A
Critique pour l’entreprise Redondance de zone
(Plusieurs zones de disponibilité)		 Le processus SQL redémarre sur la réplique primaire, ou une réplique secondaire aléatoire est promue en principale, soit dans la même zone de disponibilité ou dans une zone différente. N/A

autorisations

Les utilisateurs qui initient un basculement doivent disposer de l’un des rôles Azure suivants :

  • rôle de propriétaire de l’abonnement, ou
  • Rôle Collaborateur SQL Managed Instance ou
  • Rôle personnalisé avec l’autorisation suivante :
    • Microsoft.Sql/managedInstances/failover/action

Redémarrer une instance par basculement manuel

Vous pouvez redémarrer une instance en effectuant un basculement manuel à l’aide de PowerShell, d’Azure CLI ou de l’API REST.

La version minimale d’Az.Sql doit être la v2.9.0. Envisagez d’utiliser Azure Cloud Shell du portail Azure, qui dispose toujours de la dernière version de PowerShell disponible.

Comme condition préalable, utilisez le script PowerShell suivant pour installer les modules Azure requis. En outre, sélectionnez l’abonnement où se trouve la Managed Instance SQL sur laquelle vous souhaitez basculer.

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

Connect-AzAccount
Select-AzSubscription -SubscriptionId $subscription

Utilisez la commande PowerShell Invoke-AzSqlInstanceFailover, comme dans l’exemple suivant, pour initier le basculement du nœud principal, applicable aux niveaux de service BC et GP.

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

Utilisez la commande PowerShell suivante pour basculer le nœud secondaire de lecture, applicable uniquement au niveau de service BC.

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

Surveiller le basculement

Le suivi de la progression d’un basculement initié par l’utilisateur est différent selon les instances des niveaux de service Critique pour l’entreprise et Usage général.

Pour surveiller la progression d’un basculement initié par l’utilisateur, utilisez :

  • sys.dm_os_sys_info pour vérifier le temps d’activité du système pour le niveau de service Usage général.
  • sys.dm_hadr_fabric_replica_states pour vérifier les répliques disponibles pour le niveau de service Business Critical.

La dernière étape du processus de basculement est la redirection des connexions de clients vers le nouveau nœud principal. La brève perte de connectivité de votre client pendant le basculement, qui dure généralement moins d’une minute, indique que le basculement a réussi, quel que soit le niveau de service.

Niveau de service à usage général

L’exemple T-SQL suivant montre le temps d’activité du processus SQL sur le nœud pour le niveau de service Usage général :

SELECT sqlserver_start_time, sqlserver_start_time_ms_ticks FROM sys.dm_os_sys_info

L’heure de début du processus SQL correspond au moment où le moteur de base de données SQL Server a été lancé sur le nœud, qui se met à jour après chaque basculement. Exécutez cette requête avant et après avoir lancé un basculement d’une instance dans le niveau de service Usage général pour surveiller la progression de l’opération de basculement.

Niveau de service Critique pour l’entreprise

L’exemple T-SQL suivant indique quel nœud est actuellement le réplica principal du niveau de service Critique pour l’entreprise :

SELECT DISTINCT replication_endpoint_url, fabric_replica_role_desc FROM sys.dm_hadr_fabric_replica_states

Le nœud qui héberge le réplica principal change une fois le basculement terminé. Exécutez cette requête avant et après avoir lancé un basculement d’une instance dans le niveau de service Critique pour l’entreprise pour surveiller la progression de l’opération de basculement.

Remarque

Le processus de basculement complet peut prendre plusieurs minutes pour les charges de travail à haute intensité, car le moteur d’instance garantit que les transactions sur le nœud secondaire ont rattrapé le retard par rapport aux transactions du nœud principal avant de lancer le basculement.

Limites

Prenez en compte les limitations fonctionnelles suivantes des basculements manuels initiés par l’utilisateur :

  • Un (1) seul basculement peut être initié sur la même instance SQL Managed Instance toutes les 15 minutes.
  • Les basculements ne sont pas autorisés :
    • tant que la première sauvegarde complète d’une nouvelle base de données n’est pas terminée par les systèmes de sauvegarde automatisée ; et
    • s’il y a une restauration de base de données en cours.
  • Pour les instances dans le niveau de service Critique pour l’entreprise :
    • Les répliques doivent avoir un quorum avant qu’une demande de basculement ne soit acceptée.
    • La Invoke-AzSqlInstanceFailover commande échoue sur la réplique primaire sauf indication -ReadableSecondary contraire, auquel cas la réplique secondaire lisible bascule. Les répliques secondaires non lisibles ne basculent pas lors de l’émission de cette commande.

Contenu connexe

  • Last updated on