Partage via

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

  • Article

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 vers un nœud de calcul secondaire à l’aide de PowerShell, d’Azure CLI ou de l’API REST.

Il est possible de basculer un nœud principal sur des niveaux de service Usage général (GP) et Critique pour l’entreprise (BC), et de basculer manuellement un nœud de réplica secondaire en lecture seule sur le niveau de service BC.

Remarque

Dans cet article, le basculement fait référence au démarrage du processus du moteur de base de données SQL Server sur un nœud secondaire et n’est pas lié au basculement inter-région d’un groupe 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 se produit lorsque le processus du moteur de base de données SQL Server est mis hors connexion sur le nœud de calcul principal et mis en ligne sur un nœud de calcul secondaire. En règle générale, les basculements entre les nœuds de calcul SQL Managed Instance sont automatiques et gérés par la plateforme lorsqu’une erreur est détectée, un nœud s’est dégradé ou pendant les mises à jour de logiciels mensuelles régulières.

Toute l’opération de basculement consiste à mettre en ligne le processus du moteur de base de données SQL Server sur un nœud secondaire, en validant l’état de la base de données, puis en redirigeant les connexions de clients vers le nouveau nœud principal. 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 exécuter un basculement manuel pour redémarrer le processus du moteur sur un autre nœud pour les raisons suivantes :

  • échec ou lenteur des connexions en raison de problèmes de performances ;
  • test de la résilience du basculement pour l’application avant le déploiement en production ;
  • test de la résilience aux erreurs pour les systèmes de bout en bout en cas de basculement automatique ;
  • test de l’impact du basculement sur les sessions de base de données existantes ; et
  • détérioration des performances des requêtes (le redémarrage de l’instance peut aider à atténuer le problème de performances).

En vous assurant que vos applications bénéficient d’un basculement résilient avant le déploiement en production, vous atténuez le risque d’erreurs d’application en production et contribuez à la disponibilité des 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 de basculement potentiel (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 (préversion)
(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 réplica secondaire aléatoire est promu en réplica principal. S/O
Critique pour l’entreprise Redondance de zone
(Plusieurs zones de disponibilité)		 Le réplica secondaire aléatoire est promu en réplica principal, dans la même zone de disponibilité ou dans une zone de disponibilité différente. S/O

Autorisations

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

  • Rôle 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 avec un basculement manuel

Vous pouvez redémarrer une instance avec 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 avec l’exemple suivant pour lancer le basculement du nœud principal, applicable à la fois 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

La surveillance de la progression d’un basculement initié par l’utilisateur diffère pour les instances de 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éplicas disponibles pour le niveau de service Critique pour l’entreprise.

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 est l’heure de démarrage du processus du moteur de base de données SQL Server sur le nœud. Le temps est réinitialisé 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 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 les modifications du réplica principal 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 de niveau de service Critique pour l’entreprise :
    • il doit exister un quorum de réplicas pour que la requête de basculement soit acceptée.
    • Il n’est pas possible de spécifier le réplica secondaire accessible en lecture sur lequel initier le basculement.

Contenu connexe