Vue d’ensemble des groupes de basculement automatique et meilleures pratiques (Azure SQL Managed Instance)

S’applique à :Azure SQL Managed Instance

Cet article fournit une vue d’ensemble de la fonctionnalité de groupe de basculement avec les meilleures pratiques et recommandations à utiliser avec Azure SQL Managed Instance. La fonctionnalité groupes de basculement vous permet de gérer la réplication et le basculement de toutes les bases de données utilisateur d’une instance managée SQL vers une autre région Azure.

Pour commencer, consultez Configurer un groupe de basculement pour Azure SQL Managed Instance.

Vue d’ensemble

La fonctionnalité groupes de basculement vous permet de gérer la réplication et le basculement des bases de données utilisateur d’une instance managée SQL vers une autre instance managée SQL dans une autre région Azure. Les groupes de basculement sont conçus pour simplifier le déploiement et la gestion des bases de données géorépliquées à grande échelle.

Pour plus d’informations, consultez Haute disponibilité pour Azure SQL Managed Instance. Pour effectuer un géobasculement des données d’objectif de point (RPO) et de délai de récupération (RTO), consultez vue d’ensemble de la continuité d’activité.

Redirection de point de terminaison

Les groupes de basculement fournissent des points de terminaison d'écouteur de lecture-écriture et de lecture seule qui restent inchangés pendant les géobasculements. Vous ne devez pas modifier la chaîne de connexion de votre application après un géobasculement, car les connexions sont automatiquement acheminées vers la base de données primaire actuelle. Un géobasculement bascule toutes les bases de données secondaires du groupe dans le rôle principal. Une fois que le géobasculement se complète, l’enregistrement DNS est automatiquement mis à jour pour rediriger les points de terminaison vers la nouvelle région.

Déplacer des charges de travail en lecture seule

Pour réduire le trafic vers vos bases de données primaires, vous pouvez également utiliser les bases de données secondaires dans un groupe de basculement pour décharger les charges de travail en lecture seule. Utilisez l'écouteur en lecture seule pour diriger le trafic en lecture seule vers une base de données secondaire lisible.

Récupération d’une application

Pour arriver à une continuité d’activité totale, l’ajout d’une redondance de base de données régionale n’est qu’une partie de la solution. La récupération d’une application (service) de bout en bout après une défaillance catastrophique implique la récupération de tous les composants constituant le service et tous les services dépendants. En voici quelques exemples : logiciel client (il peut s’agir par exemple d’un navigateur avec un code JavaScript personnalisé), serveurs web frontaux, ressources de stockage et DNS. Il est essentiel que tous les composants résistent aux mêmes défaillances et redeviennent disponibles dans l’objectif de délai de récupération (RTO) de votre application. Par conséquent, vous devez identifier tous les services dépendants et comprendre les garanties et les fonctionnalités qu’ils fournissent. Ensuite, vous devez prendre les mesures appropriées pour vous assurer que votre service fonctionne pendant le basculement des services dont il dépend.

Stratégie de basculement

Les groupes de basculement prennent en charge deux stratégies de basculement :

• Client géré (recommandé) - Les clients peuvent effectuer un basculement d’un groupe lorsqu’ils remarquent une panne inattendue impactant une ou plusieurs bases de données dans le groupe de basculement. Lorsque vous utilisez des outils en ligne de commande tels que PowerShell, Azure CLI ou l’API Rest, la valeur de la stratégie de basculement pour le client géré est manual.
• Géré par Microsoft : en cas de panne généralisée qui a un impact sur une région primaire, Microsoft lance le basculement de tous les groupes de basculement affectés dont la stratégie de basculement est configurée pour être gérée par Microsoft. Le basculement géré par Microsoft ne sera pas lancé pour des groupes de basculement individuels ou un sous-ensemble de groupes de basculement dans une région. Lorsque vous utilisez des outils en ligne de commande tels que PowerShell, Azure CLI ou l’API Rest, la valeur de la stratégie de basculement pour géré par Microsoft est automatic.

Chaque stratégie de basculement a un ensemble unique de cas d’usage et des attentes correspondantes sur l’étendue de basculement et la perte de données, comme le tableau suivant récapitule :

Managée par le client

Dans de rares cas, la disponibilité intégrée ou la haute disponibilité n’est pas suffisante pour atténuer une panne, et vos bases de données dans un groupe de basculement peuvent ne pas être disponibles pendant une durée qui n’est pas acceptable pour le contrat de niveau de service (SLA) des applications qui utilisent les bases de données. Les bases de données peuvent être indisponibles en raison d’un problème localisé qui n’a qu’un impact sur quelques bases de données, ou peut être au niveau du centre de données, de la zone de disponibilité ou de la région. Dans l’un de ces cas, pour restaurer la continuité d’activité, vous pouvez lancer un basculement forcé.

La définition de votre stratégie de basculement sur gérée par le client est vivement recommandée, car elle vous permet de contrôler quand lancer un basculement et restaurer la continuité d’activité. Vous pouvez lancer un basculement lorsque vous remarquez une panne inattendue impactant une ou plusieurs bases de données dans le groupe de basculement.

Géré par Microsoft

Avec une stratégie de basculement géré par Microsoft, la responsabilité de la récupération d’urgence est déléguée au service Azure SQL. Pour que le service Azure SQL lance un basculement forcé, les conditions suivantes doivent être remplies :

• Une panne au niveau de la région causée par un événement de sinistre naturel, des modifications de configuration, des bogues logiciels ou des défaillances de composants matériels et de nombreuses bases de données de la région sont affectées.
• La période de grâce a expiré. Étant donné que la vérification de l’ampleur de la panne et son atténuation dépendent des actions humaines, la période de grâce ne peut pas être inférieure à une heure.

Lorsque ces conditions sont remplies, le service Azure SQL lance des basculements forcés pour tous les groupes de basculement de la région dont la stratégie de basculement est définie sur Microsoft gérée.

Définissez la stratégie de basculement sur Microsoft gérée uniquement quand :

• Vous souhaitez déléguer la responsabilité de récupération d’urgence au service Azure SQL.
• L’application est tolérante à l’indisponibilité de votre base de données pendant au moins une heure ou plusieurs.
• Il est acceptable de déclencher des basculements forcés un certain temps après l’expiration de la période de grâce, car le temps réel du basculement forcé peut varier considérablement.
• Il est acceptable que toutes les bases de données au sein du groupe de basculement basculent, quelle que soit leur configuration de redondance de zone ou leur état de disponibilité. Bien que les bases de données configurées pour la redondance de zone soient résilientes aux défaillances zonales et puissent ne pas être affectées par une panne, elles seront toujours en échec si elles font partie d’un groupe de basculement avec une stratégie de basculement gérée par Microsoft.
• Il est acceptable d’avoir des basculements forcés de bases de données dans le groupe de basculement sans tenir compte de la dépendance de l’application à d’autres services ou composants Azure utilisés par l’application, ce qui peut entraîner une détérioration des performances ou une indisponibilité de l’application.
• Il est acceptable d’encourir une quantité inconnue de perte de données, car l’heure exacte du basculement forcé ne peut pas être contrôlée et ignore l’état de synchronisation des bases de données secondaires.
• Les réplicas principaux et secondaires du groupe de basculement ont le même niveau de service, le niveau de calcul et la même taille de calcul.

Lorsqu’un basculement est déclenché par Microsoft, une entrée pour le nom de l’opération Basculement du groupe de basculement Azure SQL est ajouté au journal d’activité Azure Monitor. L’entrée inclut le nom du groupe de basculement sous Ressource et Événement lancé par un seul trait d’union (-) pour indiquer que le basculement a été lancé par Microsoft. Ces informations sont également disponibles dans la page Journal d’activité du nouveau serveur principal ou instance du Portail Azure.

Terminologie et fonctionnalités

• Groupe de basculement (FOG)

  Un groupe de basculement permet à toutes les bases de données utilisateur au sein d’une instance managée SQL de basculer en tant qu’unité vers une autre région Azure si l’instance managée SQL principale devient indisponible en raison d’une panne de région primaire. Comme les groupes de basculement pour SQL Managed Instance contiennent toutes les bases de données utilisateur dans l'instance, un seul groupe de basculement peut être configuré sur une instance.

  Important

  Le nom du groupe de basculement doit être unique à l’échelle globale dans le domaine .database.windows.net.

• Primaire

  Instance managée SQL qui héberge les bases de données principales dans le groupe de basculement.

• Secondaire

  L'instance managée SQL qui héberge les bases de données secondaires dans le groupe de basculement. Le serveur logique secondaire ne peut pas être situé dans la même région Azure que le serveur logique primaire.

  Important

  Si une base de données contient des objets OLTP en mémoire, l’instance de géo-réplica primaire et secondaire doivent avoir des niveaux de service correspondants, car les objets OLTP en mémoire résident toujours en mémoire. Un niveau de service inférieur sur l’instance géo-réplica peut entraîner des problèmes de manque de mémoire. Si cela se produit, le réplica secondaire pourrait ne pas récupérer la base de données, ce qui entraîne l’indisponibilité de la base de données secondaire, ainsi que des objets OLTP en mémoire sur la base de données géo-secondaire. Cela pourrait ensuite entraîner l’échec du basculement. Pour éviter cela, assurez-vous que le niveau de service de l’instance géo-secondaire correspond à celui de la base de données primaire. Les mises à niveau des niveaux de service peuvent être des opérations dépendant de la taille des données, et peuvent prendre un certain temps.

• Basculement (aucune perte de données)

  Le basculement effectue une synchronisation de données complète entre les bases de données primaire et secondaire avant que la seconde ne bascule dans le rôle primaire. Cela empêche toute perte de données. Le basculement n’est possible que lorsque le serveur principal est accessible. Le basculement des appareils est utilisé dans les scénarios suivants :

  • Simuler des récupérations d’urgence (DR) en production lorsque la perte de données n’est pas acceptable
  • Déplacer la charge de travail vers une autre région
  • Renvoyer la charge de travail vers la région primaire une fois la panne éliminée (restauration automatique)

• Basculement forcé (perte de données potentielle)

  Le basculement forcé bascule immédiatement la base de données secondaire vers le rôle primaire sans attendre que les modifications récentes soient propagées à partir de la base de données primaire. Cette opération peut occasionner une perte de données potentielle. Le basculement forcé est utilisé comme méthode de récupération pendant les pannes, lorsque la base de données primaire n’est pas accessible. Lorsque la panne est atténuée, l’ancienne base de données primaire se reconnecte automatiquement et devient une nouvelle base de données secondaire. Un basculement peut être exécuté pour la restauration automatique, en retournant les réplicas à leurs rôles primaires et secondaires d’origine.

• Période de grâce avec perte de données

  Étant donné que les données sont répliquées vers la base de données secondaire à l’aide d’une réplication asynchrone, le basculement forcé de groupes avec des stratégies de basculement gérés par Microsoft peut entraîner une perte de données. Vous pouvez personnaliser la stratégie de basculement en fonction de la tolérance de votre application à la perte de données. En configurant GracePeriodWithDataLossHours, vous pouvez contrôler le délai observé par le service Azure SQL avant d’initier un basculement forcé qui peut entraîner une perte de données.

• Zone DNS

  ID unique qui est généré automatiquement lorsqu’une instance SQL Managed Instance est créée. Un certificat multidomaine (SAN) est approvisionné pour cette instance afin d’authentifier les connexions clientes effectuées auprès de toutes les instances présentes dans la même zone DNS. Les deux instances managées SQL du même groupe de basculement doivent partager la zone DNS.

• Écouteur en lecture-écriture du groupe de basculement

  Un enregistrement DNS CNAME qui pointe vers le serveur primaire actuel. Il est généré automatiquement lorsque le groupe de basculement est créé, et permet à la charge de travail en lecture-écriture de se reconnecter en toute transparence au serveur primaire une fois modifié après le basculement. Lorsque le groupe de basculement est créé sur une instance SQL managée, un enregistrement CNAME DNS est créé pour l’URL du listener, sous la forme de <fog-name>.<zone_id>.database.windows.net.

• Écouteur en lecture seule du groupe de basculement

  Un enregistrement DNS CNAME qui pointe vers le serveur secondaire actuel. Il est créé automatiquement lorsque le groupe de basculement est créé et permet à la charge de travail SQL en lecture seule de se connecter en toute transparence au serveur secondaire une fois modifié après le basculement. Lorsque le groupe de basculement est créé sur une instance SQL managée, un enregistrement CNAME DNS est créé pour l’URL du listener, sous la forme de <fog-name>.secondary.<zone_id>.database.windows.net. Par défaut, le basculement de l’écouteur en lecture seule est désactivé, car il garantit que les performances du serveur principal ne sont pas affectées lorsque le serveur secondaire est hors connexion. Toutefois, cela signifie également que les sessions en lecture seule ne sont pas en mesure de se connecter tant que le serveur secondaire n’a pas été récupérée. Si vous ne pouvez pas tolérer des temps d’arrêt pour les sessions en lecture seule et que vous pouvez utiliser le serveur principal pour le trafic en lecture seule et en lecture-écriture au prix d’une dégradation potentielle des performances du serveur principal, vous pouvez activer le basculement pour l’écouteur en lecture seule en configurant la propriété AllowReadOnlyFailoverToPrimary. Dans ce cas, le trafic en lecture seule est automatiquement redirigé vers le serveur principal si le serveur secondaire est indisponible.

  Remarque

  La propriété AllowReadOnlyFailoverToPrimary n’a d’effet que si la stratégie de basculement gérée par Microsoft est activée et qu’un basculement forcé a été déclenché. Dans ce cas, si la propriété a la valeur True, le nouveau serveur primaire gère à la fois les sessions en lecture-écriture et en lecture seule.

Architecture du groupe de basculement

Le groupe de basculement doit être configuré sur l'instance principale et doit être connecté à l'instance secondaire dans une autre région Azure. Toutes les bases de données utilisateur sur l’instance principale sont répliquées vers l’instance secondaire. Les bases de données système comme master et msdb ne sont pas répliquées.

Le diagramme suivant illustre une configuration classique d’une application cloud géoredondante à l’aide d’une instance managée SQL et d’un groupe de basculement :

Si votre application utilise SQL Managed Instance comme niveau de données, suivez les directives générales et les meilleures pratiques décrites dans cet article lors de la conception des éléments en rapport avec la continuité d’activité.

Créer l’instance géosecondaire

Pour garantir une connectivité ininterrompue à l’instance managée SQL principale après le basculement, les instances primaires et secondaires doivent se trouver dans la même zone DNS. Cela garantit que le même certificat multidomaine (SAN) peut être utilisé pour authentifier les connexions clientes avec les deux instances du groupe de basculement. Lorsque votre application est prête pour le déploiement en production, créez une instance SQL Managed Instance secondaire dans une autre région et assurez-vous qu’elle partage la même zone DNS que l’instance SQL Managed Instance principale. Vous pouvez le faire en spécifiant un paramètre facultatif lorsque vous créez l’instance. Si vous utilisez PowerShell ou l’API REST, le nom du paramètre facultatif est DNSZonePartner. Le nom du champ facultatif correspondant dans le portail Azure est Instance managée principale.

Pour plus d’informations sur la création de l’instance SQL Managed Instance secondaire dans la même zone DNS que l’instance principale, consultez Configurer un groupe de basculement pour Azure SQL Managed Instance.

Utiliser des régions jumelées

Déployez les deux instances managées SQL dans des régions jumelées pour des raisons de performances. Les groupes de basculement SQL Managed Instance dans les régions jumelées offrent de meilleures performances par rapport aux régions non jumelées.

Azure SQL Managed Instance se conforme à une pratique de déploiement sécurisée qui garantit généralement que des régions Azure jumelées ne sont pas déployées en même temps. Toutefois, il n’est pas possible de prédire la région mise à niveau en premier, de sorte que l’ordre du déploiement n’est pas garanti. Parfois, votre instance principale est mise à niveau en premier, et parfois l’instance secondaire est mise à niveau en premier.

Dans les situations où Azure SQL Managed Instance fait partie d’un groupe de basculement et où les instances du groupe ne se trouvent pas dans des régions jumelées Azure, sélectionnez différentes planifications de fenêtres de maintenance pour votre base de données principale et secondaire. Par exemple, vous pouvez choisir une fenêtre de maintenance Jour ouvrable pour votre base de données géosecondaire et une fenêtre de maintenance Week-end pour votre base de données géoprimaire.

Activer et optimiser le flux de trafic de géoréplication entre les instances

La connectivité entre les sous-réseaux de réseau virtuel hébergeant l’instance primaire et secondaire doit être établie et maintenue pour un flux de trafic géoréplication ininterrompu. Il existe plusieurs façons de fournir une connectivité entre les instances que vous pouvez choisir en fonction de la topologie et des stratégies de votre réseau :

• Appairage global de réseaux virtuels
• Passerelles VPN
• Azure ExpressRoute

L’appairage mondial de réseaux virtuels (VNet Peering) est la méthode recommandée pour établir la connectivité entre deux instances dans un groupe de basculement. Il fournit une connexion privée à faible latence et à bande passante élevée entre les réseaux virtuels appairés à l’aide de l’infrastructure principale de Microsoft. Aucun chiffrement supplémentaire, aucune connexion Internet publique, ni passerelle ne sont nécessaires pour que les réseaux virtuels appairés communiquent.

Amorçage initial

Lors de l’établissement d’un groupe de basculement entre des instances SQL managées, une phase d’amorçage initiale est nécessaire avant le démarrage de la réplication des données. La phase d’amorçage initiale est la partie de l’opération la plus longue et la plus coûteuse. Une fois l’amorçage initial terminé, les données sont synchronisées et seules les modifications de données suivantes sont répliquées. Le temps nécessaire à l’amorçage initial dépend de la taille des données, du nombre de bases de données répliquées, de l’intensité de la charge de travail sur les bases de données primaires et de la vitesse du lien entre les réseaux virtuels qui hébergent l’instance principale et secondaire, qui dépend principalement de la façon dont la connectivité est établie. Dans des circonstances normales et lorsque la connectivité est établie à l’aide du peering de réseaux virtuels globaux recommandé, la vitesse d’amorçage est de 360 Go par heure pour SQL Managed Instance. L’amorçage est effectué pour un lot de bases de données utilisateur en parallèle, mais pas nécessairement pour toutes les bases de données en même temps. Plusieurs lots peuvent être nécessaires s’il existe de nombreuses bases de données hébergées sur l’instance.

Si la vitesse de la liaison entre les deux instances est plus lente que nécessaire, la durée de l’amorçage risque d’être sensiblement affectée. Vous pouvez utiliser la vitesse d’amorçage indiquée, le nombre de bases de données, la taille totale des données et la vitesse de liaison pour estimer la durée pendant laquelle la phase d’amorçage initiale prend avant le démarrage de la réplication des données. Par exemple, pour une base de données unique de 100 Go, la phase d’amorçage initiale prendra environ 1,2 heure si la liaison est capable d’envoyer (push) 84 Go par heure, et si aucune autre base de données n’est en cours d’amorçage. Si la liaison ne peut transférer que 10 Go par heure, l’amorçage d’une base de données de 100 Go prendra environ 10 heures. S’il existe plusieurs bases de données à répliquer, l’amorçage est exécuté en parallèle. Lorsqu’elle est combinée à une vitesse de liaison lente, la phase initiale d’amorçage peut prendre beaucoup plus de temps, en particulier si l’amorçage parallèle de données de toutes les bases de données dépasse la bande passante de liaison disponible.

Gérer le géobasculement dans une instance géosecondaire

Le groupe de basculement gère le géo-basculement de toutes les bases de données sur l’instance SQL principale gérée. Lorsqu’un groupe est créé, chaque base de données sur l’instance est automatiquement géorépliquée vers l’instance géo-secondaire. Vous ne pouvez pas utiliser les groupes de basculement pour lancer le basculement partiel d’un sous-ensemble de bases de données.

Utiliser l’écouteur en lecture-écriture (instance managée principale)

Pour les charges de travail en lecture-écriture, utilisez <fog-name>.zone_id.database.windows.net comme nom de serveur. Les connexions sont automatiquement dirigées vers la base de données primaire. Ce nom ne change pas après le basculement. Le géo-basculement implique la mise à jour de l’enregistrement DNS. Les nouvelles connexions clients sont donc routées vers le nouveau serveur principal uniquement après actualisation du cache DNS client. Étant donné que l’instance secondaire partage la même zone DNS que l’instance principale, l’application cliente peut se reconnecter à l’aide du même certificat SAN côté serveur. Les connexions clientes existantes doivent être arrêtées, puis recréées pour être acheminées vers le nouveau serveur principal. L’écouteur en lecture-écriture et l’écouteur en lecture seule ne peuvent pas être atteints via le point de terminaison public pour l’instance managée SQL.

Utiliser l'écouteur en lecture seule (instance managée secondaire)

Si vous avez des charges de travail en lecture seule isolées logiquement qui sont tolérantes à la latence des données, vous pouvez les exécuter sur l’instance géosecondaire. Pour vous connecter directement à l’instance géosecondaire, utilisez <fog-name>.secondary.<zone_id>.database.windows.net comme nom de serveur.

Dans le niveau Critique pour l’entreprise, SQL Managed Instance prend en charge l’utilisation de réplicas en lecture seule pour décharger des charges de travail de requête en lecture seule, en utilisant le paramètre ApplicationIntent=ReadOnly dans la chaîne de connexion. Lorsque vous avez configuré une instance géorépliquée secondaire, vous pouvez utiliser cette fonction pour vous connecter à un réplica en lecture seule à l’emplacement primaire ou à l’emplacement géorépliqué :

• Pour vous connecter à un réplica en lecture seule à l’emplacement primaire, utilisez ApplicationIntent=ReadOnly et <fog-name>.<zone_id>.database.windows.net.
• Pour vous connecter à un réplica en lecture seule à l’emplacement secondaire, utilisez ApplicationIntent=ReadOnly et <fog-name>.secondary.<zone_id>.database.windows.net.

L’écouteur en lecture-écriture et l’écouteur en lecture seule ne peuvent pas être atteints via le point de terminaison public pour l’instance managée SQL.

Dégradation potentielle des performances après le basculement

Une application Azure classique fait appel à plusieurs services Azure et inclut plusieurs composants. Le géobasculement du groupe de basculement est déclenché en fonction de l’état des seuls composants Azure SQL. Une panne peut ne pas affecter d’autres services Azure dans la région primaire, et leurs composants peuvent toujours être disponibles dans cette région. Une fois que les bases de données primaires ont basculé vers la région secondaire, la latence entre les composants dépendants peut augmenter. Assurez la redondance de tous les composants de l'application dans la région secondaire et basculez les composants de l'application ainsi que la base de données, afin qu'une latence interrégionale élevée n'affecte pas les performances de l'application.

Perte potentielle de données après un basculement forcé

Si une panne se produit dans la région primaire, les transactions récentes n’ont peut-être pas été répliquées sur le site géo-secondaire, et il peut y avoir une perte de données si un basculement forcé est effectué.

Mise à jour DNS

La mise à jour DNS de l’écouteur en lecture-écriture se produit immédiatement après que le basculement est initié. Cette opération n’entraîne pas de perte de données. Toutefois, le processus de basculement des rôles de base de données peut prendre jusqu’à cinq minutes dans des conditions normales. En attendant, certaines bases de données de la nouvelle instance principale resteront en lecture seule. Si un basculement est initié à l’aide de PowerShell, l’opération permettant de basculer le rôle de réplica principal est synchrone. S’il est initié à l’aide du portail Azure, l’interface utilisateur indique la progression. S’il est démarré via l’API REST, utilisez le mécanisme d’interrogation standard d’Azure Resource Manager pour en surveiller la progression.

Faites des économies avec un réplica DR (reprise d’activité après sinistre) sans licence

Vous pouvez économiser sur les coûts de licence SQL Server en configurant votre instance managée SQL secondaire à utiliser uniquement pour la récupération d’urgence . Pour réaliser cette configuration, consultez Configurer un réplica en attente sans licence pour Azure SQL Managed Instance.

Tant que l’instance secondaire n’est pas utilisée pour les charges de travail en lecture, Microsoft vous fournit gratuitement un nombre de vCores correspondant à l’instance principale. Vous êtes toujours facturé pour le calcul et le stockage utilisés par l’instance secondaire. Les groupes de basculement prennent en charge une seule réplique, qui doit être soit une réplique lisible, soit désignée comme une réplique réservée à la récupération d'urgence.

Activer les scénarios dépendant des objets des bases de données système

Les bases de données système ne sont pas répliquées vers l’instance secondaire dans un groupe de basculement. Pour activer les scénarios qui dépendent des objets des bases de données système, veillez à créer les mêmes objets sur l’instance secondaire. Conservez-les synchronisés avec l’instance principale.

Par exemple, si vous envisagez d’utiliser les mêmes connexions sur l’instance secondaire, veillez à les créer avec la même valeur SID.

-- Code to create login on the secondary instance
CREATE LOGIN foo WITH PASSWORD = '<enterStrongPasswordHere>', SID = <login_sid>;

Pour en savoir plus, consultez Réplication des connexions et des tâches de l’agent.

Synchronisation des propriétés des instances et des instances de stratégies de rétention

Les instances d’un groupe de basculement restent séparées des ressources Azure et aucune modification apportée à la configuration de l’instance principale n’est automatiquement répliquée vers l’instance secondaire. Veillez à effectuer toutes les modifications pertinentes sur l’instance principale et secondaire. Par exemple, si vous modifiez la redondance du stockage de sauvegarde ou la stratégie de rétention de sauvegarde à long terme sur l’instance principale, veillez également à la modifier sur l’instance secondaire.

Mettre à l’échelle les instances

La configuration de votre instance principale et secondaire doit être la même. Cela inclut la taille de calcul, la taille de stockage et le niveau de service. Si vous devez modifier la configuration de votre groupe de basculement, vous pouvez le faire en mettant à l’échelle chaque instance vers la même configuration en conséquence. Pour en savoir plus, consultez les instances de mise à l’échelle dans un groupe de basculement.

Empêcher la perte de données critiques

En raison de la latence élevée des réseaux étendus, la géoréplication utilise un mécanisme de réplication asynchrone. La réplication asynchrone rend la possibilité de perte de données inévitable en cas de défaillance de la base de données primaire. Pour savoir comment protéger vos données, passez en revue Empêcher la perte de données.

État du groupe de basculement

Le groupe de basculement rapporte son état en décrivant l'état actuel de la réplication des données :

• Amorçage : l’amorçage initial a lieu une fois le groupe de basculement créé, jusqu’à ce que toutes les bases de données utilisateur soient initialisées sur l’instance secondaire. Le basculement ne peut pas être lancé alors que le groupe de basculement est dans l’état d’amorçage , car les bases de données utilisateur ne sont pas encore copiées dans l’instance secondaire.
• Synchronisation en cours : statut habituel du groupe de basculement. Cela signifie que les modifications de données sur l’instance principale sont répliquées de façon asynchrone sur l’instance secondaire. Cet état ne garantit pas que les données sont entièrement synchronisées à tout moment. Il peut y avoir des modifications de données de la base de données primaire qui doivent toujours être répliquées vers la base de données secondaire en raison de la nature asynchrone du processus de réplication entre les instances d’un groupe de basculement. Les basculements automatiques et manuels peuvent être lancés lorsque le groupe de basculement est à l'état de synchronisation.
• Basculement en cours : cet état indique que le basculement lancé automatiquement ou manuellement est en cours. Aucune modification du groupe de basculement ou des basculements supplémentaires ne peuvent être lancés pendant que le groupe de basculement est dans cet état.

Restauration automatique

Lorsque des groupes de basculement sont configurés avec une stratégie de basculement gérée par Microsoft, le basculement forcé vers le serveur géo-secondaire est lancé lors d’un scénario de sinistre conformément à la période de grâce définie. La restauration automatique vers l’ancien serveur principal doit être lancée manuellement.

Interopérabilité des fonctionnalités

Sauvegardes

Une sauvegarde complète est effectuée dans les scénarios suivants :

• Avant le démarrage de l’amorçage initial, lors de la création d’un groupe de basculement.
• Après un basculement.

Une sauvegarde complète est une taille d’opération de données qui ne peut pas être ignorée ou différée, et peut prendre un certain temps. Le temps nécessaire à son exécution dépend de la taille des données, du nombre de bases de données et de l’intensité de la charge de travail sur les bases de données primaires. Une sauvegarde complète peut retarder significativement l’amorçage initial, et peut retarder ou empêcher une opération de basculement sur une nouvelle instance peu après un basculement.

Tenez compte des éléments suivants :

• Les bases de données hébergées sur l’instance secondaire d’un groupe de basculement ne sont pas sauvegardées tant que cette instance ne devient pas principale après un basculement ou tant que le groupe de basculement n’est pas supprimé.
• Une fois qu’une base de données passe au rôle principal après un basculement ou devient autonome une fois qu’un groupe de basculement est supprimé, une sauvegarde complète de la base de données est automatiquement lancée pour faciliter les restaurations à un point dans le temps.
• Une base de données ne peut pas être restaurée à partir d'une instance vers un point dans le temps où cette instance était une réplique secondaire dans un groupe de basculement. Pour effectuer une restauration à un point dans le temps, vous devez restaurer la base de données à partir de l’instance qui était primaire pendant ce point dans le temps.
• Pour recréer un groupe de basculement supprimé sur la même paire d'instances managées SQL, toutes les bases de données utilisateur doivent être retirées de l'instance secondaire prévue après la suppression du groupe de basculement. Une base de données est entièrement supprimée une fois que toutes les opérations de sauvegarde en attente sont terminées, y compris une sauvegarde complète si aucune n’a été effectuée (ce qui constitue une opération dépendante de la taille des données). Laissez le temps de nettoyer l’instance secondaire après avoir supprimé un groupe de basculement avec des bases de données très volumineuses, car chaque base de données peut avoir une opération de sauvegarde complète en attente en cours.

Une sauvegarde complète correspond à une opération sur les données d'envergure qui ne peut pas être ignorée ou différée et peut nécessiter du temps pour être complétée. Le temps nécessaire à son exécution dépend de la taille des données, du nombre de bases de données et de l’intensité de la charge de travail sur les bases de données primaires. Une sauvegarde complète peut retarder notablement l’amorçage initial et peut retarder ou empêcher une opération de basculement sur une nouvelle instance peu après un basculement.

Service de relecture du journal

Les bases de données migrées vers Azure SQL Managed Instance à l’aide de Log Replay Service (LRS) ne peuvent pas être ajoutées à un groupe de basculement tant que l’étape de basculement n’est pas exécutée. Une base de données migrée avec LRS est dans un état de restauration jusqu’au basculement, et les bases de données dans un état de restauration ne peuvent pas être ajoutées à un groupe de basculement. La tentative de création d’un groupe de basculement avec une base de données dans un état de restauration retarde la création du groupe de basculement jusqu’à ce que la restauration de la base de données se termine.

Réplication transactionnelle

L’utilisation de la réplication transactionnelle avec des instances qui se trouvent dans un groupe de basculement est prise en charge. Toutefois, si vous configurez la réplication avant d’ajouter votre instance managée SQL dans un groupe de basculement, la réplication s’interrompt lorsque vous commencez à créer votre groupe de basculement. Le moniteur de réplication affiche l’état Replicated transactions are waiting for the next log backup or for mirroring partner to catch up. La réplication reprend une fois le groupe de basculement créé.

Si une instance SQL Managed Instance de publication ou de distribution se trouve dans un groupe de basculement, l’administrateur de l’instance SQL Managed Instance doit nettoyer toutes les publications de l’ancienne instance principale et les reconfigurer sur la nouvelle instance principale après un basculement. Consultez le guide de réplication transactionnelle pour connaître les activités nécessaires dans ce scénario.

Autorisations et limites

Consultez la liste des autorisations et limitations avant de configurer un groupe de basculement.

Gérer programmatiquement des groupes de basculement

Les groupes de basculement peuvent aussi être gérés programmatiquement en utilisant Azure PowerShell, Azure CLI et l’API REST. Consultez Configurer le groupe de basculement pour en savoir plus.

Exercices de récupération d’urgence

La méthode recommandée pour effectuer une extraction de récupération d’urgence consiste à utiliser le basculement planifié manuel, conformément au tutoriel suivant : Tester le basculement.

L’exécution d’un exercice à l’aide d’un basculement forcé n’est pas recommandée, car cette opération ne fournit pas de garde-fous contre la perte de données. Néanmoins, il est possible d’obtenir un basculement forcé sans perte de données en garantissant que les conditions suivantes sont remplies avant de lancer le basculement forcé :

• La charge de travail est arrêtée sur l’instance managée SQL principale.
• Toutes les transactions de longue durée sont terminées.
• Toutes les connexions clientes à l’instance managée SQL principale ont été déconnectées.
• L’état du groupe de basculement est « Synchronisation ».

Vérifiez que les deux instances managées SQL ont changé de rôle. De plus, l’état du groupe de basculement passe de « Basculement en cours » à « Synchronisation » avant d’établir éventuellement des connexions à la nouvelle instance managée SQL principale et de démarrer la charge de travail en lecture-écriture.

Pour effectuer une restauration automatique sans perte de données vers les rôles d’instance managée SQL d’origine, l’utilisation d’un basculement planifié manuel au lieu d’un basculement forcé est fortement recommandée. Si un retour en arrière forcé est utilisé :

• Suivez les mêmes étapes que pour le basculement sans perte de données.
• Une durée d’exécution de restauration automatique plus longue est attendue si la restauration automatique forcée est exécutée peu après la fin du basculement forcé initial, car elle doit attendre la fin des opérations de sauvegarde automatiques en attente sur l’ancienne instance managée SQL principale.
• Toutes les opérations de sauvegarde automatiques en attente sur une instance qui passent du rôle principal au rôle secondaire peuvent avoir un impact sur la disponibilité de la base de données sur cette instance.
• Utilisez l’état du groupe de basculement pour déterminer si les deux instances ont correctement modifié leurs rôles et sont prêtes à accepter les connexions clientes.

Contenu connexe

• Configurer un groupe de basculement pour Azure SQL Managed Instance
• Utiliser PowerShell pour ajouter une instance managée SQL à un groupe de basculement
• Configurer un réplica en attente sans licence pour Azure SQL Managed Instance
• Vue d’ensemble de la continuité d’activité avec Azure SQL Managed Instance
• Sauvegardes automatisées dans Azure SQL Managed Instance
• Restaurer une base de données à partir d’une sauvegarde dans Azure SQL Managed Instance