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 en 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 données acceptable pouvant être perdue en raison d'une panne est appelée "objectif de point de récupération" (RPO, Recovery Point Objective). Elle est exprimée en temps de transactions perdues. 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, aucune perte de données en cas de défaillance et 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 de base de la base de données à l'aide de sauvegardes de base de données. AlloyDB Omni est compatible avec les sauvegardes à l'aide de pgBackRest et 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 tombe en panne, elle peut être restaurée à partir d'une sauvegarde avec un RPO de quelques minutes et un RTO de quelques minutes à quelques heures, en fonction de 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 répliquées. Vous pouvez configurer AlloyDB Omni pour qu'il utilise la réplication en flux continu 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, notez 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 à des dizaines ou des centaines de millisecondes de distance. 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 pour s'assurer qu'il est protégé immédiatement 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 bases de données. Vous trouverez ci-dessous quelques-unes des techniques et des outils 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 bases de données :
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 réplique opérationnelle, ce qui minimise les temps d'arrêt. Les requêtes sont routées de sorte 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 : méthodes permettant de revenir à l'architecture d'origine à l'aide des nœuds principal et d'instances dupliquées dans leur capacité d'origine et leur état 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 gère 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 du leader, 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 Distributed Configuration Store (DCS) appelé 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 santé et l'état actuel, ce qui 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 d'intégrité des serveurs de backend auxquels il se connecte en effectuant des vérifications de l'état. Si un serveur échoue à une vérification de l'état'état, HAProxy cesse de lui envoyer du trafic jusqu'à ce qu'il réussisse à nouveau les vérifications de l'é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 les 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 standby 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 échoue avant que le serveur de secours ne soit à jour. Les nœuds de secours peuvent être en retard par rapport au nœud principal, ce qui peut entraîner des incohérences lors du 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é, de cohérence et de performances des données. La réplication synchrone est préférable dans les scénarios où l'intégrité des données et la 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 un standby synchrone dans la même région, mais dans une autre zone ou un autre centre de données à proximité, et un deuxième standby asynchrone dans une autre région ou un centre de données plus éloigné pour vous protéger contre d'éventuelles pannes régionales.