Ticketing Paramètres Raft
| Élément | Valeur |
|---|---|
| Intervalle de battement de cœur | 500 ms (cluster_heartbeat_ms) |
| Délai de constat d'absence de réponse | 2000 ms (cluster_election_timeout_ms) — si le battement de cœur manque pendant ce délai, le leader est considéré comme mort |
| Fenêtre réelle de démarrage de l'élection | 1750-2000 ms — tirée au hasard sur chaque nœud pour éviter des candidatures simultanées (split vote). Le pire cas correspond exactement au délai de constat configuré |
| Arrêt côté client lors d'une panne du leader | mesuré : délai de constat + 0,3-0,5 s (environ 2,3-2,5 s avec les valeurs par défaut) — détection plus une redirection |
| Nombre de nœuds | 3 ou 5 (imposé au chargement de la configuration — tout autre nombre refuse de démarrer) |
| ID de nœud | sa position (cluster_self) dans la liste cluster_peers — c'est pourquoi l'ordre de la liste doit être identique sur chaque nœud |
| Bootstrap | 500 ms après le démarrage, chaque nœud s'initialise avec le même membership — ignoré si le nœud rejoint un cluster déjà initialisé |
| Stockage du journal | en mémoire (volatile) — un nœud redémarré récupère via la réplication ou un snapshot |
| Détection d'expiration de lease | le leader vérifie toutes les 100 ms et valide Expire via consensus |
Granularité du timeout wait | le timeout d'attente (T) est aussi décidé sur ce même cycle de 100 ms — il peut arriver avec jusqu'à 100 ms de retard |
| Avis de changement de leader | quand le leader change, un L est envoyé immédiatement à tous les clients connectés |
Choisir le battement de cœur et le délai de constat
Les deux valeurs se règlent dans la configuration via cluster_heartbeat_ms et cluster_election_timeout_ms. Le délai de constat (T) correspond exactement au temps pendant lequel le service est à l'arrêt quand le leader tombe ; à l'inverse, une valeur trop courte fait juger mort un leader bien vivant et provoque des élections inutiles.
| battement / T | Fenêtre de détection | Pire latence à la mort du leader (mesurée) | Environnement recommandé |
|---|---|---|---|
| 100 ms / 600 ms | 450-600 ms | environ 0,9 s | même baie / même AZ, latence très stable |
| 100 ms / 1000 ms | 750-1000 ms | environ 1,2 s | même AZ |
| 250 ms / 2500 ms | 1875-2500 ms | environ 2,8 s | plusieurs AZ |
| 500 ms / 2000 ms | 1750-2000 ms | environ 2,4 s | par défaut — équilibre pour plusieurs AZ |
| 500 ms / 5000 ms | 3750-5000 ms | environ 5,3 s | inter-régions, latence très fluctuante |
- La latence en fonctionnement normal n'est pas affectée par ces valeurs (la p50 mesurée ne change pas) — elles ne déterminent que le temps de rétablissement en cas de panne.
- La chute d'un suiveur n'a d'impact sur les clients avec aucune de ces valeurs. Les latences ci-dessus ne surviennent que lorsque le leader tombe.
- Contraintes :
cluster_election_timeout_msdoit valoir au moins 600 ms et au moins 4× le battement de cœur. (Il a été mesuré qu'un seul retard d'ordonnancement sous charge peut avaler deux battements entiers.)
Pourquoi 3 ou 5 nœuds
Un commit nécessite une majorité. Une configuration à nombre pair n'ajoute que du coût sans améliorer la tolérance aux pannes, le serveur la refuse donc.
| Nombre de nœuds | Majorité | Pannes simultanées tolérées |
|---|---|---|
| 2 | 2 | 0 — une seule panne arrête le cluster. Pas mieux que le mode simple |
| 3 | 2 | 1 |
| 4 | 3 | 1 — identique à 3 nœuds, juste plus coûteux |
| 5 | 3 | 2 |
Résumé du comportement en cas de panne
| Situation | Comportement |
|---|---|
| Requête client vers un nœud non-leader | M (adresse du leader), ou E no_leader si le leader est inconnu |
| Panne du leader | nouveau leader élu dans le délai de constat configuré (1750-2000 ms par défaut). Les requêtes pendant cette fenêtre reçoivent E no_leader → le client réessaie |
| Pendant le changement de leader | les requêtes d'acquisition en attente sont purgées avec M/E no_leader, et le client réessaie auprès du nouveau leader |
| Redémarrage d'un nœud | démarre avec un état vide → rattrape via la réplication du journal ou le snapshot d'un pair |
| Perte de la majorité | les commits deviennent impossibles → les écritures s'arrêtent (sécurité avant tout), reprise automatique une fois la majorité restaurée |
Terminologie
- Quorum — plus de la moitié de tous les nœuds (2 sur 3, ou 3 sur 5). Comme toute décision nécessite l'accord du quorum, deux groupes partitionnés ne peuvent jamais valider des décisions contradictoires en même temps.
- Timeout d'élection (election timeout) — le temps qu'un suiveur attend sans battement de cœur avant de conclure que le leader est mort et de démarrer une élection. Randomisé par nœud pour réduire les candidatures simultanées.