Il est essentiel de garantir la fiabilité et la qualité de votre configuration Patroni à haute disponibilité pour maintenir les opérations de base de données AlloyDB Omni en continu et minimiser les temps d'arrêt. Cette page fournit un guide complet pour tester votre cluster Patroni, couvrant différents 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.
sudo journalctl -u patroni
Les dernières entrées doivent refléter les informations sur le nœud Patroni. Un résultat semblable à celui-ci doit s'afficher.
May 16 15:10:29 alloydb-patroni1 patroni[1234]: 2024-06-12 15:10:29,020 INFO: no action. I am (patroni1), the leader with the lock May 16 15:10:39 alloydb-patroni1 patroni[1234]: 2024-06-12 15:10:39,010 INFO: no action. I am (patroni1), the leader with the lock May 16 15:10:49 alloydb-patroni1 patroni[1234]: 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 qui dispose 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 dnf install jq.curl -s http://alloydb-patroni1:8008/patroni | jq .
Un résultat semblable au suivant doit 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 l'instance PostgreSQL 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 fonctionnent correctement.
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 quelque chose de semblable à la capture d'écran suivante.
Figure 1 : Page d'état HAProxy affichant l'état d'intégrité 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 instances répliquées,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;Un diagramme semblable à celui-ci devrait s'afficher, indiquant que
patroni2etpatroni3sont diffusés en streaming depuispatroni1.
Figure 2 : Sortie pg_stat_replication affichant l'état de réplication des nœuds Patroni.
Tester le basculement automatique
Dans cette section, nous simulons une panne sur le nœud principal de votre cluster à trois nœuds en arrêtant le conteneur Patroni en cours d'exécution associé. 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 AlloyDB Omni Patroni.
cd /alloydb/
Arrêtez le conteneur.
sudo systemctl stop patroni
Un résultat semblable aux lignes suivantes doit s'afficher. Cela devrait confirmer que le conteneur et le réseau ont été arrêtés.
patroni.service - Runner for Patroni Loaded: loaded (/etc/systemd/system/patroni.service; enabled; vendor preset: disabled) Active: inactive (dead) since ...
Actualisez le tableau de bord HAProxy et observez comment le basculement se produit.
Figure 3. Tableau de bord HAProxy montrant le basculement du nœud principal vers le nœud de secours.
L'instance
patroni3est devenue la nouvelle instance principale, etpatroni2est la seule instance répliquée restante. L'ancienne instance principale,patroni1, est indisponible 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 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 l'instance répliquée la plus appropriée à promouvoir en tant que nouvelle instance principale. Une fois qu'une instance répliquée candidate est sélectionnée, Patroni promeut ce nœud en tant que nœud principal 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 instances répliquées se reconfigurent pour suivre le nouveau nœud principal, y compris en changeant de source de réplication et en rattrapant éventuellement les nouvelles transactions. HAProxy détecte le nouveau nœud principal et redirige les connexions client en conséquence, ce qui minimise les perturbations.
À 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 diagramme semblable à celui ci-dessous, indiquant que seul
patroni2est en cours de diffusion.
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 survivre à une autre panne. Si vous arrêtez le nœud principal actuel,
patroni3, un autre basculement se produit.
Figure 5. Tableau de bord HAProxy montrant le basculement du nœud principal,
patroni3, vers le nœud de secours,patroni2.
Remarques sur le remplacement
Le remplacement est le processus de rétablissement de l'ancien nœud source après un basculement. Le remplacement automatique n'est généralement pas recommandé dans un cluster de bases de données à haute disponibilité en raison de plusieurs problèmes critiques, tels qu'une récupération incomplète, le risque de scénarios de split-brain et le délai de réplication.
Dans votre cluster Patroni, si vous affichez les deux nœuds avec lesquels vous avez simulé une panne, ils rejoindront le cluster en tant qu'instances répliquées de secours.
Figure 6. Tableau de bord HAProxy montrant la restauration de patroni1 et patroni3 en tant que nœuds de secours.
patroni1 et patroni3 sont désormais répliqués à 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 remplacement.
Si vous souhaitez effectuer un basculement manuel vers votre instance principale initiale, vous pouvez le faire à l'aide de l'interface de ligne de commande patronictl. En optant pour le remplacement 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.