Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
La haute disponibilité (HA) au sein de la région évite les temps d’arrêt de la base de données en conservant des réplicas de secours de chaque partition d’un cluster. Si une partition ne répond pas pour une raison quelconque, Azure DocumentDB bascule les connexions entrantes de la partition ayant échoué vers son serveur de secours. Lorsque le basculement se produit, les partitions promues ont toujours des données fraîches via la réplication synchrone.
Toutes les partitions principales d’un cluster sont provisionnées dans une seule zone de disponibilité (AZ) pour une meilleure latence entre les partitions. Les unités en attente sont approvisionnés dans une autre zone.
Même sans haute disponibilité activée, chaque partition a son propre stockage localement redondant (LRS) avec trois réplicas synchrones gérés par le service Stockage Azure. Les trois réplicas se trouvent dans la région Azure du cluster. En cas de défaillance d'une seule réplique, le service Azure Storage la détecte et recrée de manière transparente la réplique défaillante. Consultez les métriques de cette page pour la durabilité du stockage LRS.
Lorsque la haute disponibilité est activée, Azure DocumentDB exécute une partition de secours pour chaque partition principale du cluster. Chaque partition principale et de secours a la même configuration de calcul et de stockage. Le serveur principal et son serveur de secours utilisent la réplication synchrone. Ce type de réplication vous permet d’avoir toujours les mêmes données sur les partitions primaires et de secours de votre cluster. En un mot, notre service détecte une défaillance sur les partitions principales et bascule vers des partitions de secours sans perte de données.
La chaîne de connexion de cluster reste toujours la même, quel que soit le basculement. Cela permet au service d’extraire des modifications dans les partitions physiques qui servent les requêtes des applications.
Lorsque la haute disponibilité dans la région est activée sur le cluster, chaque partition de cluster est couverte par le contrat de niveau de service (SLA) de 99,99% pour la disponibilité.
La haute disponibilité peut être activée au moment de la création du cluster. La haute disponibilité peut également être activée et désactivée à tout moment sur un cluster Azure DocumentDB existant. Il n’existe aucun temps d’arrêt de base de données lorsque la haute disponibilité est activée ou désactivée sur un cluster Azure DocumentDB.
Que se passe-t-il pendant un failover?
Chaque basculement de partition se compose de trois phases : détection d’indisponibilité, basculement vers la partition de secours et recréation de la partition de secours. Le service assure la surveillance continue de la disponibilité de chaque shard principal et de secours dans le cluster en effectuant une vérification de l'état périodique. Lorsque le contrôle d’intégrité indique de manière fiable que la partition n’est pas répondre et doit être déclarée en échec, le basculement réel (commutateur) vers la partition de secours est lancé.
Pendant la phase de basculement, les lectures et les écritures de base de données sont redirigées vers la partition de secours. La réplication synchrone entre chaque partition principale et de secours garantit que la partition de secours a toujours le même jeu de données que son principal. Cela permet à toutes les redirections d’être effectuées sans perte de données. Le passage en mode veille se fait sans interruption pour les lectures. Les opérations d’écriture peuvent nécessiter des réessais internes du service pendant la phase de basculement. Ces nouvelles tentatives peuvent être considérées comme une lenteur d’écriture côté application.
Une fois le basculement de partition terminé, le cluster est entièrement opérationnel. La dernière étape pour revenir à la configuration à haut niveau de disponibilité d’origine consiste à recréer la partition de secours. Cette recréation de fragment en attente est effectuée sans interruption ni impact sur le fragment principal.