Partager via

Haute disponibilité dans Azure Cosmos DB for PostgreSQL

  • Article

S’APPLIQUE À : Azure Cosmos DB for PostgreSQL (avec l’extension de base de données Citus pour PostgreSQL)

La haute disponibilité (HA) réduit les temps d’arrêt de la base de données en conservant des réplicas de secours de chaque nœud d’un cluster. Si un nœud devient inactif, Azure Cosmos DB for PostgreSQL bascule les connexions entrantes du nœud défaillant vers son nœud de secours. Le basculement se produit en quelques minutes, et les nœuds promus disposent toujours de données actualisées par le biais de la réplication en streaming synchrone PostgreSQL.

Tous les nœuds principaux d’un cluster sont approvisionnés dans une même zone de disponibilité pour améliorer la latence entre les nœuds. La zone de disponibilité préférée vous permet de placer tous les nœuds de cluster dans la même zone de disponibilité où l’application est déployée. Cette proximité pourrait encore améliorer les performances en réduisant la latence de la base de données d’application. Les nœuds de secours sont approvisionnés dans une autre zone. Le Portail Microsoft Azure affiche la zone de disponibilité de chaque nœud principal dans un cluster. Vous pouvez également vérifier la zone de disponibilité de chaque nœud d’un cluster à l’aide de l’une des méthodes programmatiques comme les API REST.

Même si la haute disponibilité n’est pas activée, chaque nœud dispose de son propre stockage localement redondant (LRS) avec trois réplicas synchrones gérés par le service Stockage Azure. En cas d’échec d’un seul réplica, il est détecté par stockage Azure service et est recréé de manière transparente. Pour la durabilité du stockage LRS, consultez les mesures sur cette page.

Lorsque la haute disponibilité est activée, Azure Cosmos DB for PostgreSQL exécute un nœud de secours pour chaque nœud principal du cluster. Le réplica principal et le serveur de secours utilisent la réplication PostgreSQL synchrone. Cette réplication permet aux clients d’avoir des temps d’arrêt prévisibles en cas de défaillance d’un nœud principal. En résumé, notre service détecte une défaillance sur les nœuds principaux et bascule sur les nœuds de secours sans aucune perte de données.

Pour tirer parti de la haute disponibilité sur le nœud coordinateur, les applications de base de données doivent détecter et retenter les connexions abandonnées et les transactions ayant échoué. Le coordinateur nouvellement promu est accessible avec la même chaîne de connexion.

États de la haute disponibilité

La reprise peut être divisée en trois étapes : la détection, le basculement et la reprise complète. Azure Cosmos DB for PostgreSQL exécute des contrôles d’intégrité réguliers sur chaque nœud. Il considère qu’un nœud est inactif au bout de quatre échecs. Il promeut alors un nœud de secours à l’état de nœud principal (basculement), puis crée un nouveau nœud de secours. La réplication en streaming commence en mettant à jour le nouveau nœud. Une fois toutes les données répliquées, le nœud a atteint la reprise complète.

Azure Cosmos DB for PostgreSQL affiche l’état d’avancement de son basculement sur la page de présentation des clusters du portail Azure.

  • Sain : La haute disponibilité est activée et le nœud est entièrement répliqué sur son nœud de secours.
  • Basculement en cours : Une erreur a été détectée sur le nœud principal et un basculement vers le nœud de secours a été lancé. Cet état passe à Création du nœud de secours une fois que le basculement vers le nœud de secours est terminé et que le serveur de secours devient le nouveau serveur principal.
  • Création du nœud de secours : Le nœud de secours précédent a été promue serveur principal et un nouveau nœud de secours est créé. Lorsque le nouveau nœud secondaire est prêt, cet état passe à Réplication en cours.
  • Réplication en cours : Le nouveau nœud de secours est provisionné et la synchronisation des données est en cours. Une fois que toutes les données sont répliquées sur le nouveau nœud de secours, la réplication synchrone est activée entre les nœuds principal et de secours, et l’état des nœuds redevient Sain.
  • Non : la haute disponibilité n’est pas activée sur ce nœud.

Étapes suivantes