Operación diaria y escenarios de fallo de Redis / Valkey (Cluster y Sentinel)

No es una instalación: runbook por escenarios para gestionar a diario un Redis Cluster ya instalado o una topología master/replica con Sentinel, y para recuperarlos cuando fallan (Redis 7.2, Redis 8 y Valkey). Cluster: comprobación de estado, añadir/quitar nodos, rebalance/reshard, failover manual (diferencia entre FORCE y TAKEOVER), sustitución de un nodo averiado y --cluster fix. Sentinel: estado y quórum, SENTINEL FAILOVER, añadir/quitar nodos y SENTINEL RESET, cambio de parámetros. En ambos: diagnóstico de presión de memoria y de claves grandes/calientes. Si no sabe qué hacer, empiece por la comprobación de estado; la restauración desde backup y el endurecimiento de seguridad están en guías de Redis aparte.

Topología: Redis Cluster (3+ master + replicas) o Sentinel (1 master + replicas + 3 Sentinel)

Escenarios

• Comprobación de estado del cluster (--cluster check, CLUSTER INFO / NODES) — Solo lectura: si todos los slots están cubiertos, si los nodos coinciden en la configuración, si hay algún nodo caído (fail) o algún master sin replica. Empiece por aquí si no sabe qué hacer.
• Añadir un nodo al cluster (master o replica) — Hay una nueva instancia preparada (cluster-enabled yes, vacía): se une al cluster como master y recibe slots, o pasa a ser replica de un master. Sin interrupción.
• Quitar un nodo del cluster (vaciar sus slots + del-node) — Se retira un master o una replica: los slots del master se mueven a los demás master y después el nodo se quita del cluster. Sin interrupción; durante la migración se producen redirecciones ASK.
• Redistribuir los slots (rebalance / reshard) — Los slots o la memoria están desequilibrados entre los master, un master nuevo no ha recibido slots o hay que mover un número determinado de slots de un master a otro.
• Failover manual: convertir una replica en master (CLUSTER FAILOVER, FORCE, TAKEOVER) — Hay que hacer mantenimiento en el servidor del master (planificado, sin pérdida de datos), o el master no es accesible y no se produjo el failover automático (FORCE / TAKEOVER; riesgo de pérdida de datos).
• Sustituir un master / nodo averiado (FORGET, nueva replica, --cluster fix) — El servidor de un nodo se ha perdido de forma permanente: si su replica pasó a master, se hace olvidar el nodo antiguo y se añade una nueva replica en su lugar; si no tenía replica, sus slots quedan sin propietario y se cierran con --cluster fix (los datos de esos slots se pierden).
• Estado de Sentinel: master, replicas, Sentinel, quórum — Solo lectura: la dirección del master que ven los Sentinel, las replicas, los demás Sentinel, CKQUORUM y los últimos eventos de failover. Empiece por aquí si no sabe qué hacer en una topología con Sentinel.
• Failover manual con Sentinel (SENTINEL FAILOVER) — Hay que hacer mantenimiento en el servidor del master: Sentinel convierte en master la replica más adecuada y redirige las demás replicas y los clientes al nuevo master. Interrupción de 1–2 s; sin pérdida de datos si el master está en marcha.
• Añadir / quitar / sustituir un nodo en una topología Sentinel (SENTINEL RESET) — Se ha retirado de forma permanente o se ha añadido una replica o un Sentinel: la nueva replica se conecta con REPLICAOF y los registros obsoletos de los Sentinel se limpian con SENTINEL RESET.
• Cambiar el quórum y los parámetros de Sentinel (SENTINEL SET) — Ha cambiado el número de Sentinel, o el failover se dispara demasiado tarde/demasiado pronto: se cambian quorum, down-after-milliseconds, failover-timeout y parallel-syncs en todos los Sentinel.
• Presión de memoria: diagnóstico de uso, fragmentación y eviction — used_memory se acerca a maxmemory, errores 'OOM command not allowed', la eviction aumenta, el RSS es mayor de lo esperado o los búferes de replica/AOF han crecido. El diagnóstico es de solo lectura; las soluciones se describen aparte.
• Encontrar claves grandes y calientes (--bigkeys, --memkeys, --hotkeys) — La memoria o la CPU de un nodo es más alta que la de los demás, hay picos de latencia, DEL tarda mucho: se localizan las claves más grandes y más accedidas y se eliminan de forma segura (UNLINK).

Antes de empezar

• … está instalado en el servidor de administración (viene con …, /usr/bin/…) y tiene acceso a …la instancia ……todos los nodos del cluster tanto por el puerto de cliente como por el puerto del cluster bus (puerto + 10000)…los Sentinel (…) y Redis (…)….
• Dispone de la contraseña de … (requirepass / masterauth); se pide en los pasos o se toma de la variable de entorno REDIS_PASS. Si usa ACL, el usuario necesita +@admin (comandos de cluster/sentinel) y +@keyspace.
• Se ha abierto un registro de cambio y se ha informado al equipo de aplicación. El failover y la migración de slots pueden provocar en los clientes breves redirecciones MOVED/ASK o cortes de conexión; los clientes compatibles con cluster (cluster-aware) los siguen por sí mismos.
• La nueva instancia … está preparada como en la guía de instalación de Redis Cluster: misma versión de …, cluster-enabled yes, mismos requirepass/masterauth, directorio de datos vacío (sin nodes-.conf, RDB/AOF antiguos), puerto de cliente y de bus (puerto + 10000) abiertos en el firewall.

Fases de la guía

• Estado: cobertura de slots, nodos y coherencia de la configuración (solo lectura) — Comprobar el cluster (--cluster check) · Mostrar los nodos, los roles y la distribución de replicas · Interpretar el resultado
• 1. Diagnóstico: ¿el nuevo nodo está vacío y es accesible? — Comprobar el nuevo nodo y el cluster
• 2. Aplicación: añadir el nodo — Añadir el nodo al cluster (--cluster add-node) · Repartir slots al nuevo master (rebalance) · Planificar una replica para el nuevo master
• 3. Verificación — Verificar el cluster y el nuevo nodo
• 1. Diagnóstico: ¿el nodo es master? ¿tiene slots? — Ver el rol y los slots del nodo a quitar
• 2. Aplicación: vaciar los slots y quitar el nodo — Mover los slots del master a los demás master · Quitar el nodo del cluster (--cluster del-node) · Deshabilitar el servicio en el servidor retirado
• 3. Verificación — Verificar el cluster
• 1. Diagnóstico: distribución actual — Slots, claves y memoria por master
• 2. Aplicación — …Equilibrar los slots (rebalance)…Mover … slots (reshard)…
• 1. Diagnóstico — Ver el rol de la replica y su enlace con el master
• 2. Aplicación — Iniciar el failover (CLUSTER FAILOVER… FORCE… TAKEOVER…)
• 3. Verificación — Verificar la nueva disposición
• 1. Diagnóstico: nodo perdido y cobertura de slots — Ver los nodos en estado fail y los slots sin propietario
• 2. Aplicación: hacer olvidar el nodo perdido — Hacer que todos los nodos olviden el nodo perdido (CLUSTER FORGET) · Cerrar los slots sin propietario (--cluster fix) · Añadir el nuevo nodo como replica
• 3. Verificación y seguimiento — Verificar el cluster
• Estado: master, replicas, Sentinel (solo lectura) — El master y el quórum según Sentinel · Listar las replicas y los demás Sentinel · Buscar los últimos eventos de failover en el log de Sentinel
• 1. Diagnóstico — Verificar que el quórum y las replicas están preparados
• 2. Aplicación — Iniciar el failover (SENTINEL FAILOVER)
• 3. Verificación — Verificar el nuevo master y las replicas
• 1. Diagnóstico — Número de replicas y de Sentinel que conocen los Sentinel
• 2. Aplicación — Conectar la nueva replica al master · Detener el servicio de la replica retirada · Arrancar el nuevo Sentinel · Detener el Sentinel retirado · SENTINEL RESET en todos los Sentinel
• 3. Verificación — Volver a comprobar los números y el quórum
• 1. Diagnóstico — Ver los parámetros actuales en cada Sentinel
• 2. Aplicación — Asignar … a … en todos los Sentinel
• 1. Diagnóstico: memoria, límite y eviction — Ver el uso de memoria y el límite (INFO memory) · MEMORY DOCTOR y MEMORY STATS · Ver los parámetros de memoria
• 2. Soluciones — Solución según la situación
• 1. Diagnóstico: claves grandes y calientes — Claves más grandes por tipo (--bigkeys) · Claves más grandes por memoria (--memkeys) · Claves calientes (--hotkeys) · Examinar el tamaño y el tipo de una clave
• 2. Solución — Borrar la clave grande de forma segura (UNLINK)