La haute disponibilité (HA) dans AlloyDB pour PostgreSQL permet de maintenir votre base de données opérationnelle et vos données accessibles aux applications clientes en cas de défaillance d'une zone ou d'une instance. Contrairement aux instances zonales, qui peuvent subir des temps d'arrêt prolongés en cas de panne, les instances à haute disponibilité basculent automatiquement entre les nœuds actifs et de secours dans différentes zones. Pour configurer une instance pour la haute disponibilité, consultez Afficher les paramètres des clusters et des instances.
Instances principale et secondaire
Une instance principale AlloyDB configurée avec la haute disponibilité inclut un nœud actif et un nœud de secours, situés dans des zones différentes. Pour le stockage, AlloyDB utilise un persisteur de journaux régional pour stocker les journaux WAL (Write-Ahead Log) de la base de données et le service de stockage régional AlloyDB pour stocker les blocs de données. L'adresse IP de l'instance achemine le trafic vers le nœud actif à l'aide d'un équilibreur de charge.
Lors du traitement des écritures, la base de données AlloyDB écrit d'abord le WAL dans son outil de persistance des journaux régional sur le nœud actif, puis transfère de manière asynchrone les journaux vers les serveurs de traitement des journaux régionaux dans AlloyDB, qui matérialisent les journaux en blocs de données pour un stockage à long terme. AlloyDB nettoie ensuite les journaux qui ont été traités avec succès.
Le schéma suivant illustre l'architecture à haute disponibilité.
Fig. 1. Architecture à haute disponibilité.
Basculement
Si le nœud actif devient indisponible, AlloyDB bascule automatiquement l'instance principale vers son nœud de secours, qui devient le nouveau nœud actif. L'équilibreur de charge reconnaît le nouveau nœud actif et commence à lui acheminer le trafic. Après un basculement, le nouveau nœud actif reste actif même après la reconnexion du nœud d'origine. Aucune perte de données ne se produit lors du basculement en raison des écritures WAL synchrones dans le système de persistance des journaux régional.
Le schéma suivant illustre le flux de trafic après le basculement.
Fig. 2. Flux de trafic après le basculement.
Un basculement se produit dans la séquence d'événements suivante :
- Le nœud ou la zone actif échoue. Le système de surveillance de l'état d'AlloyDB vérifie régulièrement si le nœud actif est opérationnel. Si le système de surveillance de l'état échoue à plusieurs vérifications, il lance le basculement. Cette détection peut prendre jusqu'à 30 secondes.
- La base de données démarre sur le nœud de secours et commence à accepter les connexions. Cela prend généralement moins de 30 secondes.
- Le nœud de secours devient le nœud principal. À l'aide de l'adresse IP statique de l'instance, le nouveau nœud principal commence à diffuser des données, et les requêtes client aboutissent après une reconnexion.
- AlloyDB recrée un nœud de secours dans la zone précédemment active. Ce nœud de secours est alors prêt pour les futurs basculements.
Conditions requises
Pour qu'AlloyDB autorise le basculement, la configuration doit répondre aux critères suivants :
- L'instance principale doit se trouver dans un état de fonctionnement normal (elle n'est pas arrêtée ni en cours de maintenance).
- La zone de secours et le nœud de secours doivent tous deux être opérationnels.
Architecture de secours à chaud
Les instances AlloyDB avec PostgreSQL 18 offrent un basculement amélioré grâce à la fonctionnalité de secours à chaud.
Avec la fonctionnalité de secours à chaud, AlloyDB exécute le nœud de secours en tant qu'instance répliquée. Lors du basculement, cette instance répliquée peut passer plus rapidement en mode lecture-écriture, ce qui réduit les temps d'arrêt. De plus, la réplication permet d'utiliser des caches chauds, ce qui contribue à garantir des performances de requête constantes après le basculement.
Le schéma suivant illustre l'architecture haute disponibilité avec la mise en veille à chaud incluse.
Fig. 3. Système de secours à chaud.
Pools de lecture
Les instances de pool de lecture comportant au moins deux nœuds offrent une disponibilité élevée. Les nœuds sont répartis de manière uniforme entre les zones, ce qui permet de résister aux défaillances. En cas de défaillance d'un nœud ou d'une zone, un équilibreur de charge régional achemine le trafic vers les nœuds opérationnels restants, ce qui évite tout temps d'arrêt pour vos clients.
Les pools de lecture restent en ligne lors du basculement d'une instance principale. La réplication WAL à partir de l'instance principale est temporairement suspendue pendant le basculement et reprend automatiquement une fois l'instance principale récupérée.