Ce document présente la configuration de la haute disponibilité pour les instances AlloyDB pour PostgreSQL. Pour configurer la haute disponibilité pour une nouvelle instance ou pour l'activer sur une instance existante, consultez la page Afficher les paramètres du cluster et de l'instance settings.
Une configuration à haute disponibilité garantit la continuité des opérations, même en cas de défaillance. Alors que les instances zonales peuvent subir des temps d'arrêt prolongés en cas de défaillance, la haute disponibilité permet à vos données de rester disponibles pour les applications clientes.
Instances principale et secondaire
Une instance principale AlloyDB configurée avec la haute disponibilité comprend un nœud actif et un nœud de secours, situés dans des zones différentes. Pour le stockage, AlloyDB utilise un persistor de journaux régional pour stocker les journaux de transactions (WAL) de la base de données et le service de stockage régional d'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 les WAL dans son persistor de 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 d'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.
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 à y 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 persistor de 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 active échoue. Le système de surveillance de l'état d'AlloyDB vérifie périodiquement si le nœud actif est sain. Si le système de surveillance de l'état échoue à plusieurs reprises, 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 (c'est-à-dire qu'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 sains.
Nouvelle architecture
Les instances AlloyDB nouvellement créées avec PostgreSQL 18 offrent un basculement amélioré à l'aide d'une instance dupliquée avec accès en lecture sur le nœud de secours (nœud de secours à chaud).
AlloyDB inclut une instance dupliquée avec accès en lecture sur le nœud de secours à chaud. Lors du basculement, cette instance dupliquée avec accès en lecture peut passer plus rapidement en mode lecture/écriture, ce qui réduit les temps d'arrêt. De plus, l'instance dupliquée avec accès en lecture active les caches à chaud, ce qui permet de garantir des performances de requête cohérentes après le basculement.
Le schéma suivant illustre l'architecture à haute disponibilité avec le secours à chaud inclus.
Fig. 3. 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 égale entre les zones, ce qui crée une résilience aux défaillances. En cas de défaillance, comme une défaillance de nœud ou de zone, un équilibreur de charge régional achemine le trafic vers les nœuds sains restants, ce qui garantit l'absence de temps d'arrêt pour vos clients.
Les pools de lecture restent en ligne lors d'un basculement d'instance principale. La réplication WAL à partir de l'instance principale est temporairement mise en pause lors du basculement et reprend automatiquement une fois l'instance principale récupérée.
Étape suivante
- Basculer manuellement une instance principale ou secondaire.
- Tester la haute disponibilité d'une instance principale.
- Réduire les coûts en utilisant des instances de base.