Ticketing Parámetros de Raft
| Elemento | Valor |
|---|---|
| Intervalo de heartbeat | 500 ms (cluster_heartbeat_ms) |
| Tiempo para declarar falta de respuesta | 2000 ms (cluster_election_timeout_ms) — si el heartbeat falta durante ese tiempo, se da al líder por muerto |
| Ventana real de inicio de la elección | 1750-2000 ms — se sortea al azar en cada nodo para evitar candidatos simultáneos (split vote). El peor caso es exactamente el tiempo de falta de respuesta configurado |
| Parada del cliente ante el fallo del líder | medido: tiempo de falta de respuesta + 0,3-0,5 s (unos 2,3-2,5 s con los valores por defecto) — detección más una redirección |
| Número de nodos | 3 o 5 (impuesto al cargar la configuración — cualquier otro valor rechaza el arranque) |
| ID de nodo | su posición (cluster_self) en la lista cluster_peers — por eso el orden de la lista debe ser idéntico en todos los nodos |
| Bootstrap | 500 ms tras el arranque, todos los nodos se inicializan con la misma membresía — se ignora si se une a un clúster ya inicializado |
| Almacenamiento del log | en memoria (volátil) — un nodo reiniciado se recupera vía replicación/snapshot |
| Detección de expiración de lease | el líder comprueba cada 100 ms y confirma Expire mediante consenso |
Granularidad del timeout de wait | el timeout de espera (T) también se decide en el mismo tick de 100 ms — puede llegar hasta 100 ms tarde |
| Aviso de cambio de líder | cuando el líder cambia, se envía de inmediato una L a todos los clientes conectados |
Cómo elegir el heartbeat y el tiempo de falta de respuesta
Ambos valores se ajustan en la configuración mediante cluster_heartbeat_ms y cluster_election_timeout_ms. El tiempo de falta de respuesta (T) es exactamente el tiempo que el servicio queda parado cuando falla el líder; a la inversa, un valor demasiado corto hace que un líder vivo se juzgue muerto y provoca elecciones innecesarias.
| heartbeat / T | Ventana de detección | Peor retraso al matar al líder (medido) | Entorno recomendado |
|---|---|---|---|
| 100 ms / 600 ms | 450-600 ms | unos 0,9 s | mismo rack / misma AZ, latencia muy estable |
| 100 ms / 1000 ms | 750-1000 ms | unos 1,2 s | misma AZ |
| 250 ms / 2500 ms | 1875-2500 ms | unos 2,8 s | varias AZ |
| 500 ms / 2000 ms | 1750-2000 ms | unos 2,4 s | por defecto — equilibrio para varias AZ |
| 500 ms / 5000 ms | 3750-5000 ms | unos 5,3 s | entre regiones, latencia con grandes variaciones |
- La latencia en operación normal no se ve afectada por estos valores (la p50 medida no cambia) — solo determinan el tiempo de recuperación ante un fallo.
- La caída de un seguidor no afecta a los clientes con ninguno de los valores. Los retrasos anteriores solo ocurren cuando cae el líder.
- Restricciones:
cluster_election_timeout_msdebe ser de al menos 600 ms y como mínimo 4× el heartbeat. (Se ha medido que un solo retraso de planificación bajo carga puede engullir dos heartbeats enteros.)
Por qué 3 o 5 nodos
Un commit necesita una mayoría. Una configuración con un número par de nodos solo añade coste sin añadir tolerancia a fallos, así que el servidor la rechaza.
| Número de nodos | Mayoría | Fallos simultáneos tolerados |
|---|---|---|
| 2 | 2 | 0 — un solo fallo detiene el clúster. No mejor que el modo único |
| 3 | 2 | 1 |
| 4 | 3 | 1 — igual que con 3 nodos, solo que cuesta más |
| 5 | 3 | 2 |
Resumen del comportamiento ante fallos
| Situación | Comportamiento |
|---|---|
| Solicitud de cliente a un nodo que no es el líder | M (dirección del líder), o E no_leader si el líder se desconoce |
| Fallo del líder | nuevo líder elegido dentro del tiempo de falta de respuesta configurado (1750-2000 ms por defecto). Las solicitudes durante esa ventana reciben E no_leader → el cliente reintenta |
| Durante el cambio de líder | las solicitudes de adquisición pendientes se resuelven con M/E no_leader, y el cliente reintenta contra el nuevo líder |
| Reinicio de nodo | arranca con estado vacío → se pone al día vía la replicación del log/snapshot de un par |
| Pérdida de la mayoría | los commits se vuelven imposibles → las escrituras se detienen (seguridad ante todo), y se reanudan automáticamente en cuanto se restaura la mayoría |
Terminología
- Quorum — más de la mitad de todos los nodos (2 de 3, o 3 de 5). Como cualquier decisión requiere el acuerdo del quorum, dos grupos separados por una partición nunca pueden confirmar decisiones contradictorias a la vez.
- Timeout de elección — cuánto espera un seguidor sin heartbeat antes de concluir que el líder ha muerto e iniciar una elección. Se aleatoriza por nodo para reducir candidaturas simultáneas.