Vue d’ensemble des groupes de basculement et meilleures pratiques (Azure SQL Database)

S’applique à : Azure SQL Database

Les groupes de basculement vous permettent de gérer la réplication et le basculement de tout ou partie des bases de données sur un serveur logique vers un autre dans une autre région. Cet article fournit une vue d’ensemble de la fonctionnalité de groupe de basculement avec les meilleures pratiques et recommandations pour l’utiliser avec la base de données Azure SQL.

Pour commencer avec l’utilisation de cette fonctionnalité, consultez Configurer le groupe de basculement.

Pour en savoir plus sur la récupération d’urgence d’Azure SQL Database, regardez cette vidéo :

Vue d’ensemble

Les groupes de basculement vous permettent de gérer la réplication et le basculement de toutes les bases de données vers une autre région Azure. Vous pouvez les sélectionner tous ou leur sous-ensemble, les bases de données utilisateur dans un serveur logique à répliquer sur un autre serveur logique. Il s’agit d’une abstraction déclarative sur la fonctionnalité de géoréplication active, conçue pour simplifier le déploiement et la gestion des bases de données géorépliquées à l’échelle.

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é prédéfinie 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 (contrat SLA) des applications utilisant 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 :

• Les pannes au niveau du centre de données, de la zone de disponibilité ou de la région causées 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.
• Toutes les bases de donnée(s) primaire(s) et secondaire(s) du groupe de basculement et toutes les relations de réplication de zone géographique ont le même niveau de service, le même niveau de Capacité de calcul (approvisionné ou sans serveur) et la même taille de calcul (DTU ou vCores). Si l'objectif de niveau de service (SLO) de toutes les bases de données ne correspond pas, la stratégie de basculement sera éventuellement mise à jour de Microsoft Managed à Customer Managed par Azure SQL service.

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 est un groupe nommé de bases de données gérées par un même serveur logique dans Azure qui peut basculer entièrement vers une autre région Azure lorsqu’une partie ou la totalité des bases de données primaires devient indisponible en raison d’une panne dans la région primaire.

  Important

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

• Serveurs

  Une partie ou la totalité des bases de données utilisateur d’un serveur logique peut être placée dans un groupe de basculement. En outre, un serveur prend en charge plusieurs groupes de basculement sur un seul serveur.

• Primaire

  Un serveur logique qui héberge les bases de données primaires dans le groupe de basculement.

• Secondaire

  Un serveur logique 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.

• 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.

• Ajouter des bases de données uniques au groupe de basculement

  Vous pouvez placer plusieurs bases de données uniques sur le même serveur logique, dans le même groupe de basculement. Si vous ajoutez une base de données unique au groupe de basculement, une base de données secondaire de la même édition et de la même taille de calcul est automatiquement créée sur le serveur secondaire que vous avez indiqué lors de la création du groupe de basculement. Si vous ajoutez une base de données qui présente déjà une base de données secondaire dans le serveur secondaire, ce lien de géoréplication est hérité par le groupe. Lors de l’ajout d’une base de données qui présente déjà une base de données secondaire sur un serveur qui ne fait pas partie du groupe de basculement, une nouvelle base de données secondaire est créée sur le serveur secondaire.

  Important

  • Assurez-vous que le serveur logique secondaire ne dispose pas d’une base de données portant le même nom, sauf s’il s’agit d’une base de données secondaire existante.
  • Si une base de données contient des objets OLTP en mémoire, la base de données primaire et les bases de données géo-réplica secondaires cibles 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 la base de données géo-réplica pourrait entraîner des problèmes de manque de mémoire. Si cela se produit, le géo-réplica 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 peut ensuite entraîner l’échec des basculements. Pour éviter cela, assurez-vous que le niveau de service de la base de données 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 pourraient prendre un certain temps.

• Ajouter des bases de données d’un pool élastique au groupe de basculement

  Vous pouvez placer une partie ou la totalité des bases de données d’un pool élastique dans le même groupe de basculement. Si la base de données primaire se trouve dans un pool élastique, la base de données secondaire est automatiquement créée dans le pool élastique du même nom (pool secondaire). Vérifiez que le serveur secondaire contient un pool élastique portant exactement le même nom et offrant une capacité disponible suffisante pour héberger les bases de données secondaires qui seront créées par le groupe de basculement. Si vous ajoutez une base de données dans le pool qui présente déjà une base de données secondaire dans le pool secondaire, ce lien de géoréplication est hérité par le groupe. Si vous ajoutez une base de données qui présente déjà une base de données secondaire sur un serveur ne faisant pas partie du groupe de basculement, une nouvelle base de données secondaire est créée dans le pool secondaire.

• É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 un serveur, l’enregistrement DNS CNAME pour l’URL de l’écouteur est formé comme suit : <fog-name>.database.windows.net. Après le basculement, l’enregistrement DNS est automatiquement mis à jour pour rediriger l’écouteur vers le nouveau primaire.

• É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 un serveur, l’enregistrement DNS CNAME pour l’URL de l’écouteur est formé comme suit : <fog-name>.secondary.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é est définie sur True, le nouveau serveur principal servira les sessions en lecture-écriture et en lecture seule.

• Plusieurs groupes de basculement

  Vous pouvez configurer plusieurs groupes de basculement pour la même paire de serveurs afin de contrôler l’étendue des géobasculements. Chaque groupe bascule indépendamment. Si l’application par base de données de votre locataire est déployée dans plusieurs régions et utilise des pools élastiques, vous pouvez utiliser cette fonctionnalité pour mélanger des bases de données primaires et secondaires dans chaque pool. De cette façon, vous pouvez réduire l’impact d’une panne à seulement certaines bases de données de locataire.

Architecture du groupe de basculement

Un groupe de basculement dans Azure SQL Database peut inclure une ou plusieurs bases de données, généralement utilisées par la même application. Un groupe de basculement doit être configuré sur le serveur primaire, qu’il connecte au serveur secondaire dans une autre région Azure. Le groupe de basculement peut inclure une partie ou la totalité des bases de données dans le serveur primaire. Le diagramme suivant illustre la configuration standard d’une application cloud géoredondante avec plusieurs bases de données dans un groupe de basculement :

Lorsque vous concevez un service en tenant compte de la continuité des activités, suivez les recommandations générales et les meilleures pratiques décrites dans cet article. Lors de la configuration d’un groupe de basculement, assurez-vous que l’authentification et l’accès réseau sur le réplica secondaire sont configurés pour fonctionner correctement après le géobasculement, lorsque le réplica géosecondaire devient le nouveau réplica primaire. Pour plus d’informations, consultez Gestion de la sécurité de la base de données SQL Azure après la récupération d’urgence. Pour plus d’informations, consultez Conception de solutions cloud pour la récupération d’urgence.

Utiliser des régions jumelées

Lorsque vous créez votre groupe de basculement entre le serveur principal et le serveur secondaire, utilisez des régions jumelées en tant que groupes de basculement dans des régions jumelées ont de meilleures performances par rapport aux régions non souhaitées.

En suivant les pratiques de déploiement sécurisées, la base de données Azure SQL ne met généralement pas à jour les régions jumelées en même temps. Toutefois, il n’est pas possible de prédire quelle région sera mise à niveau en premier ; ainsi l’ordre de déploiement n’est pas garanti. Parfois, votre serveur principal est mis à niveau en premier, et parfois il est mis à niveau en deuxième.

Si vous avez configuré des groupes de géoréplication ou des groupes de basculement pour les bases de données qui ne s’alignent pas sur le jumelage de régions Azure, utilisez différentes planifications de fenêtre de maintenance pour vos bases de données primaires et secondaires. Par exemple, vous pouvez sélectionner la fenêtre de maintenance Jour ouvrable pour votre base de données secondaire et la fenêtre de maintenance Week-end pour votre base de données primaire.

Amorçage initial

Lorsque vous ajoutez des bases de données ou des pools élastiques à un groupe de basculement, il y a d’abord une phase d’amorçage initiale avant le démarrage de la réplication des données. La phase d’amorçage initiale est l’opération la plus longue et la plus coûteuse. Une fois l’amorçage initial terminé, les données sont synchronisées, puis seules les modifications de données ultérieures sont répliquées. Le temps nécessaire à la réalisation de l’amorçage initial dépend de la taille de vos données, du nombre de bases de données répliquées, de la charge sur les bases de données primaires et de la vitesse de la liaison de réseau entre les bases de données primaires et secondaires. Dans des circonstances normales, la vitesse d’amorçage possible peut atteindre 500 Go par heure pour SQL Database. L’amorçage est effectué pour toutes les bases de données en parallèle.

Nombre de bases de données dans un groupe de basculement

Le nombre de bases de données au sein d’un groupe de basculement affecte directement la durée des opérations de basculement et de basculement forcé.

• Pendant un basculement (également appelé basculement planifié), nous nous assurons que toutes les bases de données primaires sont entièrement synchronisées avec leurs bases de données secondaires et atteignent l’état Prêt. Pour éviter de surcharger le plan de contrôle, les bases de données sont préparées par lots. Par conséquent, il est vivement recommandé de limiter le nombre de bases de données dans un groupe de basculement.
• Dans le cas d’un basculement forcé, la phase de préparation est accélérée, car la synchronisation de données n’est pas lancée. Pour obtenir des durées de basculement plus rapides et prévisibles, il peut être utile de maintenir moins de bases de données dans le groupe de basculement.

Utiliser différents groupes de basculement pour différentes bases de données de basculement

Un ou plusieurs groupes de basculement peuvent être créés entre deux serveurs situés dans des régions différentes (serveurs principal et serveur secondaire). Chaque groupe peut inclure une ou plusieurs bases de données qui sont récupérées ensemble dans le cas où une partie ou la totalité des bases de données primaires deviennent indisponibles en raison d’une panne dans la région principale. La création d’un groupe de basculement crée des bases de données géosecondaires avec le même objectif de service que la base de données primaire. Si vous ajoutez une relation de géoréplication existante à un groupe de basculement, vérifiez que la base de données géosecondaire est configurée avec le même niveau de service et la même taille de calcul que la base de données primaire.

Utiliser l’écouteur en lecture-écriture (primaire)

Pour les charges de travail en lecture-écriture, utilisez <fog-name>.database.windows.net comme nom de serveur dans la chaîne de connexion. Les connexions sont automatiquement dirigées vers la base de données primaire. Ce nom ne change pas après le basculement. Notez que le basculement implique la mise à jour de l’enregistrement DNS de façon à ce que les connexions clients soient redirigées vers le nouveau serveur primaire seulement après l’actualisation du cache DNS. La durée de vie (TTL) de l’enregistrement DNS des écouteurs principal et secondaire est de 30 secondes.

Utiliser l'écouteur en lecture seule (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 la base de données géosecondaire. Pour les sessions en lecture seule, utilisez <fog-name>.secondary.database.windows.net comme nom de serveur dans la chaîne de connexion. Les connexions sont automatiquement dirigées vers la base de données géosecondaire. Il est également recommandé d’indiquer une intention de lecture dans la chaîne de connexion à l’aide de ApplicationIntent=ReadOnly.

Dans les niveaux de service Premium, Critique pour l’entreprise et Hyperscale, SQL Database 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 base de données géosecondaire, vous pouvez utiliser cette fonction pour vous connecter à un réplica en lecture seule à l’emplacement primaire ou à l’emplacement géosecondaire :

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

Dégradation potentielle des performances après le basculement

Une application Azure classique fait appel à plusieurs services Azure et inclut plusieurs composants. Le basculement d’un groupe est déclenché en fonction de l’état de la base de données Azure SQL seul. Il peut arriver que les autres services Azure de la région primaire ne soient pas affectés par la panne et que leurs composants soient toujours disponibles dans cette région. Une fois que les bases de données primaires ont basculé vers la région (DR) secondaire, la latence entre les composants dépendants peut augmenter. Pour éviter l’impact d’une latence plus élevée sur les performances de l’application, vérifiez la redondance de tous les composants de l’application dans la région DR, suivez ces instructions de sécurité réseau et orchestrez le géobasculement des composants d’application concernés avec la base de données.

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é.

Restauration automatique

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

Autorisations et limites

Consultez le guide de configuration du groupe de basculement pour obtenir la liste des autorisations et limitations.

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. Pour plus d’informations, consultez Configurer un groupe de basculement.

Contenu connexe

• Pour obtenir des exemples de scripts, consultez :
  • Use PowerShell to configure active geo-replication for Azure SQL Database (Utiliser PowerShell pour configurer la géoréplication active pour Azure SQL Database)
  • Utiliser PowerShell afin de configurer la géoréplication active pour avoir une base de données mise en pool dans Azure SQL Database
  • Use PowerShell to add an Azure SQL Database to a failover group (Utiliser PowerShell afin d’ajouter une base de données Azure SQL Database à un groupe de basculement)
• Pour une vue d’ensemble de la continuité des activités et des scénarios, consultez Vue d’ensemble de la continuité des activités
• Pour en savoir plus sur les sauvegardes automatisées d’une base de données Azure SQL, consultez Sauvegardes automatisées d’une base de données SQL.
• Pour en savoir plus sur l’utilisation des sauvegardes automatisées pour la récupération, consultez Restaurer une base de données à partir des sauvegardes initiées par le service.
• Pour en savoir plus sur les exigences d’authentification pour de nouveaux serveurs et bases de données primaires, consultez Gestion de la sécurité de la base de données SQL Azure après la récupération d’urgence.