Gestion de la haute disponibilité de PostgreSQL – Partie I :Basculement automatique de PostgreSQL

La gestion de la haute disponibilité (HA) dans votre hébergement PostgreSQL est un sujet très important pour garantir que vos clusters de déploiement de base de données maintiennent une disponibilité exceptionnelle et de solides performances opérationnelles afin que vos données soient toujours disponibles pour votre application. Dans un article de blog précédent, nous vous avions présenté la configuration de la haute disponibilité pour PostgreSQL à l'aide de la réplication en continu. Nous allons maintenant vous montrer comment gérer au mieux la haute disponibilité côté client.

Il existe plusieurs outils disponibles pour gérer la haute disponibilité (HA) de vos clusters de déploiement PostgreSQL à l'aide de la réplication en continu. Ces solutions offrent des capacités de basculement automatique, surveillent la disponibilité et l'état du système, la réplication, la gestion des utilisateurs et d'autres tâches administratives utiles sur les cas d'utilisation des bases de données Postgres. Certaines des principales solutions open source incluent :

1. Basculement automatique PostgreSQL par ClusterLabs

2. Replication Manager pour les clusters PostgreSQL par repmgr (2ndQuadrant)

3. Patroni par Zalando

Chaque outil fournit sa propre façon de gérer les clusters PostgreSQL à haute disponibilité. Dans notre série d'articles en trois parties sur la haute disponibilité pour PostgreSQL, nous partagerons une vue d'ensemble, les prérequis et les résultats de travail et de test pour chacun de ces trois outils. Ici, dans la partie 1, nous allons nous plonger dans la solution PAF de ClusterLabs.

• Gestion de la haute disponibilité dans PostgreSQL – Partie 2 :Replication Manager
• Gestion de la haute disponibilité dans PostgreSQL – Partie 3 :Patroni

Comment gérer la haute disponibilité pour votre base de données PostgreSQL ?

PostgreSQL Automatic Failover (PAF) est une solution de gestion de haute disponibilité pour PostgreSQL par ClusterLabs. Il utilise la réplication synchrone Postgres pour garantir qu'aucune donnée n'est perdue au moment de l'opération de basculement. Il utilise la pile Pacemaker et Corosync standard de l'industrie. En combinant les applications Pacemaker et Corosync, vous serez en mesure de détecter les défaillances de la base de données PostgreSQL dans le système et d'agir en conséquence.

Pacemaker est un service capable de gérer de nombreuses ressources, et le fait avec l'aide de ses agents de ressources. Les agents ressources ont alors la responsabilité de gérer une ressource spécifique, comment ils doivent se comporter et informer Pacemaker de leurs résultats.

L'implémentation de votre agent de ressources doit être conforme à la spécification Open Cluster Framework (OCF). Cette spécification définit le comportement des agents de ressources et la mise en œuvre de méthodes telles que l'arrêt, le démarrage, la promotion, la rétrogradation et l'interaction avec Pacemaker.

PAF est un agent de ressources OCF pour Postgres écrit en Perl. Une fois votre cluster de bases de données construit à l'aide de la réplication en continu interne, PAF est capable d'exposer à Pacemaker l'état actuel de l'instance PostgreSQL sur chacun des nœuds des bases de données :maître, esclave, arrêté, rattrapage, équilibreur de charge, etc.

Fonctionnement du basculement automatique Postgres

PAF communique avec Pacemaker concernant l'état du cluster et surveille le fonctionnement de la base de données PostgreSQL. En cas d'échec, il informe Pacemaker, et s'il n'y a aucune chance que le maître actuel soit récupéré, il déclenchera une élection entre l'un des serveurs de base de données de secours actuels. Avec le robuste Pacemaker en place, Postgres Automatic Failover effectuera des actions de gestion telles que le démarrage, l'arrêt, la surveillance et le basculement sur tous les nœuds des bases de données Postgres.

Gérer la haute disponibilité dans PostgreSQL – Partie I :Basculement automatique par ClusterLabsClick To Tweet

Basculement automatique PostgreSQL pour la configuration haute disponibilité (HA)

• PAF prend en charge PostgreSQL version 9.3 et ultérieure.
• PAF n'est pas responsable de la création du maître/de secours PostgreSQL ou de sa configuration - vous devez créer et configurer la réplication en continu avant d'utiliser PAF.
• PAF ne modifie aucune configuration ou configuration requise de PostgreSQL. Cependant, les utilisateurs de la base de données doivent suivre quelques prérequis tels que :
  • L'esclave doit être configuré en tant que secours automatique. Les nœuds esclaves de secours peuvent être interrogés en tant que bases de données en lecture seule.
  • Un fichier de modèle de récupération (par défaut :/recovery.conf.pcmk) doit être fourni avec les paramètres ci-dessous :
    • mode_veille =sur
    • recovery_target_timeline ='le plus récent'
    • primary_conninfo doit avoir le paramètre application_name défini et défini sur le nom du nœud local comme dans Pacemaker.
• PAF expose plusieurs paramètres liés à la gestion d'une ressource Postgres. Cela peut être configuré en fonction de ses besoins. Voici les paramètres :
  • bindir : emplacement des binaires PostgreSQL (par défaut :/usr/bin)
  • pgdata : emplacement du PGDATA de votre instance (par défaut :/var/lib/pgsql/data)
  • répertoire des données : chemin vers le répertoire défini dans data_directory à partir de votre fichier postgresql.conf
  • pghost : le répertoire socket ou l'adresse IP à utiliser pour se connecter à l'instance locale (par défaut :/tmp)
  • pgport : le port pour se connecter à l'instance locale (par défaut :5432)
  • modèle_récupération : le modèle local qui sera copié en tant que fichier PGDATA/recovery.conf. Ce fichier modèle doit exister sur tous les nœuds (par défaut :$PGDATA/recovery.conf.pcmk)
  • start_opts : Arguments supplémentaires donnés au processus Postgres au démarrage. Voir « postgres –help » pour les options disponibles. Utile lorsque le fichier postgresql.conf n'est pas dans le répertoire de données (PGDATA), par exemple :-c config_file=/etc/postgresql/9.3/main/postgresql.conf
  • utilisateur_système : le propriétaire système du processus de votre instance (par défaut :postgres)
  • décalage maximal : décalage maximum autorisé sur une veille avant que nous ne lui définissions un score principal négatif

Avantages du basculement automatique Postgres

• PAF fournit à l'utilisateur une configuration et une configuration pratiques gratuites de PostgreSQL.
• PAF peut gérer une panne de nœud et déclencher des élections lorsque le maître tombe en panne.
• Le comportement de quorum peut être appliqué dans PAF.
• Il fournira une solution complète de gestion des bases de données à haute disponibilité (HA) pour la ressource, y compris le démarrage, l'arrêt, la surveillance et la gestion des scénarios d'isolement du réseau.
• C'est une solution distribuée, qui permet la gestion de n'importe quel nœud à partir d'un autre nœud.

Inconvénients du basculement automatique Postgres

• PAF ne détecte pas si un nœud de secours est mal configuré avec un nœud inconnu ou inexistant dans la configuration de récupération. Le nœud sera affiché comme esclave, même si la veille est en cours d'exécution sans se connecter au nœud maître/de secours en cascade.
• Nécessite l'ouverture d'un port supplémentaire (5405 par défaut) pour la communication des composants Pacemaker et Corosync via UDP.
• Ne prend pas en charge la configuration basée sur NAT.
• Pas de prise en charge de pg_rewind.

Haute disponibilité pour les scénarios de test PostgreSQL

Nous avons effectué quelques tests pour déterminer la capacité de gestion de la haute disponibilité (ha) de PostgreSQL à l'aide de PAF sur certains cas d'utilisation. Tous ces tests ont été exécutés pendant que l'application s'exécutait et insérait des données dans la base de données PostgreSQL. L'application a été écrite à l'aide du pilote JDBC PostgreSQL Java en exploitant la capacité de basculement de connexion.

Tests de serveur de secours

Tests de serveur maître/primaire

Tests d'isolation réseau

Tests divers

Le PAF est-il la solution pour la haute disponibilité de PostgreSQL ?

Le basculement automatique Postgres offre plusieurs avantages dans la gestion de la haute disponibilité (HA) PostgreSQL dans de nombreux cas d'utilisation. PAF utilise le basculement d'adresse IP au lieu de redémarrer le serveur de secours pour se connecter au nouveau maître lors d'un événement de basculement. Cela s'avère avantageux dans les scénarios où l'utilisateur ne souhaite pas redémarrer les nœuds de secours. PAF nécessite également très peu d'intervention manuelle et gère la santé globale de toutes les ressources des bases de données Postgres. Le seul cas où une intervention manuelle est requise est en cas de divergence des données chronologiques où l'utilisateur peut choisir d'utiliser pg_rewind.

Dans la partie 1, nous avons discuté des capacités et du fonctionnement de PostgreSQL Automatic Failover (PAF) de ClusterLabs, et dans la partie 2, nous discuterons les mêmes aspects de haute disponibilité en utilisant le Replication Manager pour les clusters PostgreSQL (repmgr) de 2ndQuadrant. Assurez-vous de revenir à la partie 3, où nous couvrirons également Patroni de Zalando et comparerons les trois solutions open source pour vous aider à déterminer celle qui convient le mieux à votre application.

Dans le blog de la partie 1, nous avons discuté des capacités, des meilleures pratiques et du fonctionnement de PAF par ClusterLabs, et dans l'article de blog de la partie 2, nous allons discuter du même sujet des aspects de haute disponibilité à l'aide du gestionnaire de réplication pour les clusters Postgresql (repmgr) par 2ndQuadrant. N'oubliez pas de consulter notre article de blog sur la partie 3, où nous couvrirons également Patroni de Zalando et comparerons les trois solutions open source pour vous aider à déterminer les meilleures pratiques et la solution idéale pour vos applications professionnelles.