Partager via

La géoréplication active

Applies to :Azure SQL Database

Cet article fournit une vue d’ensemble de la fonctionnalité de géoréplication active pour Azure SQL Database, ce qui vous permet de répliquer en continu des données d’une base de données primaire vers une base de données secondaire lisible. La base de données secondaire lisible peut se trouver dans la même région Azure que la base de données primaire ou, plus souvent, dans une autre région. Ce type de base de données secondaire accessible en lecture est également appelé géosecondaire ou géoréplica.

La géoréplication active est configurée par base de données. Pour basculer sur un groupe de bases de données, ou si votre application nécessite un point de terminaison de connexion stable, envisagez plutôt des groupes de basculement.

Vous pouvez également Effectuer une migration SQL Database avec la géoréplication active.

Vue d’ensemble

La géoréplication active est conçue comme une solution de continuité d’activité. La géoréplication active vous permet d’effectuer une récupération d’urgence rapide des bases de données individuelles en cas de sinistre régional ou de panne à grande échelle. Une fois la géoréplication configurée, vous pouvez déclencher un géo-basculement vers un géo-secondaire situé dans une autre région Azure. Le géo-basculement est initié de manière programmatique par l'application ou manuellement par l'utilisateur.

Le diagramme suivant illustre la configuration standard d’une application cloud géoredondante avec la géoréplication active.

Diagramme de la géoréplication active.

Si, pour une raison quelconque, votre base de données primaire échoue, vous pouvez lancer un basculement géographique vers l’une de vos bases de données secondaires. Quand un secondaire est promu au rôle principal, tous les autres secondaires sont automatiquement liés au nouveau principal.

Vous pouvez gérer la géoréplication et initier un basculement géographique à l’aide de l’une des méthodes suivantes :

La géoréplication active utilise la technologie du Groupe de disponibilité Always On pour répliquer de manière asynchrone le journal des transactions généré sur le réplica principal vers toutes les réplicas de zone géographique. À un moment donné, une base de données secondaire peut être légèrement en retard sur la base de données primaire, mais les données secondaires restent cohérentes au niveau transactionnel. En d’autres termes, les modifications effectuées par les transactions non validées ne sont pas visibles.

Remarque

La géoréplication active réplique les modifications en diffusant le journal de transaction de la base de données à partir du réplica principal vers les répliques secondaires. Elle n’est pas liée à la réplication transactionnelle, qui réplique les modifications en exécutant des commandes DML (INSERT, UPDATE, DELETE) sur les abonnés.

La géoréplication fournit une redondance régionale. La redondance régionale permet aux applications de récupérer rapidement après une perte permanente d’une région entière Azure ou de parties d’une région, causées par des catastrophes naturelles, des erreurs humaines catastrophiques ou des actes malveillants. Vous pouvez trouver le RPO de géoréplication dans Continuité des activités dans Azure SQL Database.

La figure suivante présente un exemple de géoréplication active configurée avec une base de données primaire située dans la région USA Ouest 2, ainsi qu’une base de données géosecondaire située dans la région USA Est.

Screenshot du portail Azure affichant une relation de géoréplication SQL DB.

En plus de la récupération d’urgence, la géoréplication active peut être utilisée dans les scénarios suivants :

  • Migration de base de données : vous pouvez vous servir de la géoréplication active pour migrer une base de données d’un serveur vers un autre serveur avec un temps d’arrêt minimal.
  • Mises à niveau de l’application : vous pouvez créer une base de données secondaire supplémentaire faisant office de copie de restauration automatique lors des mises à niveau de l’application.

Pour arriver à une continuité d’activité totale, l’ajout d’une redondance régionale de base de données 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. Pour plus d’informations sur la conception de solutions pour la récupération d’urgence, consultez Designing des services disponibles globalement à l’aide de Azure SQL Database.

Terminologie et fonctionnalités

  • Réplication asynchrone automatique : vous ne pouvez créer qu’un géo-secondaire pour une base de données existante. La zone géosecondaire peut être créée sur n’importe quel serveur logique, autre que le serveur avec la base de données primaire. Une fois créée, la réplique géo-secondaire est peuplée avec les données de la base de données primaire. Ce processus est appelé amorçage. Une fois la géosecondaire créée et amorcée, les mises à jour de la base de données primaire sont automatiquement répliquées de manière asynchrone sur la réplique géosecondaire. La réplication asynchrone signifie que les transactions sont validées sur la base de données primaire avant leur réplication.

  • Réplicas géo-secondaires lisibles : une application peut accéder à un réplica géo-secondaire pour exécuter des requêtes en lecture seule à l’aide des principaux de sécurité identiques ou différents utilisés pour accéder à la base de données primaire. Pour plus d’informations, consultez Utiliser des réplicas en lecture seule pour alléger les charges de travail des requêtes en lecture seule.

Important

Vous pouvez utiliser la géoréplication pour créer des réplicas secondaires dans la même région que la base de données primaire. Vous pouvez utiliser ces secondaires pour satisfaire aux besoins de lecture en échelle horizontale dans la même région. Toutefois, une réplique secondaire dans la même région ne fournit pas de résilience supplémentaire face aux défaillances catastrophiques ou aux pannes à grande échelle, et n’est donc pas une cible de basculement appropriée à des fins de reprise après sinistre. De même,il ne garantit en rien l’isolation de la zone de disponibilité. Utilisez le niveau de service Critique pour l’entreprise ou Premium avec une configuration de zone redondante ou le niveau de service Usage général avec une configuration de zone redondante pour isoler la zone de disponibilité.

  • Basculement (aucune perte de données) : lorsqu’un basculement (aucune perte de données) est lancé, une étape complète de synchronisation des données est effectuée avant de basculer les rôles des bases de données primaires et géo-secondaires. Cela garantit qu’il n’y a aucune perte de données. La durée du basculement dépend de la taille du journal des transactions sur la base de données primaire qui doit être synchronisée avec la base géo-secondaire. Le basculement est conçu pour les scénarios suivants :

    • Simuler des exercices de reprise après sinistre (DR) dans l'environnement de production lorsque la perte de données n'est pas acceptable
    • Déplacer les bases de données vers une autre région
    • Renvoyer la base de données vers la région primaire après l'atténuation de la panne (retour à l'état précédent).

  • Basculement forcé (perte de données potentielle) : le basculement forcé bascule immédiatement le géo-secondaire vers le rôle principal sans attendre la synchronisation avec le serveur principal. Toutes les transactions validées sur la base de données primaire qui ne sont pas répliquées sur la base de données secondaire sont perdues. Cette opération est conçue comme une méthode de récupération pendant les pannes lorsque le serveur principal n’est pas accessible, mais que la disponibilité de la base de données doit être restaurée rapidement. Lorsque le primaire d'origine est de nouveau en ligne, il est automatiquement reconnecté et synchronisé avec les données actuelles du primaire, puis devient le nouveau géo-secondaire.

Important

Après un basculement ou un basculement forcé, le point de terminaison de connexion du nouveau réplica principal est modifié, car il est maintenant situé sur un autre serveur logique.

  • Plusieurs géo-secondaires lisibles : jusqu’à quatre géo-secondaires peuvent être créés pour un primaire. S’il n’existe qu’une seule base de données secondaire, en cas d’échec de celle-ci, l’application est exposée à un risque plus élevé jusqu’à la création d’une nouvelle base de données secondaire. S’il existe plusieurs bases de données secondaires, l’application reste protégée même en cas d’échec de l’une des bases de données secondaires. Des serveurs secondaires supplémentaires peuvent également être utilisés pour augmenter la capacité des charges de travail en lecture seule.

Conseil

Si vous utilisez la géo-réplication active pour créer une application distribuée à l'échelle mondiale et que vous devez fournir un accès en lecture seule aux données dans plus de quatre régions, vous pouvez effectuer un chaînage en créant un secondaire d'un secondaire pour ajouter des géo-réplicas supplémentaires. Le décalage de réplication sur les répliques géographiques enchaînées peut être plus important que sur les répliques géographiques connectées directement à la réplique principale. La configuration des topologies de géoréplication chaînée n’est prise en charge que par programmation, et non à partir du portail Azure.

  • Géoréplication des bases de données dans un pool élastique : chaque géo-secondaire peut être une base de données unique ou une base de données dans un pool élastique. Le choix du pool élastique pour chaque base de données secondaire géographique est distinct et ne dépend pas de la configuration d’un autre réplica géographique dans la topologie (qu’il soit principal ou secondaire). Chaque pool élastique est contenu dans un serveur logique unique. Étant donné que les noms de bases de données sur un serveur logique doivent être uniques, plusieurs géosecondaires d'une même base de données primaire ne peuvent jamais partager un pool élastique.

  • Basculement géographique et restauration contrôlés par l’utilisateur : une géo-secondaire qui a terminé l’amorçage initial peut être explicitement basculée vers le rôle principal à tout moment par l’application ou l’utilisateur. Lors d’une panne où le serveur principal est inaccessible, seul le basculement forcé peut être utilisé, ce qui promeut immédiatement un géo-secondaire comme étant le nouveau primaire. Lorsque la panne est atténuée, le système définit automatiquement le serveur principal récupéré comme secondaire géographique et le synchronise avec le nouveau serveur principal. En raison de la nature asynchrone de la géoréplication, des transactions récentes peuvent être perdues lors de basculements forcés si le principal échoue avant que ces transactions ne soient répliquées sur un géoréplica secondaire. Quand une base de données primaire avec plusieurs géosecondaires bascule, le système reconfigure automatiquement les relations de réplication et lie les géosecondaires restantes à la base de données nouvellement promue primaire sans aucune intervention de l’utilisateur. Une fois que la panne à l’origine du basculement géographique a été résolue, il peut être souhaitable de renvoyer le primaire dans sa région d’origine. Pour ce faire, effectuez un basculement manuel.

  • Réplica de secours : si votre réplica secondaire est utilisé uniquement pour la reprise après sinistre et n’a pas de charges de travail de lecture ou d’écriture, vous pouvez désigner le réplica en tant que réplica de secours pour économiser sur les coûts de licence.

Préparer le géo-basculement

Pour vous assurer que votre application peut accéder immédiatement au nouveau serveur principal après un basculement géographique, vérifiez que l’authentification et l’accès réseau de votre serveur secondaire sont correctement configurés. Pour plus d’informations, consultez Configurer et gérer la sécurité de l'Azure SQL Database pour la géorestauration ou le basculement. Vérifiez également que la stratégie de rétention de sauvegarde de la base de données secondaire correspond à celle de la base de données principale. Ce paramètre ne fait pas partie de la base de données et n’est pas répliqué à partir du serveur principal. Par défaut, le secondaire géographique est configuré avec une période de rétention PITR par défaut de sept jours. Pour plus d’informations, consultez Sauvegardes automatiques dans Azure SQL Database.

Important

Si votre base de données est membre d’un groupe de basculement, vous ne pouvez pas lancer son basculement à l’aide de la commande de basculement de la géoréplication. Utilisez la commande de basculement du groupe. Pour basculer une base de données individuelle, vous devez d’abord la supprimer du groupe de basculement. Voir Vue d’ensemble des groupes de failover & meilleures pratiques (Azure SQL Database) pour plus d’informations.

Configurer la base de données géosecondaire

Le primaire et le secondaire géographique doivent avoir le même niveau de service. Il est également vivement recommandé de configurer la base de données géosecondaire avec les mêmes redondance de stockage de sauvegarde, niveau de calcul (provisionné ou serverless) et taille de calcul (DTU ou vCores) que la base de données primaire. Si le primaire est soumis à une charge de travail importante en écriture, un secondaire géo avec une taille de calcul inférieure pourrait ne pas être en mesure de suivre. Cette situation entraîne un décalage de réplication sur le géo-secondaire, et peut éventuellement entraîner l’indisponibilité du géo-secondaire. Pour atténuer ces risques, la géoréplication active réduit si nécessaire le taux de journalisation des transactions de la base de données primaire pour permettre à ses bases de données secondaires de rattraper le retard.

Une autre conséquence d'une configuration géo-secondaire déséquilibrée est qu'après le basculement, les performances de l'application peuvent être affectées en raison de la capacité de calcul insuffisante du nouveau primaire. Dans ce cas, il est nécessaire d’effectuer un scale-up de la base de données pour disposer de ressources suffisantes, ce qui peut prendre beaucoup de temps et nécessite un basculement à haute disponibilité à la fin du processus de scale-up, ce qui peut interrompre les charges de travail de l’application.

Conseil

Pour obtenir des conseils de dépannage détaillés sur le décalage dans la géoréplication, consultez Résoudre les problèmes de décalage de reprise de géoréplication.

Si vous décidez de créer le géo-secondaire avec une autre configuration, vous devez surveiller le taux d’E/S du journal sur le serveur principal au fil du temps. Cela vous permet d’estimer la taille minimale de calcul du secondaire géo-distribué requis pour soutenir la charge de réplication. Par exemple, si votre base de données primaire est P6 (1 000 DTU) et que ses E/S de journal sont soutenues à 50%, le géo-secondaire doit être au moins P4 (500 DTU). Pour récupérer les données d’E/S du journal historique, utilisez la vue sys.resource_stats . Pour récupérer des données d’E/S de journal récentes avec une granularité plus élevée qui reflètent mieux les pics à court terme, utilisez la vue sys.dm_db_resource_stats .

Conseil

La limitation des E/S du journal des transactions peut se produire dans les scénarios suivants :

  • Si la géo-secondaire est à une taille de calcul inférieure à celle du primaire. Recherchez le HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO type d’attente dans les vues de base de données sys.dm_exec_requests et sys.dm_os_wait_stats.
  • La limitation peut également se produire pour des raisons non liées à la taille de calcul, par exemple dans les charges de travail lourdes pour l’insertion en bloc, SELECT INTO et les créations d’index. Pour plus d’informations sur les types d’attente pour différents types de limitation d’E/S de journal, consultez Gouvernance du taux de journalisation des transactions.

Par défaut, la redondance de stockage de sauvegarde de la base de données géosecondaire est identique à celle de la base de données primaire. Vous pouvez configurer la base de données géosecondaire avec une redondance de stockage de sauvegarde différente. Les sauvegardes sont toujours effectuées sur la base de données primaire. Si la base de données secondaire est configurée avec une redondance de stockage de sauvegarde différente, après le géo-basculement effectué lors de la promotion de la base de données secondaire en base de données primaire, les nouvelles sauvegardes sont stockées et facturées en fonction du type de stockage (RA-GRS, ZRS, LRS) sélectionné sur la nouvelle base de données primaire (ancienne secondaire).

Économiser sur les coûts avec la réplique en attente

Si votre réplica secondaire n'est utilisé que pour la reprise après sinistre (DR) et n'a pas de charge de travail en lecture ou en écriture, vous pouvez réduire les coûts de licence en désignant la base de données comme base de données de réserve lorsque vous configurez une nouvelle relation de géoréplication active.

Pour en savoir plus, consultez la réplique de secours sans licence.

Géoréplication entre abonnements

  • Vous pouvez utiliser le portail Azure pour configurer la géoréplication active entre les abonnements tant que les deux abonnements se trouvent dans le même locataire Microsoft Entra.

    • Pour créer un réplica géo-secondaire dans un abonnement différent de l’abonnement du serveur principal dans un client Microsoft Entra différent, utilisez l’authentification SQL et T-SQL. authentification Microsoft Entra pour Azure SQL pour la géoréplication entre abonnements croisés n’est pas prise en charge lorsqu’un serveur logique se trouve dans un autre client Azure
    • Les opérations de géoréplication entre abonnements, y compris la configuration et le basculement géographique, sont également prises en charge à l’aide de l’API REST de création ou de mise à jour de bases de données.

  • La création d’un serveur géo-secondaire inter-abonnement sur un serveur logique dans le même locataire Microsoft Entra ou dans un locataire différent n’est pas prise en charge lorsque l’authentification Microsoft Entra avec Azure SQL uniquement est activée sur un serveur logique principal ou secondaire et que la création est tentée à l’aide d’un utilisateur Microsoft Entra ID.

Pour obtenir des instructions pas à pas et des méthodes, consultez Tutorial : Configurer la géoréplication et le basculement actifs (Azure SQL Database).

Points de terminaison privés

L’ajout d’une instance géo-secondaire à l’aide de T-SQL n’est pas pris en charge lors de la connexion au serveur principal via un point de terminaison privé.

Si le point de terminaison privé est configuré mais que l’accès au réseau public est autorisé, l’ajout d’une base de données géosecondaire lors de la connexion au serveur principal à partir d’une adresse IP publique est pris en charge.

Une fois la base de données géosecondaire ajoutée, l’accès au réseau public peut être refusé.

Synchronisation des informations d’identification et des règles de pare-feu

Lorsque vous utilisez un accès réseau public pour la connexion à la base de données, nous vous recommandons d’utiliser des règles de pare-feu IP au niveau de la base de données pour les bases de données géo-répliquées. Ces règles sont répliquées avec la base de données, ce qui garantit que toutes les bases de données géosecondaires ont les mêmes règles de pare-feu IP que la base de données primaire. Cette approche évite aux clients de devoir configurer et tenir à jour manuellement les règles de pare-feu sur les serveurs hébergeant les bases de données primaire et secondaires. De même, l’utilisation des utilisateurs de base de données autonome pour l’accès aux données garantit que les bases de données primaires et secondaires ont toujours les mêmes informations d’identification d’authentification. Ainsi, après un géobasculement, il n’y a pas d’interruption due à une non-concordance des identifiants. Si vous utilisez des identifiants de connexion et des utilisateurs (et non des utilisateurs contenus), vous devez prendre des mesures supplémentaires pour vous assurer que les mêmes identifiants de connexion existent dans la base de données secondaire. Pour plus d’informations sur la configuration, consultez Configurer et gérer la sécurité de Azure SQL Database pour la géorestauration ou le basculement.

Mettre à l’échelle une base de données primaire

Vous pouvez effectuer un scale-up/down sur une base de données primaire avec une taille de calcul différente (au sein du même niveau de service) sans déconnecter les bases de données géosecondaires. Lors de la mise à l'échelle, nous vous recommandons de commencer par la base de données secondaire géographique, puis de passer à la base de données primaire. Lors du scale-down, inversez l’ordre : commencez par la base de données primaire, puis terminez par la base de données secondaire.

Pour plus d’informations sur les groupes de basculement, consultez la mise à l’échelle d’un réplica 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 protéger les transactions critiques d’une perte de données, le développeur d’applications peut appeler la procédure stockée sp_wait_for_database_copy_sync immédiatement après la validation de la transaction. L’appel de sp_wait_for_database_copy_sync bloque le thread appelant jusqu’à ce que la dernière transaction validée ait été transmise et consignée de manière sécurisée dans le journal des transactions de la base de données secondaire. Il attend également que les transactions transmises soient rejouées (refaites) sur le secondaire. La sp_wait_for_database_copy_sync procédure stockée système est limitée à un lien de géoréplication spécifique. Tout utilisateur disposant de droits de connexion à la base de données primaire peut appeler cette procédure.

Remarque

sp_wait_for_database_copy_sync empêche la perte de données après un géobasculement pour des transactions spécifiques, mais ne garantit pas une synchronisation complète pour les opérations de lecture. Le délai causé par un appel de procédure sp_wait_for_database_copy_sync peut être significatif et dépend de la taille du journal des transactions pas encore transmis à la base de données primaire au moment de l’appel.

Surveiller le décalage de la géoréplication

Pour surveiller le décalage par rapport au RPO, utilisez la replication_lag_sec colonne de sys.dm_geo_replication_link_status sur la base de données primaire. Elle affiche le décalage en secondes entre les transactions validées sur la base de données primaire et celles enregistrées dans le journal des transactions sur la base de données secondaire. Par exemple, si le retard est d’une seconde, cela signifie que si la base de données primaire est affectée par une panne à ce moment et qu’un géo-basculement est initié, les transactions validées au cours de la dernière seconde seront perdues.

Pour mesurer le décalage ayant trait aux modifications de la base de données primaire renforcées sur la base de données géosecondaire, comparez la valeur last_commit sur la base de données secondaire avec la même valeur sur la base de données primaire.

Conseil

Si replication_lag_sec sur la base de données primaire est NULL, cela signifie que la base de données primaire ne sait actuellement pas à quel point un géo-secondaire est en retard. Cela se produit généralement après le redémarrage du processus et relève d’une situation temporaire. Envisagez d’envoyer une alerte si replication_lag_sec renvoie NULL sur une période prolongée. Cette alerte peut indiquer que le réplica secondaire de zone géographique ne peut pas communiquer avec le réplica principal en raison d’une défaillance liée à la connectivité.

Il existe également des conditions qui pourraient entraîner une différence importante entre last_commit le temps sur la géo-secondaire et sur la base primaire. Par exemple, si une validation intervient sur la base de données primaire après une longue période sans modifications, la différence augmente considérablement avant de redevenir rapidement nulle. Envisagez d’envoyer une alerte si la différence entre ces deux valeurs demeure importante pendant une période prolongée.

Gestion de la géoréplication active par programmation

La géoréplication active peut également être gérée par programmation à l’aide de T-SQL, de Azure PowerShell et de l’API REST. Les tableaux ci-dessous décrivent l’ensemble des commandes disponibles. La géoréplication active inclut un ensemble d’API de Azure Resource Manager pour la gestion, y compris l’API REST Azure SQL Database et les applets de commande Azure PowerShell. Ces API prennent en charge Azure contrôle d’accès en fonction du rôle (Azure RBAC). Pour plus d’informations sur l’implémentation des rôles d’accès, consultez Azure contrôle d’accès en fonction du rôle (Azure RBAC).

Important

Ces commandes T-SQL s’appliquent uniquement à la géoréplication active et ne s’appliquent pas aux groupes de basculement.

Commande Descriptif
MODIFIER BASE DE DONNÉES Utiliser l’argument ADD SECONDARY ON SERVER pour créer une base de données secondaire pour une base de données existante et démarrer la réplication des données
MODIFIER BASE DE DONNÉES Utilisez FAILOVER ou FORCE_FAILOVER_ALLOW_DATA_LOSS pour basculer une base de données secondaire en primaire afin de lancer le basculement.
MODIFIER BASE DE DONNÉES Permet REMOVE SECONDARY ON SERVER de mettre fin à une réplication de données entre une base de données SQL et la base de données secondaire spécifiée.
sys.liens_de_réplication_géographique Retourne des informations concernant tous les liens de réplication existants pour chaque base de données sur un serveur.
sys.dm_geo_replication_link_status Obtient l’heure de la dernière réplication, le dernier décalage de la réplication et d’autres informations sur le lien de réplication pour une base de données spécifique.
sys.dm_operation_status Affiche l’état de toutes les opérations de base de données, y compris les modifications apportées aux liens de réplication.
sys.sp_wait_for_database_copy_sync Fait attendre l'application jusqu'à ce que toutes les transactions validées soient enregistrées définitivement dans le journal des transactions d'un secondaire géo.

Résolution des problèmes

Pour plus d’informations sur la résolution des problèmes de décalage de géoréplication, consultez Résoudre les problèmes de décalage de géoréplication.

Contenu connexe

Configurer la géoréplication active :

Autres contenus de continuité d’activité :

  • Last updated on