Haute disponibilité avec Azure Cosmos DB

S’APPLIQUE À : NoSQL MongoDB Cassandra Gremlin Table

Pour créer une solution à haute disponibilité, vous devez évaluer les caractéristiques de fiabilité de tous ses composants. Azure Cosmos DB fournit des fonctionnalités et des options de configuration pour vous permettre d’obtenir une haute disponibilité pour votre solution.

Cet article utilise les termes suivants :

  • Objectif de temps de récupération (RTO) : délai entre le début d’une panne affectant Azure Cosmos DB et la récupération jusqu’à la disponibilité totale.
  • Objectif de point de récupération (RPO) : délai entre la dernière écriture correctement restaurée et le début de la panne qui affecte Azure Cosmos DB.

Notes

Les RPO et RTO attendus et maximaux dépendent du type de panne rencontré par Azure Cosmos DB. Par exemple, une panne d’un seul nœud a des RPO et RTO attendus différents de ceux de la panne d’une région entière.

Cet article décrit en détail les événements pouvant affecter la disponibilité d’Azure Cosmos DB, ainsi que les options de configuration Azure Cosmos DB correspondantes.

Maintenance des réplicas

Azure Cosmos DB est un service multilocataire qui gère de façon transparente tous les détails des différents nœuds de calcul. Les utilisateurs n’ont pas à se soucier du moindre correctif ou de la moindre maintenance planifiée. Azure Cosmos DB garantit les contrats de niveau de service (SLA) pour la disponibilité et la latence P99 lors de toutes les opérations de maintenance automatique que le système effectue.

Pannes de réplicas

Les pannes de réplicas sont des pannes de nœuds individuels dans un cluster Azure Cosmos DB déployé dans une région Azure.

Azure Cosmos DB atténue automatiquement les pannes de réplicas en garantissant au moins trois réplicas de vos données dans chaque région Azure pour votre compte dans un quorum à quatre réplicas. Cette garantie induit un RTO de 0 et un RPO de 0 pour les pannes de nœud individuelles, sans nécessiter de modification ou de configuration d’application.

Dans de nombreuses régions Azure, il est possible de répartir votre cluster Azure Cosmos DB à travers les zones de disponibilité. Les zones de disponibilité peuvent augmenter les contrats de niveau de service, car elles sont physiquement séparées et fournissent une source d’alimentation, un réseau et un refroidissement distincts. Lorsque vous déployez un compte Azure Cosmos DB au moyen de zones de disponibilité, Azure Cosmos DB fournit un RTO de 0 et un RPO de 0, même lors d’une panne de zone.

Lors d’un de vos déploiements dans une région Azure unique, sans entrée utilisateur supplémentaire, Azure Cosmos DB est résilient aux pannes de nœuds. L’activation de la redondance entre les zones de disponibilité rend Azure Cosmos DB résilient aux pannes de zone, avec une augmentation des frais.

Vous ne pouvez configurer la redondance de zone que lors de l’ajout d’une nouvelle région à un compte Azure Cosmos DB. Pour les régions existantes, vous pouvez activer la redondance de zone en supprimant la région, puis en la rajoutant avec la redondance de zone activée. Pour un compte à région unique, cette approche vous oblige à ajouter une région vers laquelle basculer temporairement, puis de la supprimer et d’ajouter la région souhaitée avec la redondance de zone activée.

Par défaut, un compte Azure Cosmos DB n’utilise pas plusieurs zones de disponibilité. Vous pouvez activer le déploiement sur plusieurs zones de disponibilité des façons suivantes :

Si votre compte Azure Cosmos DB est distribué entre N régions Azure, il y aura au moins N x 4 copies de toutes vos données. Pour plus d’informations sur la manière dont Azure Cosmos DB réplique les données dans chaque région, voir Distribution globale avec Azure Cosmos DB. Le fait d’avoir un compte Azure Cosmos DB dans plus de deux régions améliore la disponibilité de votre application et réduit la latence dans les régions associées.

Pannes régionales

Les pannes régionales sont des pannes qui affectent tous les nœuds Azure Cosmos DB dans une région Azure, à travers toutes les zones de disponibilité. Pour de rares cas de pannes régionales, vous pouvez configurer Azure Cosmos DB pour prendre en charge différents résultats de durabilité et de disponibilité.

Disponibilité

Lorsqu'un compte Azure Cosmos DB est déployé dans une unique région, il n'y a généralement pas de perte de données. L’accès aux données est rétabli après la restauration des services Azure Cosmos DB dans la région affectée. La perte de données ne peut se produire qu’en cas de sinistre irrécupérable dans la région Azure Cosmos DB.

Pour vous aider à vous protéger contre toute perte totale de données résultant de catastrophes dans une région, Azure Cosmos DB propose deux modes de sauvegarde différents :

  • Les sauvegardes continues sauvegardent chaque région toutes les 100 secondes. Elles vous permettent de restaurer vos données à n’importe quel point dans le temps avec une granularité de 1 seconde. Dans chaque région, la sauvegarde dépend des données validées dans cette région.
  • Les sauvegardes périodiques sauvegardent entièrement toutes les partitions de tous les conteneurs sous votre compte, sans aucune synchronisation entre les partitions. L’intervalle minimum de sauvegarde est d’une heure.

Lorsqu’un compte Azure Cosmos DB est déployé dans plusieurs régions, la durabilité des données dépend du niveau de cohérence que vous configurez sur le compte. Le tableau suivant détaille, pour tous les niveaux de cohérence, le RPO d’un compte Azure Cosmos DB déployé dans au moins deux régions.

Niveau de cohérence RPO pour une panne régionale
Session, préfixe cohérent et éventuel Moins de 15 minutes
Bounded staleness (En fonction de l'obsolescence) K et T
Remarque 0

K = le nombre de versions (c’est-à-dire de mises à jour) d’un élément.

T = l’intervalle de temps depuis la dernière mise à jour.

Pour les comptes à plusieurs régions, la valeur minimale de K et T est de 100 000 opérations d’écriture ou 300 secondes. Cette valeur fixe le RPO minimal des données lorsque vous utilisez l’obsolescence limitée.

Pour plus d’informations sur les différences entre les niveaux de cohérence, voir Niveaux de cohérence dans Azure Cosmos DB.

Disponibilité

Si votre solution nécessite une disponibilité continue pendant la panne régionale, vous pouvez configurer Azure Cosmos DB pour répliquer vos données dans plusieurs régions et pour basculer de façon transparente vers des régions disponibles si nécessaire.

Les comptes à région unique peuvent perdre leur disponibilité après une panne régionale. Pour garantir la haute disponibilité à tout moment, nous vous recommandons la configuration de votre compte Azure Cosmos DB avec une seule région d’écriture et au moins une deuxième région (de lecture) et d’activer le basculement managé par le service.

Le basculement managé par le service permet à Azure Cosmos DB de basculer vers la zone d’écriture d’un compte à plusieurs régions, afin de préserver la disponibilité au détriment de la perte de données comme décrit plus tôt dans la section durabilité. Les basculements régionaux sont détectés et traités dans le client Azure Cosmos DB. Ils ne nécessitent aucune modification de l’application. Pour obtenir des instructions sur l’activation de plusieurs régions de lecture et le basculement managé par le service, consultez Gérer un compte Azure Cosmos DB en utilisant le portail Azure.

Important

Si vous avez choisi une configuration d’écriture dans une seule région avec plusieurs régions de lecture, nous vous recommandons vivement de configurer les comptes Azure Cosmos DB utilisés pour des charges de travail de production afin d’activer le basculement géré par le service. Cette configuration permet à Azure Cosmos DB de basculer les bases de données du compte vers des régions disponibles. En l’absence de cette configuration, le compte subit une perte de disponibilité en écriture pendant toute la durée de la panne régionale d’écriture. Le basculement manuel échoue en raison d’un manque de connectivité régionale.

Avertissement

Même si le basculement géré par le service est activé, une panne partielle peut nécessiter une intervention manuelle pour l’équipe de service Azure Cosmos DB. Dans ces scénarios, le basculement peut nécessiter jusqu’à 1 heure (ou plus) pour prendre effet. Pour une meilleure disponibilité en écriture pendant les pannes partielles, nous vous recommandons d’activer les zones de disponibilité en plus du basculement géré par le service.

Régions d’écriture multiples

Vous pouvez configurer Azure Cosmos DB pour accepter les écritures dans plusieurs régions. Cette configuration est utile pour réduire la latence d’écriture dans les applications distribuées géographiquement.

Lorsque vous configures un compte Azure Cosmos DB pour plusieurs régions d’écriture, une cohérence forte n’est pas prise en charge et des conflits d’écriture peuvent survenir. Pour plus d’informations sur la résolution desdits conflits, voir Types de conflits et stratégies de résolution lors de l’utilisation de plusieurs régions d’écriture.

Important

La mise à jour fréquente du même ID de document (ou la recréation fréquente du même ID de document après la durée de vie ou la suppression) aura un effet sur les performances de réplication en raison d’un nombre accru de conflits générés dans le système.  

Région de résolution des conflits

Lorsqu’un compte Azure Cosmos DB est configuré avec des écritures dans plusieurs régions, l’une des régions agit en tant qu’arbitre en cas de conflit d’écriture.

Meilleures pratiques pour les écritures multirégions

Voici quelques meilleures pratiques à prendre en compte lorsque vous écrivez dans plusieurs régions.

Conserver le trafic local

Lorsque vous utilisez des écritures à plusieurs régions, l’application doit transmettre du trafic en lecture et en écriture provenant de la région locale, strictement vers la région Cosmos DB locale. Pour des performances optimales, éviter les appels entre régions.

Il est important que l’application réduise les conflits en évitant les anti-modèles suivants :

  • Envoi de la même opération d’écriture vers toutes les régions pour augmenter les chances d’obtenir un temps de réponse rapide

  • Détermination aléatoire de la région cible pour une opération de lecture ou d’écriture en fonction de la requête

  • Utilisation d’une stratégie de tourniquet (round-robin) pour déterminer la région cible d’une opération de lecture ou d’écriture sur la base d'une requête

Éviter la dépendance vis-à-vis du décalage de réplication

Vous ne pouvez pas configurer les comptes d’écriture à plusieurs régions pour une cohérence forte. La région en cours d’écriture répond immédiatement après la réplication des données localement par Azure Cosmos DB, tout en répliquant de façon globale les données de manière asynchrone.

Bien que ce soit rare, un décalage de réplication peut survenir sur une ou plusieurs partitions lorsque vous de la géo-répliquez les données. Un décalage de réplication peut survenir en raison de rares anomalies dans le trafic réseau ou d’un taux de résolution des conflits plus élevé que d’habitude.

Par exemple, une architecture dans laquelle l’application écrit dans la région A, mais lit à partir de la région B introduit une dépendance sur le décalage de réplication entre les deux régions. Toutefois, si l’application lit et écrit dans la même région, les performances restent constantes même en présence d’un décalage de réplication.

Évaluer l’utilisation de la cohérence de session pour les opérations d’écriture

Dans la Cohérence de session, le jeton de session est utilisé tant pour les opérations de lecture que d’écriture.

Pour les opérations de lecture, Azure Cosmos DB envoie le jeton de session mis en cache au serveur avec la garantie de recevoir des données correspondant au jeton de session spécifié (ou plus récent).

Pour les opérations d’écriture, Azure Cosmos DB envoie le jeton de session à la base de données avec une garantie de persistance des données uniquement si le serveur a intercepté le jeton de session fourni. Dans les comptes d’écriture à région unique, la région d’écriture est toujours garantie de rattraper le jeton de session. Toutefois, dans les comptes d’écriture à plusieurs régions, la région dans laquelle vous écrivez n’a peut-être pas intercepté les écritures émises dans une autre région. Si le client écrit dans la région A avec un jeton de session de la région B, la région A ne pourra pas conserver les données tant qu’elle n’aura pas intercepté les modifications apportées dans la région B.

Il est préférable d’utiliser des jetons de session uniquement pour les opérations de lecture, et non pour les opérations d’écriture, lorsque vous interchangez les jetons de session entre des instances clientes.

Atténuer les mises à jour rapides du même document

Les mises à jour du serveur pour résoudre ou confirmer l’absence de conflits peuvent entrer en conflit avec les écritures déclenchées par l’application lorsque le même document est mis à jour à plusieurs reprises. Les mises à jour répétées qui se succèdent rapidement dans le même document entraînent des latences plus élevées lors de la résolution des conflits.

Bien que des rafales ponctuelles de mises à jour répétées du même document soient inévitables, vous devez envisager d’explorer une architecture où de nouveaux documents sont plutôt créés si le trafic à l’état stable voit des mises à jour rapides du même document sur une période prolongée.

À quoi s’attendre lors d’une panne régionale

Le client des comptes à région unique sera confronté à une perte de disponibilité en lecture et en écriture jusqu’à la restauration du service.

Les comptes à plusieurs régions rencontrent des comportements différents en fonction des configurations et des types de panne.

Configuration Outage Impact sur la disponibilité Impact sur la durabilité Procédure à suivre
Région d’écriture unique Panne dans une région de lecture Tous les clients redirigent automatiquement les lectures vers d’autres régions. Il n’y a pas de perte de disponibilité en lecture ou en écriture pour toutes les configurations. L’exception est une configuration de deux régions avec une cohérence forte, perdant la disponibilité en écriture jusqu’à la restauration du service. Ou, si vous activez le basculement managé par le service, le service étiquette la région comme ayant échoué et un basculement se produit. Pas de perte de données. Pendant la panne, assurez-vous qu’il y a suffisamment d’unités de requête (RU) approvisionnées dans les régions restantes pour prendre en charge le trafic en lecture.

Lorsque la panne est terminée, réajustez les unités de requête approvisionnées en conséquence.
Région d’écriture unique Panne dans une région d’écriture Les clients redirigent les lectures vers d’autres régions.

Sans basculement managé par le service, les clients subissent une perte de disponibilité en écriture. La restauration de la disponibilité en écriture se produit automatiquement à la fin de la panne.

Avec basculement managé par le service, les clients subissent une perte de disponibilité jusqu’à ce que le service manage un basculement vers une nouvelle région d’écriture que vous avez sélectionnée.
Si vous ne sélectionnez pas le niveau de cohérence fort, le service risque de ne pas répliquer certaines données dans les régions actives restantes. Cette réplication repose sur le niveau de cohérence que vous sélectionnez. Si la région affectée subit une perte de données permanente, vous risquez de perdre des données non répliquées. Pendant la panne, assurez-vous qu’il y a suffisamment d’unités de requête approvisionnées dans les régions restantes pour prendre en charge le trafic de lecture.

N’effectuez pas de basculement manuel pendant la panne, car il ne va pas fonctionner.

Lorsque la panne est terminée, réajustez les unités de requête approvisionnées en conséquence. Les comptes utilisant l’API pour NoSQL peuvent également récupérer les données non répliquées dans la région ayant échoué à partir de votre flux de conflit.
Régions d’écriture multiples Toute panne régionale Il existe un risque de perte temporaire de la disponibilité des écritures, lié à une seule région d’écriture avec basculement managé par le service. Le basculement de la région de résolution des conflits peut également entraîner une perte de la disponibilité des écritures si de nombreuses écritures conflictuelles se produisent au moment de la panne. Les données récemment mises à jour dans la région défaillante peuvent être indisponibles dans les régions actives restantes, selon le niveau de cohérence sélectionné. Si la région affectée subit une perte de données permanente, vous risquez la perte des données non répliquées. Pendant la panne, assurez-vous qu’il y a suffisamment d’unités de requête approvisionnées dans les régions restantes pour prendre en charge davantage de trafic.

À la fin de la panne, vous pouvez réajuster les unités de requête approvisionnées en conséquence. Si possible, Azure Cosmos DB récupère automatiquement les données non répliquées dans la région ayant échoué. Cette récupération automatique se sert de la méthode de résolution des conflits que vous configurez pour les comptes utilisant l’API pour NoSQL. Pour les comptes utilisant les autres API, cette récupération automatique utilise La dernière écriture gagne.

Informations supplémentaires sur les pannes de région de lecture

  • La région affectée est déconnectée et marquée comme étant hors connexion. Les Kits de développement logiciel (SDK) Azure Cosmos DB redirigent les appels de lecture vers la région disponible suivante dans la liste des régions préférées.

  • Si aucune région de la liste des régions préférées n'est disponible, les appels sont automatiquement acheminés vers la zone d’écriture active.

  • Aucune modification n’est nécessaire dans le code de votre application pour gérer les pannes de la région de lecture. Lorsque la région de lecture affectée est de nouveau en ligne, elle se synchronise avec la région d’écriture active et est à nouveau disponible pour le traitement des requêtes de lecture après sa complète récupération.

  • Les lectures suivantes sont redirigées vers la région récupérée sans modification nécessaire de votre code d’application. Tant pendant le basculement que la réintégration d’une région ayant précédemment échoué, Azure Cosmos DB continue à respecter les garanties de cohérence de lecture.

  • Même dans un cas rare et malheureux où une région d’écriture Azure est définitivement irrécupérable, il n’y a aucune perte de données si votre compte Azure Cosmos DB à plusieurs régions est configuré avec une cohérence forte. Un compte Azure Cosmos DB à plusieurs régions dispose des caractéristiques de durabilité spécifiées précédemment dans la section Durabilité .

Informations supplémentaires sur les pannes de région d’écriture

  • En cas de panne régionale d’écriture, le compte Azure Cosmos DB promeut une région secondaire comme nouvelle région d’écriture principale lorsque le basculement managé par le service est configuré dans le compte Azure Cosmos DB. Le basculement intervient vers une autre région selon l’ordre de priorité des régions que vous avez spécifié.

  • Le basculement manuel ne doit pas être déclenché et il va échouer en cas de panne de la région source ou de destination. La raison étant que la procédure de basculement inclut une vérification de cohérence qui nécessite une connectivité entre les régions.

  • Lorsque la région précédemment affectée est de nouveau en ligne, toutes les données d'écriture qui n'étaient pas dupliquées lors de son l’échec sont mises à disposition au moyen d’un flux de conflits. Les applications peuvent lire le flux de conflits, résoudre les conflits selon la logique propre à l’application, et réécrire les données mises à jour dans le conteneur Azure Cosmos DB le cas échéant.

  • Une fois la région d’écriture précédemment affectée récupérée, elle s’affiche en tant que « en ligne » dans le portail Azure et devient disponible en tant que région de lecture. À ce stade, il est sûr de revenir à la région récupérée en tant que région d’écriture à l’aide de PowerShell, d’Azure CLI ou du portail Azure. Aucune perte de données ou de disponibilité ne survient avant, pendant ou après le changement de région d'écriture. Votre application continue d’être hautement disponible.

Avertissement

En cas de panne d’une région d’écriture, où le compte Azure Cosmos DB promeut une région secondaire comme nouvelle région d’écriture principale via le basculement géré par le service, la région d’écriture d’origine ne sera pas promue automatiquement en tant que région d’écriture une fois qu’elle est récupérée. Il vous incombe de revenir à la région récupérée en tant que région d’écriture à l’aide de PowerShell, d’Azure CLI ou du portail Azure (une fois sécurisé, comme décrit ci-dessus).

Contrats SLA

Le tableau suivant récapitule les fonctionnalités de haute disponibilité des différentes configurations du compte.

KPI Écritures dans une région unique sans zones de disponibilité Écritures dans une région unique avec zones de disponibilité Écritures dans plusieurs régions et dans une région unique sans zone de disponibilité Écritures dans plusieurs régions et dans une région unique avec des zones de disponibilité Régions multiples, écritures dans plusieurs régions avec ou sans zones de disponibilité
Contrat SLA de disponibilité en écriture 99,99 % 99,995 % 99,99 % 99,995 % 99, 999 %
Contrat SLA de disponibilité en lecture 99,99 % 99,995 % 99, 999 % 99, 999 % 99, 999 %
Défaillances de zone : Perte de données Perte de données Aucune perte de données Aucune perte de données Aucune perte de données Aucune perte de données
Défaillances de zone : Disponibilité Perte de disponibilité Aucune perte de disponibilité Aucune perte de disponibilité Aucune perte de disponibilité Aucune perte de disponibilité
Panne régionale : Perte de données Perte de données Perte de données Dépend du niveau de cohérence. Pour plus d’informations, consultez Compromis entre cohérence, disponibilité et performances. Dépend du niveau de cohérence. Pour plus d’informations, consultez Compromis entre cohérence, disponibilité et performances. Dépend du niveau de cohérence. Pour plus d’informations, consultez Compromis entre cohérence, disponibilité et performances.
Panne régionale : Disponibilité Perte de disponibilité Perte de disponibilité Aucune perte de disponibilité pour échec dans la région de lecture, temporaire pour échec dans la région d’écriture Aucune perte de disponibilité pour échec dans la région de lecture, temporaire pour échec dans la région d’écriture Aucune perte de disponibilité de lecture, perte de disponibilité d’écriture temporaire dans la région affectée
Prix (1) Non applicable Unités de requête approvisionnées x taux de 1,25 RU/s provisionnées x N régions RU/s provisionnées x taux 1,25 x N régions (2) Taux d’écriture à plusieurs régions x N régions

1 Pour les comptes serverless, les RU sont multipliées par un facteur de 1,25.

2 Le taux de 1,25 s’applique uniquement aux régions pour lesquelles vous activez les zones de disponibilité.

Astuces pour générer des applications hautement disponibles

  • Examinez le comportement attendu des kits de développement logiciel (SDK) Azure Cosmos DB au cours des événements et quelles configurations l’affectent.

  • Pour garantir une disponibilité élevée en écriture et en lecture, configurez votre compte Azure Cosmos DB de façon à ce qu’il s’étende sur au moins deux régions (ou trois, si vous utilisez la cohérence forte). Pour en savoir plus, consultez Tutoriel : Configurer la distribution globale d’Azure Cosmos DB à l’aide de l’API pour NoSQL.

  • Pour les comptes Azure Cosmos DB à plusieurs régions, configurés avec une seule région d’écriture, activez le basculement managé par le service à l’aide d’Azure CLI ou du Portail Azure. Une fois le basculement managé par le service activé, Azure Cosmos DB bascule votre compte sans entrées utilisateur en cas de sinistre régional.

  • Même si votre compte Azure Cosmos DB est hautement disponible, votre application n’est peut-être pas correctement conçue pour rester hautement disponible. Pour tester la haute disponibilité de bout en bout de votre application, dans le cadre de procédures de récupération d’urgence (DR) ou de test de votre application, désactivez temporairement le basculement managé par le service pour votre compte. Appelez le basculement manuel au moyen de PowerShell, d’Azure CLI ou du Portail Azure, puis analyser votre application. Une fois le test achevé, vous pouvez basculer vers la région primaire et restaurer le basculement managé par le service pour le compte.

    Important

    N’appelez pas de basculement manuel lors d’une panne Azure Cosmos DB sur la région source ou de destination. Le basculement manuel nécessite une connectivité régionale, pour garder la cohérence des données, et va ainsi échouer.

  • Dans un environnement de base de données globalement distribuée, il existe une relation directe entre le niveau de cohérence et la durabilité des données en situation de panne à l'échelle d'une région. Au moment de l'élaboration de votre plan de continuité d'activité, vous devez identifier le délai maximal acceptable nécessaire à la récupération complète de l'application après un événement perturbateur (c’est-à-dire le RTO). Vous devez également déterminer sur quelle période maximale l'application peut accepter de perdre les mises à jour de données récentes lors de la récupération après un événement perturbateur (c’est-à-dire le RPO). Pour plus d’informations concernant le RTO et le RPO, consultez Niveaux de cohérence dans Azure Cosmos DB.

À quoi s’attendre lors d’une panne régionale d’Azure Cosmos DB

Pour les comptes à région unique, les clients sont confrontés à une perte de disponibilité en lecture et en écriture lors d’une panne régionale Azure Cosmos DB. Les comptes à plusieurs régions connaissent des comportements différents, tels que décrits dans le tableau suivant.

Régions d’écriture Basculement managé par le service À quoi s’attendre Procédure à suivre
Région d’écriture unique Non activé En cas de panne dans une région de lecture lorsque vous n’utilisez pas la cohérence forte, tous les clients redirigent vers d’autres régions. Il n’y a aucune perte de disponibilité en lecture ou en écriture et aucune perte de données. Lorsque vous utilisez une cohérence forte, une panne dans une région de lecture peut affecter la disponibilité en écriture si moins de deux régions de lecture restent actives.

En cas de panne dans la région d’écriture, les clients rencontrent une perte de disponibilité en écriture. Si vous ne sélectionnez pas la cohérence forte, le service peut ne pas répliquer certaines données dans les régions actives restantes. Cette réplication repose sur le niveau de cohérence sélectionné. Si la région affectée subit une perte de données permanente, vous risquez la perte des données non répliquées.

Azure Cosmos DB restaure la disponibilité en écriture à la fin de la panne.
Pendant la panne, assurez-vous qu’il y a suffisamment d’unités de requête approvisionnées dans les régions restantes pour prendre en charge le trafic de lecture.

N’effectuez pas de basculement manuel pendant la panne, car il ne va pas fonctionner.

Lorsque la panne est terminée, réajustez les unités de requête approvisionnées en conséquence.
Région d’écriture unique activé En cas de panne dans une région de lecture lorsque vous n’utilisez pas la cohérence forte, tous les clients redirigent vers d’autres régions. Il n’y a aucune perte de disponibilité en lecture ou en écriture et aucune perte de données. Lorsque vous utilisez une cohérence forte, la panne d’une région de lecture peut affecter la disponibilité en écriture si moins de deux régions de lecture restent actives.

En cas de panne dans la région d’écriture, les clients subissent une perte de disponibilité en écriture jusqu’à ce qu’Azure Cosmos DB choisisse une nouvelle région comme nouvelle région d’écriture selon vos préférences. Si vous ne sélectionnez pas la cohérence forte, le service peut ne pas répliquer certaines données dans les régions actives restantes. Cette réplication repose sur le niveau de cohérence sélectionné. Si la région affectée subit une perte de données permanente, vous risquez la perte des données non répliquées.
Pendant la panne, assurez-vous qu’il y a suffisamment d’unités de requête approvisionnées dans les régions restantes pour prendre en charge le trafic de lecture.

N’effectuez pas de basculement manuel pendant la panne, car il ne va pas fonctionner.

À la fin de la panne, vous pouvez replacer la région d’écriture dans la région d’origine et réajuster les RU approvisionnées en conséquence. Les comptes utilisant l’API pour NoSQL peuvent aussi récupérer les données non répliquées dans la région ayant échoué à partir de votre flux de conflit.
Régions d’écriture multiples Non applicable Les données récemment mises à jour dans la région défaillante peuvent ne pas être disponibles dans les régions actives restantes. Les niveaux de cohérence de session, la garantie de préfixe et l’éventuelle garantissent une obsolescence inférieure à 15 minutes. L’obsolescence limitée garantit moins de K mises à jour ou T secondes, selon la configuration. Si la région affectée subit une perte de données permanente, vous risquez la perte des données non répliquées. Pendant la panne, assurez-vous qu’il y a suffisamment d’unités de requête approvisionnées dans les régions restantes pour prendre en charge davantage de trafic.

À la fin de la panne, vous pouvez réajuster les unités de requête approvisionnées en conséquence. Si possible, Azure Cosmos DB récupère les données non répliquées dans la région indisponible. Cette récupération se sert de la méthode de résolution des conflits que vous configurez pour les comptes utilisant l’API pour NoSQL. Pour les comptes utilisant d’autres API, cette récupération se sert de la méthode Dernière écriture prioritaire.

Étapes suivantes

Vous pouvez ensuite lire les articles suivants :