Assurer la fiabilité et la qualité de votre configuration Patroni haute disponibilité est essentiel pour maintenir les opérations de base de données en continu et minimiser les temps d'arrêt. Cette page fournit un guide complet sur le test de votre cluster Patroni, couvrant divers scénarios de défaillance, la cohérence de la réplication et les mécanismes de basculement.
Tester votre configuration Patroni
Connectez-vous à l'une de vos instances patroni (
alloydb-patroni1,alloydb-patroni2oualloydb-patroni3) et accédez au dossier patroni d'AlloyDB Omni.cd /alloydb/
Inspectez les journaux Patroni.
docker compose logs alloydbomni-patroni
Les dernières entrées doivent refléter des informations sur le nœud Patroni. Un résultat semblable aux lignes suivantes doit s'afficher.
alloydbomni-patroni | 2024-06-12 15:10:29,020 INFO: no action. I am (patroni1), the leader with the lock alloydbomni-patroni | 2024-06-12 15:10:39,010 INFO: no action. I am (patroni1), the leader with the lock alloydbomni-patroni | 2024-06-12 15:10:49,007 INFO: no action. I am (patroni1), the leader with the lockConnectez-vous à n'importe quelle instance exécutant Linux qui dispose d'une connectivité réseau avec votre instance Patroni principale,
alloydb-patroni1, et obtenez des informations sur l'instance. Vous devrez peut-être installer l'outiljqen exécutantsudo apt-get install jq -y.curl -s http://alloydb-patroni1:8008/patroni | jq .
Un résultat semblable à celui-ci devrait s'afficher :
{ "state": "running", "postmaster_start_time": "2024-05-16 14:12:30.031673+00:00", "role": "master", "server_version": 150005, "xlog": { "location": 83886408 }, "timeline": 1, "replication": [ { "usename": "alloydbreplica", "application_name": "patroni2", "client_addr": "10.172.0.40", "state": "streaming", "sync_state": "async", "sync_priority": 0 }, { "usename": "alloydbreplica", "application_name": "patroni3", "client_addr": "10.172.0.41", "state": "streaming", "sync_state": "async", "sync_priority": 0 } ], "dcs_last_seen": 1715870011, "database_system_identifier": "7369600155531440151", "patroni": { "version": "3.3.0", "scope": "my-patroni-cluster", "name": "patroni1" } }
L'appel du point de terminaison de l'API HTTP Patroni sur un nœud Patroni expose divers détails sur l'état et la configuration de cette instance PostgreSQL particulière gérée par Patroni, y compris des informations sur l'état du cluster, la chronologie, les informations WAL et les vérifications de l'état indiquant si les nœuds et le cluster sont opérationnels.
Tester votre configuration HAProxy
Sur une machine disposant d'un navigateur et d'une connectivité réseau à votre nœud HAProxy, accédez à l'adresse suivante:
http://haproxy:7000. Vous pouvez également utiliser l'adresse IP externe de l'instance HAProxy au lieu de son nom d'hôte.L'écran qui s'affiche doit ressembler à la capture d'écran suivante.
Figure 1 : Page d'état HAProxy affichant l'état de fonctionnement et la latence des nœuds Patroni.
Dans le tableau de bord HAProxy, vous pouvez voir l'état de fonctionnement et la latence de votre nœud Patroni principal,
patroni1, et des deux réplicas,patroni2etpatroni3.Vous pouvez effectuer des requêtes pour vérifier les statistiques de réplication dans votre cluster. À partir d'un client tel que pgAdmin, connectez-vous à votre serveur de base de données principal via HAProxy et exécutez la requête suivante.
SELECT pid, usename, application_name, client_addr, state, sync_state FROM pg_stat_replication;Vous devriez voir un résultat semblable au diagramme suivant, qui montre que
patroni2etpatroni3sont en streaming depuispatroni1.
Figure 2 : Résultat de pg_stat_replication affichant l'état de réplication des nœuds Patroni.
Tester le basculement automatique
Dans cette section, dans votre cluster à trois nœuds, nous simulons une panne sur le nœud principal en arrêtant le conteneur Patroni en cours d'exécution associé. Vous pouvez arrêter le service Patroni sur le principal pour simuler une panne ou appliquer certaines règles de pare-feu pour arrêter la communication avec ce nœud.
Dans l'instance Patroni principale, accédez au dossier Patroni AlloyDB Omni.
cd /alloydb/
Arrêtez le conteneur.
docker compose down
Le résultat obtenu devrait ressembler à ce qui suit. Cela devrait confirmer que le conteneur et le réseau ont été arrêtés.
[+] Running 2/2 ✔ Container alloydb-patroni Removed ✔ Network alloydbomni-patroni_default RemovedActualisez le tableau de bord HAProxy et observez le basculement.
Figure 3. Tableau de bord HAProxy affichant le basculement du nœud principal vers le nœud de secours.
L'instance
patroni3est devenue la nouvelle instance principale, etpatroni2est le seul réplicateur restant. L'instance principale précédente,patroni1, est en panne et les vérifications de l'état échouent.Patroni effectue et gère le basculement via une combinaison de surveillance, de consensus et d'orchestration automatisée. Dès que le nœud principal ne parvient pas à renouveler son bail dans un délai spécifié ou s'il signale une défaillance, les autres nœuds du cluster reconnaissent cette condition via le système de consensus. Les nœuds restants se coordonnent pour sélectionner le réplica le plus approprié à promouvoir en tant que nouveau nœud principal. Une fois qu'un réplica candidat est sélectionné, Patroni le promeut en instance principale en appliquant les modifications nécessaires, telles que la mise à jour de la configuration PostgreSQL et la relecture de tous les enregistrements WAL en attente. Ensuite, le nouveau nœud principal met à jour le système de consensus avec son état, et les autres réplicas se reconfigurent pour suivre le nouveau nœud principal, y compris en changeant leur source de réplication et en rattrapant potentiellement les nouvelles transactions. HAProxy détecte le nouveau principal et redirige les connexions client en conséquence, ce qui garantit une perturbation minimale.
À partir d'un client tel que pgAdmin, connectez-vous à votre serveur de base de données via HAProxy et vérifiez les statistiques de réplication de votre cluster après le basculement.
SELECT pid, usename, application_name, client_addr, state, sync_state FROM pg_stat_replication;Vous devriez voir un diagramme semblable à celui-ci, indiquant que seul
patroni2est en streaming.
Figure 4 : Sortie pg_stat_replication montrant l'état de réplication des nœuds Patroni après le basculement.
Votre cluster à trois nœuds peut encore subir une panne. Si vous arrêtez le nœud principal actuel,
patroni3, un autre basculement se produit.
Figure 5. Tableau de bord HAProxy affichant le basculement du nœud principal,
patroni3, vers le nœud de secours,patroni2.
Considérations concernant le remplacement
Le repli est le processus de rétablissement de l'ancien nœud source après un basculement. Le basculement automatique n'est généralement pas recommandé dans un cluster de base de données haute disponibilité en raison de plusieurs problèmes critiques, tels que la récupération incomplète, le risque de scénarios de cerveau divisé et le décalage de réplication.
Dans votre cluster Patroni, si vous démarrez les deux nœuds avec lesquels vous avez simulé une panne, ils rejoindront le cluster en tant que réplicas de secours.
Figure 6. Tableau de bord HAProxy affichant la restauration de patroni1 et patroni3 en tant que nœuds de secours.
patroni1 et patroni3 répliquent désormais à partir de l'instance principale actuelle patroni2.
Figure 7 : Sortie pg_stat_replication montrant l'état de réplication des nœuds Patroni après le basculement.
Si vous souhaitez revenir manuellement à votre primaire initiale, vous pouvez le faire à l'aide de l'interface de ligne de commande patronictl. En optant pour le basculement manuel, vous pouvez vous assurer d'un processus de récupération plus fiable, cohérent et vérifié, tout en préservant l'intégrité et la disponibilité de vos systèmes de base de données.