Haute disponibilité PostgreSQL avec architectures maître-esclave et maître-maître

Vous trouverez ci-dessous un extrait de notre livre blanc "PostgreSQL Management and Automation with ClusterControl" qui peut être téléchargé gratuitement.

Note de révision : Gardez à l'esprit que les termes utilisés dans ce blog Maître-Esclave sont synonymes de termes Maître-Veille utilisés par PostgreSQL. Nous utilisons Maître-Esclave pour garder le parallélisme avec les autres technologies.

Pour la configuration HA, nous pouvons avoir plusieurs architectures, mais les architectures de base seraient maître-esclave et maître-maître. Les serveurs de base de données peuvent fonctionner ensemble pour permettre à un deuxième serveur de prendre rapidement le relais en cas de défaillance du serveur principal (haute disponibilité). ), ou pour permettre à plusieurs ordinateurs de servir les mêmes données (équilibrage de charge).

Architectures maître-esclave PostgreSQL

Ces architectures nous permettent de maintenir une base de données maître avec un ou plusieurs serveurs de secours prêts à reprendre les opérations en cas de défaillance du serveur principal. Ces bases de données de secours resteront synchronisées (ou presque synchronisées) avec le maître.

La réplication entre le maître et les esclaves peut se faire via des instructions SQL (redondances logiques) ou via les modifications internes de la structure des données (redondances physiques). PostgreSQL utilise un flux d'enregistrements de journal à écriture anticipée (WAL) pour maintenir la synchronisation des bases de données de secours. Si le serveur principal tombe en panne, le serveur de secours contient presque toutes les données du serveur principal et peut rapidement devenir le nouveau serveur de base de données maître. Cela peut être synchrone ou asynchrone et ne peut être effectué que pour l'ensemble du serveur de base de données.

La configuration de la réplication en continu est une tâche qui nécessite de suivre attentivement certaines étapes. Pour ces étapes et quelques informations supplémentaires sur ce sujet, veuillez consulter :Devenir un administrateur de base de données PostgreSQL - Comment configurer la réplication en continu pour une haute disponibilité.

À partir de la version 10, PostgreSQL inclut l'option de configuration de la réplication logique.

La réplication logique permet à un serveur de base de données d'envoyer un flux de modifications de données à un autre serveur. La réplication logique PostgreSQL construit un flux de modifications de données logiques à partir du WAL. La réplication logique permet de répliquer les modifications de données des tables individuelles. Il ne nécessite pas qu'un serveur particulier soit désigné comme maître ou réplique, mais permet aux données de circuler dans plusieurs directions.

Vous pouvez trouver plus d'informations concernant la réplication logique :Blog :Un aperçu de la réplication logique dans PostgreSQL.

Pour assurer efficacement une haute disponibilité, il ne suffit pas d'avoir une architecture maître-esclave. Nous devons également activer une forme de basculement automatique, donc si quelque chose échoue, nous pouvons avoir le plus petit retard possible dans la reprise des fonctionnalités normales. PostgreSQL n'inclut pas de mécanisme de basculement automatique pour identifier les défaillances sur la base de données principale et notifier au salve de s'en approprier, ce qui nécessitera un peu de travail de la part du DBA. Vous devez travailler sur un script qui inclut la commande pg_ctl promote, qui promouvra l'esclave en tant que nouveau maître. Il existe également des outils tiers pour cette automatisation. De nombreux outils de ce type existent et sont bien intégrés aux fonctionnalités du système d'exploitation requises pour un basculement réussi, telles que la migration d'adresse IP.

Après un basculement, vous devez modifier votre application en conséquence pour travailler avec le nouveau maître. Vous n'aurez également qu'un seul serveur qui fonctionnera, donc la recréation de l'architecture maître-esclave doit être faite, donc nous revenons à la même situation normale que nous avions avant le problème.

Architectures maître-maître PostgreSQL

Cette architecture permet de minimiser l'impact d'une erreur dans l'un des nœuds, car l'autre nœud peut prendre en charge tout le trafic, affectant peut-être légèrement les performances, mais sans jamais perdre de fonctionnalité. Il est également utilisé pour réaliser (et c'est peut-être un point encore plus intéressant) l'évolutivité horizontale (scale-out), à l'opposé du concept d'évolutivité verticale où nous ajoutons plus de ressources à un serveur (scale-up).

Pour implémenter cette architecture, vous devrez utiliser des outils externes, car cette fonctionnalité n'est pas (encore) supportée nativement par PostgreSQL.

Vous devez être très prudent lorsque vous choisissez une solution pour la mise en œuvre de master-master, car il existe de nombreux produits différents. Beaucoup d'entre eux sont encore "verts", avec peu d'utilisateurs sérieux ou de cas de réussite. Certains autres projets ont par contre été abandonnés, car il n'y a pas de mainteneurs actifs.

Pour plus d'informations sur les outils disponibles, veuillez consulter :Blog :Top PG Clustering HA Solutions for PostgreSQL.

Équilibrage de charge et regroupement de connexions

Plusieurs outils d'équilibrage de charge peuvent être utilisés pour gérer le trafic de votre application afin de tirer le meilleur parti de l'architecture de votre base de données. De la même manière, il en existe d'autres qui peuvent vous aider à gérer la manière dont l'application se connecte à la base de données, en mutualisant ces connexions et en les réutilisant entre différentes requêtes.

Certains produits sont utilisés à ces deux fins, comme le pgpool bien connu, et d'autres qui se concentreront sur une seule de ces fonctionnalités, comme pgbouncer (regroupement de connexions) et HAProxy (utilisé pour l'équilibrage de charge).