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 temps de restauration du service et de perte de données. La disponibilité est généralement mesurée en termes de temps de disponibilité 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 doit pas être indisponible plus de 52,6 minutes par an, soit 4,38 minutes par mois. Le temps nécessaire pour restaurer le service après une panne est appelé "objectif de temps de récupération" ou RTO (Recovery Time Objective). La quantité de données acceptables à perdre en cas d'indisponibilité est appelée objectif de point de récupération (RPO, Recovery Point Objective). Elle est exprimée en temps pendant lequel les transactions sont perdues. Par exemple, un RPO de 10 minutes signifie qu'en cas de défaillance, vous pouvez perdre jusqu'à 10 minutes de données.
Il est courant de définir une cible de disponibilité, ou objectif de niveau de service (SLO, Service Level Objective), ainsi que des cibles 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 exiger également 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 données avec des sauvegardes de base de données. AlloyDB Omni est compatible avec les sauvegardes à l'aide de pgBackRest et archive également les fichiers de journal WAL (Write-Ahead Logging) 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 PDMA de quelques minutes et un DMIA de quelques minutes à plusieurs heures, en fonction de la taille de la base de données.
Pour des exigences RPO et RTO plus strictes, vous pouvez configurer AlloyDB Omni en 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épliques. Vous pouvez configurer AlloyDB Omni pour utiliser la réplication en streaming PostgreSQL standard afin de vous assurer que chaque transaction validée sur la base de données principale est répliquée de manière synchrone dans les deux bases de données de secours. Cela offre un RPO nul et un RTO inférieur à soixante 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 risquer une petite perte de données. Par exemple, vous pouvez avoir un RPO non nul en échange d'une latence transactionnelle plus faible en implémentant une haute disponibilité avec une réplication asynchrone plutôt qu'une 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 (à quelques dizaines de kilomètres l'un de l'autre, 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 consiste à se protéger contre la perte d'un centre de données ou d'une région où plusieurs centres de données se trouvent à proximité, AlloyDB Omni peut être configuré avec une réplication en streaming asynchrone de la région principale vers une région secondaire, généralement à des centaines ou milliers de kilomètres de distance, ou à des dizaines à des centaines de millisecondes d'intervalle. Dans cette configuration, la région principale est configurée avec une réplication par flux synchrone entre les bases de données principales et de secours de la région, et une 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é pour les bases de données peuvent varier en fonction du système de gestion de base de données. Vous trouverez ci-dessous quelques-unes des techniques et des outils généralement impliqués dans la mise en œuvre d'une haute disponibilité pour les bases de données, qui peuvent varier en fonction du système de gestion des 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 de défaillance d'une instance principale.
Failover automatique: mécanisme permettant de détecter les défaillances et de passer facilement à un réplica en bon état, ce qui réduit au maximum les temps d'arrêt. Les requêtes sont acheminées afin 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 la 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 permet d'équilibrer la charge et de garantir la redondance.
Retour: 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 pannes de serveur, la latence élevée, l'épuisement des ressources et les alertes de déclenchement, ou les 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 de données ou de défaillance catastrophique.
Mise en pool de connexions (facultatif): optimise 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 cluster Open Source pour les bases de données PostgreSQL, conçu pour gérer et automatiser la haute disponibilité des clusters PostgreSQL. Patroni utilise divers systèmes de consensus distribués tels que etcd, Consul ou Zookeeper pour coordonner et gérer l'état du cluster. Parmi les principales fonctionnalités et composants de Patroni, citons la haute disponibilité avec basculement automatique, l'élection du leader, la réplication et la récupération. Patroni s'exécute avec le service PostgreSQL sur les instances de serveur de base de données, en gérant leur état, leurs basculements et leur réplication pour garantir une haute disponibilité et une 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.
HAProxy (High Availability Proxy) est un logiciel Open Source utilisé pour l'équilibrage de charge et le proxying des applications 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 offre un équilibrage de charge en distribuant le trafic réseau sur plusieurs serveurs. HAProxy maintient également l'état de santé des serveurs backend auxquels il se connecte en effectuant des vérifications de l'état. Si un serveur échoue lors d'une vérification de l'état, HAProxy cesse de lui envoyer du trafic jusqu'à ce qu'il réussisse à nouveau les vérifications de l'état.
Remarques 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 asynchrone. Pour des exigences RPO strictes, 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 sur le principal et sur au moins un nœud de secours synchrone avant d'être validées. La réplication synchrone garantit que les données ne sont pas perdues en cas de défaillance de l'instance principale, ce qui assure une durabilité et une cohérence fortes des données. Le principal attend les accusés de réception de la veille synchrone, ce qui peut entraîner une latence plus élevée et un débit potentiellement inférieur en raison du temps de va-et-vient 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 d'effectuer un commit des transactions sur le cluster principal sans attendre de confirmation des clusters de secours. L'instance principale envoie des 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 le risque de perte de données si le principal échoue avant que le standby ne l'ait rattrapé. Les serveurs de secours peuvent être en retard par rapport au serveur principal, ce qui peut entraîner des incohérences potentielles lors du basculement.
Le choix entre la réplication synchrone et asynchrone dans un cluster Patroni dépend des exigences spécifiques en termes 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 latence réduite sont prioritaires. Vous pouvez configurer une solution mixte qui implique d'avoir un cluster à trois nœuds avec un mode de secours synchrone dans la même région, mais dans une zone ou un centre de données à proximité, et un deuxième mode de secours asynchrone dans une autre région ou un centre de données plus éloigné pour vous protéger contre les pannes régionales potentielles.