Cette page décrit la haute disponibilité et les outils que nous vous recommandons d'utiliser.
À propos de la résilience des données
Vous pouvez considérer la résilience des données en termes de disponibilité, de délai de restauration du service et de perte de données. La disponibilité est généralement mesurée en termes de temps d'activité, et exprimée sous la forme du pourcentage du temps pendant lequel la base de données est disponible. Par exemple, pour atteindre une disponibilité de 99,99 %, votre base de données ne peut pas être indisponible plus de 52,6 minutes par an, soit 4,38 minutes par mois. Le temps nécessaire pour restaurer un service après une panne est appelé "objectif de temps de récupération" ou "RTO". La quantité de perte de données acceptable imputable à une panne est appelée "objectif de point de récupération" (RPO, Recovery Point Objective). Elle est exprimée en temps de perte de transactions. Par exemple, un RPO de 10 minutes signifie qu'en cas de défaillance, vous pourriez perdre jusqu'à 10 minutes de données.
Il est courant de définir un objectif de disponibilité, ou objectif de niveau de service (SLO), ainsi que des objectifs pour le RTO et le RPO. Par exemple, pour une charge de travail donnée, vous pouvez définir le SLO sur 99,99 %, et également exiger un RPO de 0, soit aucune perte de données en cas de défaillance, ainsi qu'un RTO de 30 secondes. Pour une autre charge de travail, vous pouvez définir le SLO sur 99,9 %, le RPO sur 5 minutes et le RTO sur 10 minutes.
Vous pouvez implémenter une résilience basique de la base de données à l'aide de sauvegardes de bases de données. AlloyDB Omni est compatible avec les sauvegardes à l'aide de pgBackRest. Il archive également les fichiers WAL (Write Ahead Log) de la base de données pour minimiser la perte de données. Avec cette approche, si votre base de données principale subit une défaillance, elle peut être restaurée à partir d'une sauvegarde, avec un RPO de quelques minutes et un RTO de quelques minutes à quelques heures, selon la taille de la base de données.
Pour des exigences de RPO et de RTO plus strictes, vous pouvez configurer AlloyDB Omni dans une configuration à haute disponibilité à l'aide de Patroni. Dans cette architecture, il existe une base de données principale et deux bases de données de secours (ou instances répliquées). Vous pouvez configurer AlloyDB Omni pour qu'il utilise la réplication en flux continu de PostgreSQL standard afin de garantir que chaque transaction validée sur la base de données principale est répliquée de manière synchrone sur les deux bases de données de secours. Cela permet d'obtenir un RPO nul et un RTO inférieur à 60 secondes pour la plupart des scénarios de défaillance.
Selon la configuration de votre cluster, la réplication synchrone peut avoir un impact sur le temps de réponse des transactions. Vous pouvez choisir de prendre le risque de perdre une petite quantité de données. Par exemple, vous pouvez avoir un RPO non nul en échange d'une latence transactionnelle plus faible en implémentant la haute disponibilité avec la réplication asynchrone au lieu de la réplication synchrone. En raison de l'impact potentiel de la réplication synchrone sur la latence des transactions, les architectures à haute disponibilité sont presque toujours implémentées dans un seul centre de données ou entre des centres de données proches les uns des autres (à quelques dizaines de kilomètres, ou avec une latence inférieure à 10 millisecondes). Toutefois, vous devez noter que cette documentation utilise la réplication synchrone par défaut.
Pour la reprise après sinistre, qui protège contre la perte d'un centre de données ou d'une région où plusieurs centres de données sont proches les uns des autres, AlloyDB Omni peut être configuré avec une réplication de flux asynchrone de la région principale vers une région secondaire, généralement à des centaines ou des milliers de kilomètres de distance, ou avec des dizaines ou des centaines de millisecondes de latence. Dans cette configuration, la réplication par flux synchrone est configurée dans la région principale entre les bases de données principale et de secours de la région. La réplication par flux asynchrone est configurée de la région principale vers une ou plusieurs régions secondaires. AlloyDB Omni peut être configuré dans la région secondaire avec plusieurs instances de base de données. Cela garantit une protection immédiate après un basculement depuis la région principale.
Fonctionnement de la haute disponibilité
Les techniques et outils spécifiques utilisés pour implémenter la haute disponibilité des bases de données peuvent varier en fonction du système de gestion de base de données employé. Vous trouverez ci-dessous des exemples d'outils et de techniques généralement utilisés pour implémenter la haute disponibilité des bases de données, qui peuvent varier en fonction du système de gestion de base de données employé :
Redondance : la réplication de votre base de données sur plusieurs serveurs ou régions géographiques offre des options de basculement en cas d'indisponibilité d'une instance principale.
Basculement automatique : mécanisme permettant de détecter les défaillances et de passer de manière fluide à une instance répliquée opérationnelle, ce qui minimise les temps d'arrêt. Les requêtes sont routées de façon à ce que les requêtes d'application atteignent le nouveau nœud principal.
Continuité des données : des mesures de protection sont mises en place pour protéger l'intégrité des données en cas de défaillance. Cela inclut les techniques de réplication et les vérifications de cohérence des données.
Clustering : le clustering consiste à regrouper plusieurs serveurs de base de données pour qu'ils fonctionnent ensemble en tant que système unique. De cette manière, tous les nœuds du cluster sont actifs et gèrent les requêtes, ce qui assure l'équilibrage de charge et la redondance.
Rétablissement : ensemble de méthodes permettant de revenir à l'architecture d'origine en restaurant des nœuds d'instances principale et répliquées avec leur capacité d'origine et dans l'état où ils se trouvaient avant le basculement.
Équilibrage de charge : la répartition des requêtes de base de données sur plusieurs instances améliore les performances et permet de gérer l'augmentation du trafic.
Surveillance et alertes : les outils de surveillance détectent les problèmes tels que les défaillances de serveur, la latence élevée et l'épuisement des ressources, et déclenchent des alertes ou des procédures de basculement automatique.
Sauvegarde et restauration : les sauvegardes peuvent être utilisées pour restaurer les bases de données à un état antérieur en cas de corruption des données ou de défaillance catastrophique.
Regroupement de connexions (facultatif) : permet d'optimiser les performances et l'évolutivité des applications qui interagissent avec vos bases de données.
Outils de haute disponibilité
Patroni est un outil de gestion de clusters Open Source pour les bases de données PostgreSQL. Il est conçu pour gérer et automatiser la haute disponibilité des clusters PostgreSQL. Patroni utilise différents systèmes de consensus distribués tels qu'etcd, Consul ou Zookeeper pour coordonner et gérer l'état du cluster. Patroni inclut des fonctionnalités et des composants clés, tels que la haute disponibilité avec basculement automatique, l'élection de l'instance répliquée principale, la réplication et la récupération. Patroni s'exécute aux côtés du service PostgreSQL sur les instances de serveur de base de données, en gérant leur état, leurs basculements et leur réplication pour assurer une haute disponibilité et une grande fiabilité.
Patroni utilise un système de consensus distribué pour stocker les métadonnées et gérer le cluster. Dans ce guide, nous utilisons un magasin de configurations distribuées (DCS, Distributed Configuration Store) nommé etcd. L'une des utilisations d'etcd consiste à stocker et à récupérer des informations sur les systèmes distribués, telles que la configuration, l'état de fonctionnement et l'état actuel. Cela garantit une configuration cohérente sur tous les nœuds.
High Availability Proxy (HAProxy) est un logiciel Open Source utilisé pour l'équilibrage de charge et le proxying des applications basées sur TCP et HTTP. Il permet d'améliorer les performances et la fiabilité des applications Web en distribuant les requêtes entrantes sur plusieurs serveurs. HAProxy propose un équilibrage de charge en répartissant le trafic réseau sur plusieurs serveurs. HAProxy gère également l'état de fonctionnement des serveurs de backend auxquels il se connecte en effectuant des vérifications de l'état. Si un serveur échoue à une vérification d'état, HAProxy cesse de lui envoyer du trafic jusqu'à ce qu'il passe avec succès les nouvelles vérifications d'état.
Points à prendre en compte concernant la réplication synchrone et asynchrone
Dans un cluster PostgreSQL géré par Patroni, la réplication peut être configurée en mode synchrone et asynchrone. Par défaut, Patroni utilise la réplication en flux continu asynchrone. Pour des exigences strictes en termes de RPO, nous vous recommandons d'utiliser la réplication synchrone.
La réplication synchrone dans PostgreSQL garantit la cohérence des données en attendant que les transactions soient écrites à la fois dans la base de données principale et dans au moins une base de données de secours synchrone avant de les valider. La réplication synchrone garantit qu'aucune donnée n'est perdue en cas de défaillance du serveur principal, ce qui assure une durabilité et une cohérence élevées des données. Le serveur principal attend les accusés de réception du serveur de secours synchrone, ce qui peut entraîner une latence plus élevée et potentiellement un débit plus faible en raison du temps d'aller-retour supplémentaire. Cela peut réduire le débit global du système, en particulier en cas de charge élevée.
La réplication asynchrone permet de valider les transactions sur le cluster principal sans attendre d'accusé de réception des clusters de secours. L'instance principale envoie les enregistrements WAL aux instances de secours, qui les appliquent de manière asynchrone. Cette approche asynchrone réduit la latence d'écriture et améliore les performances, mais présente un risque de perte de données si le serveur principal subit une défaillance avant que le serveur de secours ne soit à jour. Les instances de secours peuvent être en retard par rapport à l'instance principale, ce qui peut entraîner des incohérences en cas de basculement.
Le choix entre la réplication synchrone et asynchrone dans un cluster Patroni dépend des exigences spécifiques en matière de durabilité des données, de cohérence et de performances. La réplication synchrone est préférable dans les scénarios où l'intégrité des données et une perte de données minimale sont essentielles, tandis que la réplication asynchrone convient aux environnements où les performances et la faible latence sont prioritaires. Vous pouvez configurer une solution mixte qui implique un cluster à trois nœuds avec une instance de secours synchrone dans la même région, mais dans une autre zone ou un autre centre de données à proximité, et une deuxième instance de secours asynchrone dans une autre région ou un centre de données plus éloigné pour vous protéger contre d'éventuelles pannes régionales.