Ajout documentation Fonctionnement du délai de bascule HA

HowtoPatroni.md

@@ -192,3 +192,32 @@ Lors du premier démarrage de Patroni sur les machines du cluster, Patroni va co
 
 Sur les Replica, Patroni va lancer un `pg_basebackup` depuis le replica vers le leader pour copier l'instance PostgreSQL et la redémarré en mode recovery.
 C'est identique a ce qu'on fait lorsque on initialise une [Streaming Réplication](https://wiki.evolix.org/HowtoPostgreSQL/ReplicationPhysique#synchronisation-initiale-des-donn%C3%A9es-m%C3%A9thode-courante)
+
+## Fonctionnement du délai de bascule HA
+
+Patroni effectue de temps en temps ce que nous appelons un cycle HA. 
+À chaque cycle HA, il se charge d'effectuer une série de vérifications sur le cluster pour déterminer son état de santé et, en fonction de l'état, il peut prendre des mesures, comme le basculement vers un serveur de réplica.
+
+Ce comportement se configure dans la partie `dcs:` de la configuration :
+
+~~~
+bootstrap:
+    dcs:
+        ttl: 30
+        loop_wait: 10
+        retry_timeout: 10
+        maximum_lag_on_failover: 1048576
+~~~
+
+`loop_wait` détermine combien de temps, en secondes, Patroni effectue un nouveau cycle de vérifications HA.
+
+`retry_timeout` définit le délai d'attente pour les opérations de nouvelle tentative sur le DCS et sur Postgres. Par exemple : si le DCS ne répond pas pendant plus de `retry_timeout` secondes, Patroni peut rétrograder le nœud principal (Leader) en tant qu'action de sécurité.
+
+`ttl` définit la durée du bail sur le verrou leader dans le DCS. Si le leader actuel du cluster n'est pas en mesure de renouveler le bail pendant ses cycles HA pour une durée supérieure à ttl, alors le bail expirera et cela déclenchera une bascule du leader dans le cluster.
+
+On peut donc modifier les variables `loop_wait`, `retry_timeout` et `ttl`, pour réduire le temps de bascule d'un leader en cas de l'indisponibilité d'un nœud.
+Il faut toujours respecter la règle suivante : `loop_wait + 2*retry_timeout` doit être inférieur ou égale à la valeur de `ttl`.
+
+Il y a toujours un compromis entre un basculement rapide et la capacité à tolérer du lags au niveau réseau. Il faut donc veiller à ne pas trop mettre de valeurs basses, car il va effectivement avoir un basculement rapide, mais il peut aussi avoir un basculement au moindre lag de réseau, et donc provoquer potentiellement un splitbrain.
+
+`maximum_lag_on_failover` est la valeur en octet maximale qu'un réplica peut prendre en retard pour pouvoir participer à l'élection du leader.