Partager via

La géoréplication active

S’applique à :base de données Azure SQL

Cet article fournit une vue d’ensemble de la fonctionnalité de géoréplication active pour Azure SQL Database, 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 accessible en lecture peut être dans la même région Azure que la base de données primaire, ou, plus communément, 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 lancer un basculement géographique vers une zone géographique secondaire dans une autre région Azure. Le géo-basculement est initié par programme 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 une base de données secondaire est promue au rôle principal, tous les autres réplicas secondaires sont automatiquement liés à la nouvelle base de données primaire.

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 des transactions de la base de données du réplica principal vers les réplicas 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 entre régions permet aux applications de récupérer rapidement d’une perte permanente d’une région Azure entière, ou d’une partie d’une région, résultant de catastrophes naturelles, de graves erreurs humaines ou d’actes de malveillance. Vous trouverez un RPO de géoréplication dans La continuité d’activité 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.

Capture d’écran du portail Azure montrant 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 Conception de services disponibles à l’échelle mondiale à l’aide d’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éé, le géo-réplica est rempli avec les données de la base de données primaire. Ce processus est appelé amorçage. Une fois la base de données 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 le géo-réplica. 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 décharger des charges de travail de 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 réplicas secondaires pour répondre aux scénarios d’échelle horizontale en lecture dans la même région. Toutefois, un réplica secondaire dans la même région ne fournit pas de résilience supplémentaire aux défaillances catastrophiques ou aux pannes à grande échelle, et n’est donc pas une cible de basculement appropriée à des fins de récupération d’urgence. 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 récupérations d’urgence (DR) en production lorsque la perte de données n’est pas acceptable
    • Déplacer les bases de données vers une autre région
    • Renvoyer les bases de données 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 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é, réensemencé en utilisant les données actuelles du primaire, et devient le nouveau géo-secondaire.

Important

Après un basculement forcé, le point de terminaison de connexion de la base de données principale est modifié, car le nouveau réplica principal 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 bases de données secondaires supplémentaires peuvent également être utilisées pour effectuer un scale-out des charges de travail en lecture seule.

Conseil

Si vous utilisez la géoréplication active pour créer une application mondialement distribuée et que vous avez besoin de fournir un accès en lecture seule aux données dans plus de quatre régions, vous pouvez créer une base de données secondaire pour une base de données secondaire (processus connu sous le nom de chaînage), afin de créer des géo-réplicas supplémentaires. Le décalage de réplication sur les réplicas de zone géographique enchaînés peut être plus important que sur les réplicas de zone géographique connectés directement au réplica principal. La configuration des topologies de géoréplication chaînée est prise en charge uniquement par programme, 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 de zone géographique est distinct et ne dépend pas de la configuration d’un autre réplica 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éo-réplicas de la 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 géo-secondaire et le met à jour avec le nouveau réplica 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 réplica principal est défaillant avant que ces transactions ne soient répliquées sur un réplica secondaire de zone géograpgique. Quand une base de données primaire avec plusieurs géo-réplicas bascule, le système reconfigure automatiquement les relations de réplication et lie les bases de données géosecondaires restantes à la base de données nouvellement promue comme 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 réplica principal 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 réplica principal après le géo-basculement, assurez-vous 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é Azure SQL Database pour la géorestauration ou le basculement. Vérifiez également que la stratégie de rétention de sauvegarde sur la base de données secondaire correspond à celle du réplica principal. 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 géo-réplica est configuré avec une période de rétention de récupération jusqu’à une date et heure par défaut de sept jours. Pour plus d’informations, consultez Sauvegardes automatisées 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. Pour plus d’informations, consultez la vue d’ensemble des groupes de basculement et les meilleures pratiques (Azure SQL Database).

Configurer la base de données géosecondaire

Les réplicas principal et secondaire de zone géographique doivent offrir 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 réplica principal est soumis à une charge de travail importante en écriture, un réplica secondaire de zone géographique ayant 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 réplica secondaire de zone géographique et peut éventuellement entraîner l’indisponibilité du réplica secondaire de zone géographique. 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 de réplica secondaire de zone géographique 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 réplica principal. 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.

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 de calcul minimale du géo-réplica requis pour supporter 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 à la taille primaire. Recherchez le HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO type d’attente dans sys.dm_exec_requests et les vues de base de données 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 INTOet les builds d’index. Pour plus d’informations sur les types d’attente pour différents types de limitation d’E/S de journal, consultez gouvernance des 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).

Réduire les coûts avec le réplica en attente

Si votre réplica secondaire n’est utilisé que pour la récupération d’urgence (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 en attente lorsque vous configurez une nouvelle relation de géoréplication active.

Pour en savoir plus, reportez-vous au réplica en attente 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 client ID Microsoft Entra.

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

Pour obtenir des méthodes et des instructions pas à pas, consultez Tutoriel : Configurer la géoréplication active et le basculement (base de données Azure SQL).

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 informations d’identification de l’authentification. 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é 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 du scale-up, nous vous recommandons de commencer par la base de données géosecondaire, puis de terminer avec 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, passez en revue 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 renforcé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 l’accès en 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.

Supervision du 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 les transactions renforcé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 le serveur principal est NULL, cela signifie que la base de données primaire ne sait actuellement pas à quel point se trouve un géo-secondaire. 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 elle est retournée NULL pendant 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 la différence entre last_commit le temps sur la géo-secondaire et sur la base primaire deviennent volumineuses. 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 aussi être gérée de manière programmatique à l’aide de T-SQL, d’Azure PowerShell et de l’API REST. Les tableaux ci-dessous décrivent l’ensemble des commandes disponibles. La géoréplication active comprend un ensemble d’API Azure Resource Manager pour la gestion, notamment l’API REST Azure SQL Database et les applets de commande Azure PowerShell. Ces API prennent en charge le contrôle d’accès en fonction du rôle Azure (Azure RBAC). Pour plus d’informations sur l’implémentation de rôles d’accès, consultez la page sur le contrôle d’accès en fonction du rôle Azure (RBAC Azure).

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 Utiliser FAILOVER ou FORCE_FAILOVER_ALLOW_DATA_LOSS basculer une base de données secondaire pour qu’elle soit primaire pour 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 Entraîne l’attente de l’application jusqu’à ce que toutes les transactions validées soient renforcées dans le journal des transactions d’un géo-réplica.

Contenu connexe

Configurer la géoréplication active :

Autres contenus de continuité d’activité :

  • Last updated on