Il est essentiel de garantir la fiabilité et la qualité de votre configuration Patroni à haute disponibilité pour assurer la continuité des opérations de la base de données AlloyDB Omni et réduire les temps d'arrêt. Cette page fournit un guide complet pour tester votre cluster Patroni, couvrant différents scénarios d'échec, 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 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. Vous devriez voir un résultat semblable à celui-ci.
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 lock
Connectez-vous à n'importe quelle instance exécutant Linux et disposant d'une connectivité réseau à 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 .
Vous devriez voir un résultat semblable à celui-ci.
{ "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 d'é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.Vous devriez voir un résultat semblable à 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 nœuds dupliqués,patroni2etpatroni3.Vous pouvez exécuter 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 schéma suivant, indiquant que
patroni2etpatroni3sont diffusés en streaming à partir depatroni1.
Figure 2 : Sortie 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. Vous pouvez arrêter le service Patroni sur le nœud principal pour simuler une panne ou appliquer des règles de pare-feu pour arrêter la communication avec ce nœud.
Sur l'instance Patroni principale, accédez au dossier Patroni AlloyDB Omni.
cd /alloydb/
Arrêtez le conteneur.
docker compose down
Vous devriez voir un résultat semblable à celui-ci. 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 Removed
Actualisez 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 nœud dupliqué restant. L'instance principale précédente,patroni1, est hors service et les vérifications d'état échouent.Patroni effectue et gère le basculement grâce à 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 un échec, 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 nœud dupliqué le plus approprié à promouvoir en tant que nouveau nœud principal. Une fois qu'un nœud dupliqué candidat est sélectionné, Patroni le promeut en nœud principal en appliquant les modifications nécessaires, telles que la mise à jour de la configuration PostgreSQL et la relecture des enregistrements WAL en attente. Ensuite, le nouveau nœud principal met à jour le système de consensus avec son état, et les autres nœuds dupliqués 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 nœud principal et redirige les connexions client en conséquence, ce qui minimise les interruptions.
À 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 dans votre cluster après le basculement.
SELECT pid, usename, application_name, client_addr, state, sync_state FROM pg_stat_replication;Vous devriez voir un résultat semblable au schéma suivant, indiquant que seul
patroni2est désormais diffusé en streaming.
Figure 4 : Sortie pg_stat_replication affichant l'état de réplication des nœuds Patroni après le basculement.
Votre cluster à trois nœuds peut survivre à une panne supplémentaire. Si vous arrêtez le nœud principal actuel,
patroni3, un autre basculement a lieu.
Figure 5 : Tableau de bord HAProxy affichant le basculement du nœud principal,
patroni3, vers le nœud de secours,patroni2.
Considérations sur le rétablissement
Le rétablissement est le processus de rétablissement de l'ancien nœud source après un basculement. Le rétablissement 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 qu'une récupération incomplète, un risque de scénarios de split-brain et un décalage de réplication.
Dans votre cluster Patroni, si vous activez les deux nœuds avec lesquels vous avez simulé une panne, ils rejoindront le cluster en tant que nœuds dupliqués de secours.
Figure 6 : Tableau de bord HAProxy affichant la restauration de patroni1 et patroni3 en tant que nœuds de secours.
Désormais, patroni1 et patroni3 sont répliqués à partir du nœud principal actuel, patroni2.
Figure 7 : Sortie pg_stat_replication affichant l'état de réplication des nœuds Patroni après le rétablissement.
Si vous souhaitez revenir manuellement à votre nœud principal initial, vous pouvez le faire en utilisant l'interface de ligne de commande patronictl. En optant pour le rétablissement manuel, vous pouvez garantir un processus de récupération plus fiable, cohérent et minutieusement vérifié, tout en préservant l'intégrité et la disponibilité de vos systèmes de base de données.