Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
J'ai mis en place une réplication (hot standby, réplication physique, pas logique) entre deux bâtiments distincts.
* est-il possible de faire en sorte que le primaire stoppe si le standby est déconnecté?
* la solution "préconisée" pour faire un switchover est de couper le primaire puis faire un "promote" sur le standby. En coupant le primaire, ne risque-t'on pas d'arrêter la réplication en cours et donc de créer un gap entre le primaire et le standby?
* Y a-t'il un script à tourner sur le primaire , au cas où ils ne serait plus connecté, de mettre quelque part les wal non reçus par le standby (wals qui seraient envoyés manuellement)?
* quand on coupe le primaire, s'assure-t'il de transmettre jusqu'au dernier wal vers le standby avant de s'arrêter?
Le but étant de diminuer le risque de perte de données en cas de basculement contrôlé.
Merci des réponses et conseils.
Hors ligne
* est-il possible de faire en sorte que le primaire stoppe si le standby est déconnecté?
Automatiquement non. Il vous faut un script qui arrête le secondaire une fois qu'il a détecté la déconnexion du secondaire.
* la solution "préconisée" pour faire un switchover est de couper le primaire puis faire un "promote" sur le standby. En coupant le primaire, ne risque-t'on pas d'arrêter la réplication en cours et donc de créer un gap entre le primaire et le standby?
Non. Ce qui a été envoyé est rejoué. Les transactions pour lesquelles le COMMIT n'est pas arrivé ne sont pas prises en compte.
* Y a-t'il un script à tourner sur le primaire , au cas où ils ne serait plus connecté, de mettre quelque part les wal non reçus par le standby (wals qui seraient envoyés manuellement)?
C'est normalement le but du paramètre archive_command.
* quand on coupe le primaire, s'assure-t'il de transmettre jusqu'au dernier wal vers le standby avant de s'arrêter?
S'il est coupé, il ne peut rien faire. C'est donc à réaliser manuellement.
Guillaume.
Hors ligne
* est-il possible de faire en sorte que le primaire stoppe si le standby est déconnecté?
Automatiquement non. Il vous faut un script qui arrête le secondaire une fois qu'il a détecté la déconnexion du secondaire.
Par contre suivant le besoin, une répli synchrone pourrait amener le résultat souhaité… vu qu'on ne peut plus écrire sur le primaire si le standby est déconnecté
Marc.
Hors ligne
Salut,
Si le but est «de diminuer le risque de perte de données en cas de basculement contrôlé», alors la réplication asynchrone suffit largement.
Au moment où on arrête le primaire, ce dernier attend que les secondaires connectés aient bien récupéré l'ensemble des WAL avant de s'arrêter. Par contre, si la réplication est coupée pour une raison ou une autre (coupure réseau, arrêt du secondaire, ...), le primaire ne fait aucun effort pour s'assurer du statut des secondaires absents.
Donc, après avoir arrêté le primaire, il vous suffit de comparer l'adresse du dernier "shutdown checkpoint" du primaire avec ce qu'a reçu le secondaire. S'ils sont égaux, vous pouvez promouvoir le standby sans perte de données. Voir par exemple: https://public.dalibo.com/exports/forma … -promotion
Hors ligne
Bonjour, alors ça c'est très intéressant. Est-ce que quelqu'un sait si Patroni fait ce genre de comparaison au moment d'une promotion/élection ?
Cordialement,
Sébastien.
Hors ligne
Bonjour Sébastien,
Je crois bien que oui.
La fonction "demote" crée un callback "on_shutdown" faisant appel à la méthode "is_failover_possible" en positionnant le paramètre "cluster_lsn" pointant sur le shutdown checkpoint. Voir le code et le commentaire là : https://github.com/zalando/patroni/blob … a.py#L1234
On observe ensuite dans la méthode "is_failover_possible" que si le paramètre "cluster_lsn" est positionné et que la position du standby dans les WAL est inférieure, alors le standby est exclu à cause de son lag. Voir: https://github.com/zalando/patroni/blob … a.py#L1044
Ce code remonte au minimum à octobre 2021, mais je n'ai pas été cherché s'il existait ailleurs avant le commit d394b63c.
Hors ligne
Merci Guillaume,
c'est intéressant.
Par contre en lisant cette partie du code et la doc patroni, j'ai l'impression que ça dépend en 1er lieu du type de replication (synchrone ou asynchrone).
En asynchrone la doc indique que la priorité est l'aspect "availability" au détriment des données. Donc dans ce mode patroni est autorisé à sacrifier des données.
Et tout ce joue dans ce cas avec le paramètre "maximum_lag_on_failover" : si ce maximum est atteint ou dépassé, le replica ne peut plus prétendre à être promu.
Mais avant ce maximum, c'est ok et donc ce lag de transaction est perdu.
Cordialement,
Sébastien.
Hors ligne
Bonjour Sébastien,
«En asynchrone la doc indique que la priorité est l'aspect "availability" au détriment des données. Donc dans ce mode patroni est autorisé à sacrifier des données»
Parles-tu de cette page de doc : https://patroni.readthedocs.io/en/lates … durability ?
Si c'est bien cela, elle décrit simplement le mode de réplication asynchrone de PgSQL qui autorise fatalement la perte de transaction en cas de bascule d'urgence. Ce n'est pas un choix de Patroni lui même.
Aussi, je discute ici de bascule planifiée, pas une bascule sur incident. Or, une bascule planifiée passe par l'appel à la méthode "demote" où il semble que le nécessaire soit fait pour que les standby attendent d'avoir reçu le "shutdown checkpoint" avant de se lancer dans la course au leader lock.
Ceci dit, je suis évidemment intéressé si tu as un bout de code laissant croire le contraire ! Je ne suis pas dev sur Patroni, je ne maîtrise pas le python et je peux totalement mésinterpréter ou oublier un bout de code...
Hors ligne
Bonjour Guillaume,
Oui il s'agit bien de cette page.
Mais oui tu as absolument raison, les bascules volontaires/planifiées sont très différentes des bascules sur incident/urgentes.
Bien vu.
Je vais essayer de creuser encore un peu plus le sujet (qui est vraiment très intéressant et qui intéresse au plus haut point les décideurs dans les entreprises).
Sans trop d'espoir d'étudier le code car le python et moi... bof.
Cordialement,
Sébastien.
Hors ligne
Bonjour,
Après une analyse un peu plus profonde du code, j'ai commencé à avoir des doutes. Le callback "on_shutdown" permet surtout de relacher le leader lock plus rapidement pour laisser les secondaires se jeter dessus plus rapidement si certains d'entre eux ont bien reçu le "shutdown checkpoint" donc.
Sauf que si aucun standby n'a reçu ce checkpoint, ce callback n'effectue aucune attente. Aussi, il est de toute façon asynchrone et la méthode "demote()" poursuit son chemin quoiqu'il arrive, et fini par relâcher le lock sans se soucier de l'état des standby.
J'ai voulu tester ma compréhension avec un scénario très, très artificiel:
* créer une base pgbench suffisamment grosse
* ralentir si besoin la réplication avec une boucle de kill -STOP/kill -CONT sur le walreciver
* dans une séquence rapide:
- exécuter un "VACUUM FULL pgbench_accounts" sur le primaire
- commander un switchover immédiatement après le vacuum
- tuer (SIGKILL) immédiatement le walreceiver sur le secondaire pour simuler un incident
Et effectivement, avec ce scénario, l'ancien primaire ne réussi pas à raccrocher car le nouveau a créé une nouvelle timeline avant le "shutdown checkpoint".
Il est bon d'avoir conscience de cette race condition, mais elle reste malgré tout bien peu probable. De plus, il est relativement aisé de s'assurer que le switchover s'est déroulé correctement avec un simple "patronictl list" pendant quelques secondes.
Aussi, il est possible de se prémunir d'un tel incident avec une procédure un peu plus blindée:
* une interruption des écritures en production
* attendre que les instances soient toutes à flot
* déclencher le switchover
* valider le bon raccrochement de l'ancien primaire en tant que standby
- si ok: fin
- sinon: reconstruction de l'ancien primaire en tant que standby, par exemple
avec une restauration PITR optimisée
* relancer les écritures en production
Avec une telle procédure, il devient franchement improbable que l'ancien primaire ne puisse plus raccrocher suite à la bascule.
Hors ligne
Pages : 1
