PostgreSQL
 sql >> Base de données >  >> RDS >> PostgreSQL

Gestion de la haute disponibilité dans PostgreSQL – Partie 3 :Patroni

Dans nos articles de blog précédents, nous avons discuté des capacités et du fonctionnement de PostgreSQL Automatic Failover (PAF) par Cluster Labs et Replication Manager (repmgr) par 2ndQuadrant. Dans le dernier article de cette série, nous passerons en revue la dernière solution, Patroni de Zalando, et comparerons les trois à la fin afin que vous puissiez déterminer quel framework de haute disponibilité convient le mieux à votre déploiement d'hébergement PostgreSQL.

  • Gestion de la haute disponibilité dans PostgreSQL – Partie I :Basculement automatique PostgreSQL
  • Gestion de la haute disponibilité dans PostgreSQL – Partie 2 :Replication Manager

Patroni pour PostgreSQL

Patroni est à l'origine un fork de Governor, un projet de Compose. Il s'agit d'une suite d'outils open source, écrite en Python, pour gérer la haute disponibilité des clusters PostgreSQL. Au lieu de créer son propre protocole de cohérence, Patroni exploite intelligemment le modèle de cohérence fourni par un Distributed Configuration Store (DCS). Il prend également en charge d'autres solutions DCS telles que Zookeeper, etcd, Consul et Kubernetes.

Patroni assure la configuration de bout en bout des clusters PostgreSQL HA, y compris la réplication en continu. Il prend en charge différentes manières de créer un nœud de secours et fonctionne comme un modèle qui peut être personnalisé selon vos besoins.

Cet outil riche en fonctionnalités expose ses fonctionnalités via les API REST et également via un utilitaire de ligne de commande appelé patronictl. Il prend en charge l'intégration avec HAProxy en utilisant ses API de vérification de l'état pour gérer l'équilibrage de charge.

Patroni prend également en charge la notification d'événements à l'aide de rappels, qui sont des scripts déclenchés par certaines actions. Il permet aux utilisateurs d'effectuer toutes les actions de maintenance en fournissant une fonctionnalité de pause/reprise. La fonctionnalité de prise en charge de Watchdog rend le framework encore plus robuste.

Comment ça marche

Initialement, les binaires PostgreSQL et Patroni doivent être installés. Une fois cela fait, vous devrez également configurer une configuration HA DCS. Toutes les configurations nécessaires pour amorcer le cluster doivent être spécifiées dans le fichier de configuration yaml et Patroni utilisera ce fichier pour l'initialisation. Sur le premier nœud, Patroni initialise la base de données, obtient le verrou principal de DCS et s'assure que le nœud est exécuté en tant que maître.

L'étape suivante consiste à ajouter des nœuds de secours, pour lesquels Patroni propose plusieurs options. Par défaut, Patroni utilise pg_basebackup pour créer le nœud de secours et prend également en charge des méthodes personnalisées telles que WAL-E, pgBackRest, Barman et autres pour la création du nœud de secours. Patroni simplifie l'ajout d'un nœud de secours et gère toutes les tâches d'amorçage et la configuration de votre réplication en continu.

Gestion de la haute disponibilité dans #PostgreSQL – Partie 3 :Patroni contre PAF contre repmgrClick To Tweet

Une fois la configuration de votre cluster terminée, Patroni surveillera activement le cluster et s'assurera qu'il est en bon état. Le nœud maître renouvelle le verrou leader toutes les ttl seconde(s) (par défaut :30 secondes). Lorsque le nœud maître ne parvient pas à renouveler le verrou leader, Patroni déclenche une élection, et le nœud qui obtiendra le verrou leader sera élu comme nouveau maître.

Comment gère-t-il le scénario Split Brain ?

Dans un système distribué, le consensus joue un rôle important dans la détermination de la cohérence, et Patroni utilise DCS pour parvenir à un consensus. Seul le nœud qui détient le verrou leader peut être le maître et le verrou leader est obtenu via DCS. Si le nœud maître ne détient pas le verrou leader, il sera immédiatement rétrogradé par Patroni pour fonctionner en veille. De cette façon, à tout moment, il ne peut y avoir qu'un seul maître en cours d'exécution dans le système.

Y a-t-il des exigences de configuration ?

  • Patroni a besoin de Python 2.7 et supérieur.
  • Le DCS et son module python spécifique doivent être installés. À des fins de test, DCS peut être installé sur les mêmes nœuds exécutant PostgreSQL. Cependant, en production, DCS doit être installé sur des nœuds distincts.
  • Le fichier de configuration yaml doit être présent à l'aide de ces paramètres de configuration de haut niveau :

    Global/Universel
    Cela inclut la configuration telle que le nom de l'hôte (nom) qui doit être unique pour le cluster, le nom du cluster (portée) et le chemin pour stocker la configuration dans DCS (espace de noms).

    Journal
    Paramètres de journal spécifiques à Patroni, y compris le niveau, le format, file_num, file_size, etc.

    Configuration du démarrage
    Il s'agit de la configuration globale d'un cluster qui sera écrite dans DCS. Ces paramètres de configuration peuvent être modifiés à l'aide des API Patroni ou directement dans DCS. La configuration d'amorçage comprend des méthodes de création de veille, des paramètres initdb, un script de post-initialisation, etc. , mode synchrone, etc. Cette section sera écrite dans ///config d'un magasin de configuration donné après l'initialisation du nouveau cluster.

    PostgreSQL
    Cette section contient les paramètres spécifiques à PostgreSQL tels que l'authentification, les chemins de répertoire pour les données, les binaires et la configuration, l'adresse IP d'écoute, etc.

    API REST
    Cette section inclut la configuration spécifique à Patroni liée aux API REST telles que l'adresse d'écoute, l'authentification, SSL, etc.

    Consul
    Paramètres spécifiques au Consul DCS.

    Etcd
    Paramètres spécifiques à Etcd DCS.

    Exposant
    Paramètres spécifiques au DCS Exposant.

    Kubernetes
    Paramètres spécifiques au DCS Kubernetes.

    ZooKeeper
    Paramètres spécifiques à ZooKeeper DCS.

    Watchdog
    Paramètres spécifiques à Watchdog.

Les avantages de Patroni

  • Patroni permet la configuration de bout en bout du cluster.
  • Prend en charge les API REST et l'intégration HAproxy.
  • Prend en charge les notifications d'événements via des scripts de rappel déclenchés par certaines actions.
  • Exploit DCS pour parvenir à un consensus

Contre Patroni

  • Patroni ne détectera pas la mauvaise configuration d'un standby avec un nœud inconnu ou inexistant dans la configuration de récupération. Le nœud sera affiché en tant qu'esclave même si le serveur de secours est en cours d'exécution sans se connecter au nœud maître/de secours en cascade.
  • L'utilisateur doit gérer la configuration, la gestion et la mise à niveau du logiciel DCS.
  • Nécessite l'ouverture de plusieurs ports pour la communication des composants :
    • Port API REST pour Patroni
    • Minimum 2 ports pour DCS

Scénarios de test de haute disponibilité

Nous avons effectué quelques tests sur la gestion de la haute disponibilité PostgreSQL à l'aide de Patroni. Tous ces tests ont été effectué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 PostgreSQL Java JDBC en exploitant la capacité de basculement de connexion.

Tests de serveur de secours

Sl. Non Scénario de test Observation
1 Tuer le processus PostgreSQL Patroni a ramené le processus PostgreSQL à l'état d'exécution.

  • Il n'y a eu aucune interruption de l'application du rédacteur.
2 Arrêter le processus PostgreSQL Patroni a ramené le processus PostgreSQL à l'état d'exécution.

  • Il n'y a eu aucune interruption de l'application du rédacteur.
3 Redémarrer le serveur Patroni doit être démarré après le redémarrage, sauf s'il est configuré pour ne pas démarrer au redémarrage. Une fois Patroni lancé, il lance le processus PostgreSQL et configure la configuration de secours.

  • Il n'y a eu aucune interruption de l'application du rédacteur.
4 Arrêter le processus Patroni
  • Cela n'a pas arrêté le processus PostgreSQL.
  • liste patronique n'a pas affiché ce serveur.
  • Il n'y a eu aucune interruption de l'application du rédacteur.

Donc, essentiellement, vous devez surveiller la santé du processus Patroni, sinon cela entraînera des problèmes sur toute la ligne.

Tests de serveur maître/primaire

Sl. Non Scénario de test Observation
1 Tuer le processus PostgreSQL Patroni a ramené le processus PostgreSQL à l'état d'exécution. Patroni s'exécutant sur ce nœud avait un verrou principal et l'élection n'a donc pas été déclenchée.

  • Il y a eu un temps d'arrêt dans l'application du rédacteur.
2 Arrêtez le processus PostgreSQL et ramenez-le immédiatement après l'expiration de la vérification de l'état Patroni a ramené le processus PostgreSQL à l'état d'exécution. Patroni s'exécutant sur ce nœud avait un verrou principal et l'élection n'a donc pas été déclenchée.

  • Il y a eu un temps d'arrêt dans l'application du rédacteur.
3 Redémarrer le serveur Le basculement s'est produit et l'un des serveurs de secours a été élu comme nouveau maître après avoir obtenu le verrou. Lorsque Patroni a été démarré sur l'ancien maître, il a ramené l'ancien maître et exécuté pg_rewind et a commencé à suivre le nouveau maître.T

  • Il y a eu un temps d'arrêt dans l'application du rédacteur.
4 Arrêter/Tuer le processus Patroni
  • L'un des serveurs de secours a acquis le verrou DCS et est devenu le maître en se faisant connaître.
  • L'ancien maître fonctionnait toujours et cela a conduit à un scénario multi-maîtres. L'application écrivait toujours sur l'ancien maître.
  • Une fois que Patroni a démarré sur l'ancien master, il a rembobiné l'ancien master (use_pg_rewind a été défini sur true) à la nouvelle chronologie principale et au lsn et a commencé à suivre le nouveau maître.

Comme vous pouvez le voir ci-dessus, il est très important de surveiller la santé du processus Patroni sur le maître. Le non-respect de cette consigne peut entraîner un scénario multimaître et une perte de données potentielle.

Tests d'isolation réseau

Sl. Non Scénario de test Observation
1 Réseau-isoler le serveur maître des autres serveurs La communication DCS a été bloquée pour le nœud maître.

  • PostgreSQL a été rétrogradé sur le serveur maître.
  • Un nouveau maître a été élu dans la partition majoritaire.
  • Il y a eu un temps d'arrêt dans l'application du rédacteur.
2 Réseau-isoler le serveur de secours des autres serveurs La communication DCS a été bloquée pour le nœud de secours.

  • Le service PostgreSQL était en cours d'exécution, cependant, le nœud n'a pas été pris en compte pour les élections.
  • Il n'y a eu aucune interruption dans l'application du rédacteur.

Quel est le meilleur framework HA PostgreSQL ?

Patroni est un outil précieux pour les administrateurs de bases de données PostgreSQL (DBA), car il effectue la configuration et la surveillance de bout en bout d'un cluster PostgreSQL. La flexibilité de choisir DCS et la création de secours est un avantage pour l'utilisateur final, car il peut choisir la méthode avec laquelle il est à l'aise.

Les API REST, l'intégration HaProxy, la prise en charge de Watchdog, les rappels et sa gestion riche en fonctionnalités font de Patroni la meilleure solution pour la gestion PostgreSQL HA.

Test du framework PostgreSQL HA :PAF contre repmgr contre Patroni

Vous trouverez ci-dessous un tableau complet détaillant les résultats de tous les tests que nous avons effectués sur les trois frameworks :PostgreSQL Automatic Failover (PAF), Replication Manager (repmgr) et Patroni.

Tests de serveur de secours

Scénario de test Basculement automatique PostgreSQL (PAF) Gestionnaire de réplication (repmgr) Patroni
Tuer le processus PostgreSQL Pacemaker a ramené le processus PostgreSQL à l'état d'exécution.

  • Il n'y a eu aucune interruption de l'application du rédacteur.
 Le serveur de secours a été marqué comme défaillant. Une intervention manuelle a été nécessaire pour redémarrer le processus PostgreSQL.

  • Il n'y a eu aucune interruption de l'application du rédacteur.
 Patroni a ramené le processus PostgreSQL à l'état d'exécution.

  • Il n'y a eu aucune interruption de l'application du rédacteur.
Arrêter le processus PostgreSQL Pacemaker a ramené le processus PostgreSQL à l'état d'exécution.

  • Il n'y a eu aucune interruption de l'application du rédacteur.
 Le serveur de secours a été marqué comme défaillant. Une intervention manuelle a été nécessaire pour redémarrer le processus PostgreSQL.

  • Il n'y a eu aucune interruption de l'application du rédacteur.
 Patroni a ramené le processus PostgreSQL à l'état d'exécution.

  • Il n'y a eu aucune interruption de l'application du rédacteur.
Redémarrer le serveur Le serveur de secours était initialement marqué hors ligne. Une fois le serveur démarré après le redémarrage, PostgreSQL a été démarré par Pacemaker et le serveur a été marqué comme en ligne. Si la clôture était activée, le nœud n'aurait pas été ajouté automatiquement au cluster.

  • Il n'y a eu aucune interruption de l'application du rédacteur.
 Le serveur de secours a été marqué comme défaillant. Une fois le serveur démarré après le redémarrage, PostgreSQL a été démarré manuellement et le serveur a été marqué comme étant en cours d'exécution.

  • Il n'y a eu aucune interruption de l'application du rédacteur.
 Patroni doit être démarré après le redémarrage, sauf s'il est configuré pour ne pas démarrer au redémarrage. Une fois Patroni lancé, il lance le processus PostgreSQL et configure la configuration de secours.

  • Il n'y a eu aucune interruption de l'application du rédacteur.
Arrêter le processus de l'agent de structure Agent :stimulateur cardiaque

  • Le processus PostgreSQL a été arrêté et marqué hors ligne.
  • Il n'y a eu aucune interruption de l'application du rédacteur.
 Agent :repmgrd

  • Le serveur de secours ne fera pas partie de la situation de basculement automatique.
  • Le service PostgreSQL est en cours d'exécution.
  • There was no disruption of the writer application.
 Agent:patroni

  • It did not stop the PostgreSQL process.
  • patronictl list did not display this server.
  • There was no disruption of the writer application.

Master/Primary Server Tests

Test Scenario PostgreSQL Automatic Failover (PAF) Replication Manager (repmgr) Patroni
Kill the PostgreSQL process Pacemaker brought the PostgreSQL process back to running state. Primary got recovered within the threshold time and hence election was not triggered.

  • There was downtime in the writer application.
 repmgrd started health check for primary server connection on all standby servers for a fixed interval. When all retries failed, an election was triggered on all the standby servers. As a result of the election, the standby which had the latest received LSN got promoted. The standby servers which lost the election will wait for the notification from the new master node and will follow it once they receive the notification.Manual intervention was required to start the postgreSQL process again.

  • There was downtime in the writer application.
 Patroni brought the PostgreSQL process back to running state. Patroni running on that node had primary lock and hence election was not triggered.

  • There was downtime in the writer application.
Stop the PostgreSQL process and bring it back immediately after health check expiry Pacemaker brought the PostgreSQL process back to running state. Primary got recovered within the threshold time and hence election was not triggered.

  • There was downtime in the writer application.
 repmgrd started health check for primary server connections on all standby servers for a fixed interval. When all the retries failed, an election was triggered on all the standby nodes. However, the newly elected master didn’t notify the existing standby servers since the old master was back.Cluster was left in an indeterminate state and manual intervention was required.

  • There was downtime in the writer application.
 Patroni brought the PostgreSQL process back to running state. Patroni running on that node had primary lock and hence election was not triggered.

  • There was downtime in the writer application.
Reboot the server Election was triggered by Pacemaker after the threshold time for which master was not available. The most eligible standby server was promoted as the new master. Once the old master came up after reboot, it was added back to the cluster as a standby. If fencing was enabled, then node wouldn’t have been added automatically to cluster.

  • There was downtime in the writer application.
 repmgrd started election when master connection health check failed on all standby servers. The eligible standby was promoted. When this server came back, it didn’t join the cluster and was marked failed. repmgr node rejoin command was run to add the server back to the cluster.

  • There was downtime in the writer application.
 Failover happened and one of the standby servers was elected as the new master after obtaining the lock. When Patroni was started on the old master, it brought back the old master up and performed pg_rewind and started following the new master.

  • There was downtime in the writer application.
Stop the framework agent process Agent:pacemaker

  • The PostgreSQL process was stopped and it was marked offline.
  • Election was triggered and new master was elected.
  • There was downtime in writer application.
 Agent:repmgrd

  • The primary server will not be part of the automated failover situation.
  • PostgreSQL service was found to be running.
  • There was no disruption in writer application.
 Agent:patroni

  • One of the standby servers acquired the DCS lock and became the master by promoting itself.
  • The old master was still running and it led to multi-master scenario. The application was still writing to the old master.
  • Once Patroni was started on the old master, it rewound the old master (use_pg_rewind was set to true) to the new master timeline and lsn and started following the new master.

Network Isolation Tests

Test Scenario PostgreSQL Automatic Failover (PAF) Replication Manager (repmgr) Patroni
Network isolate the master server from other servers (split brain scenario) Corosync traffic was blocked on the master server.

  • PostgreSQL service was turned off and master server was marked offline due to quorum policy.
  • A new master was elected in the majority partition.
  • There was a downtime in the writer application.
 All servers have the same value for location in repmgr configuration:

  • repmgrd started election when master connection health check failed on all standby servers.
  • The eligible standby was promoted, but the PostgreSQL process was still running on the old master node.
  • There were two nodes running as master. Manual intervention was required after the network isolation was corrected.

The standby servers have the same value for location but the primary had a different value for location in repmgr configuration:

  • repmgrd started election when master connection health check failed on all standby servers.
  • But, there was no new master elected since the standby servers had location different from that of the primary.
  • repmgrd went into degrade monitoring mode. PostgreSQL was running on all the nodes and there was only one master in the cluster.
 DCS communication was blocked for master node.

  • PostgreSQL was demoted on the master server.
  • A new master was elected in the majority partition.
  • There was a downtime in the writer application.
Network-isolate the standby server from other servers Corosync traffic was blocked on the standby server.

  • The server was marked offline and PostgreSQL service was turned off due to quorum policy.
  • There was no disruption in the writer application.
  • repmgrd went into degrade monitoring mode.
  • The PostgreSQL process was still running on the standby node.
  • Manual intervention was required after the network isolation was corrected.
 DCS communication was blocked for the standby node.

  • The PostgreSQL service was running, however, the node was not considered for elections.
  • There was no disruption in the writer application.