Procedimiento de reinicio progresivo ​

Hay un principio central: siempre debe seguir viva una mayoría. Con 3 nodos, solo puedes bajar 1 a la vez; con 5 nodos, hasta 2.

1. Reinicia primero los seguidores (nodos que no son el líder), uno a uno — el líder sigue sirviendo durante todo el proceso. Confirma que cada nodo reiniciado se ha puesto al día vía la replicación del log de un par o el snapshot antes de pasar al siguiente.
2. Por último, baja el líder. Los nodos restantes detectan la pérdida del heartbeat y eligen un nuevo líder en 0,5-1 segundo. Las solicitudes de los clientes durante esa ventana reciben E no_leader, pero los clientes oficiales reintentan de forma transparente, así que la aplicación solo percibe un breve retraso.
3. Vuelve a levantar al antiguo líder — se une como seguidor y se pone al día (no recupera el liderazgo automáticamente).

El estado del bloqueo se conserva durante todo el proceso mientras siga viva una mayoría — los bloqueos concedidos o liberados durante el reinicio también pasan por el commit, así que no se pierde nada.

Flujo (con 3 nodos) ​

Durante el breve intervalo en que el líder está caído, los clientes pueden recibir E no_leader, pero los clientes oficiales reintentan de forma transparente, así que solo se percibe como un breve retraso en la aplicación.