Persistencia de Redis en Docker sin convertirlo en una app lenta de disco

Hechos e historia breve que realmente importan

Los debates sobre persistencia en Redis pueden volverse religiosos. Mantengámoslo concreto: aquí hay algunos puntos de contexto que explican los controles actuales y sus aristas.

1. Redis nació como un servidor en memoria con disco como red de seguridad opcional. La persistencia está añadida, no es fundamental—por eso debes alinearla con tu carga de trabajo.
2. Las instantáneas RDB aparecieron primero y son intencionadamente “tochonas”. Cambian escrituras pequeñas frecuentes por escrituras pesadas ocasionales y un coste por fork con copy-on-write.
3. AOF (Append Only File) se añadió para reducir la ventana de pérdida de datos. Registra comandos de escritura; la reproducción reconstruye el dataset al reiniciar. Excelente para durabilidad; fácil de usar mal.
4. appendfsync everysec existe porque “always” es caro. Busca una ventana de durabilidad de un segundo mientras suaviza la amplificación de escritura.
5. Redis reescribe el AOF para evitar que crezca hasta el infinito. Esa reescritura es una típica “tarea en segundo plano que aún muerde” porque compite por E/S y memoria.
6. Fork + copy-on-write significa que la persistencia puede aumentar el uso de memoria. Durante snapshot o rewrite, las páginas modificadas se duplican. En contenedores, así es como te encuentras con el OOM killer.
7. Las capas copy-on-write de Docker no son mágicas. Coloca archivos de persistencia pesados en overlay2 y vas a medir “gimnasia de metadatos del sistema de archivos”, no Redis.
8. El comportamiento de fsync es un contrato entre kernel y almacenamiento, no una promesa de Redis. Si tu almacenamiento miente sobre los flushes o tu hipervisor engaña, tus escrituras “durables” se convierten en teatro.
9. La persistencia de Redis no es una estrategia de backups. Es un mecanismo de recuperación ante fallos. Las copias de seguridad requieren retención separada, copias fuera del host y pruebas de restauración.

Una cita para mantenerte honesto: idea parafraseada — Charity Majors: “Todo falla; la diferencia es si puedes entenderlo y recuperarte rápido.”

Modelo de persistencia: qué escribe realmente Redis y cuándo duele

Instantáneas RDB: escrituras grandes, sombras largas

La persistencia RDB escribe una instantánea puntual en disco. Es eficiente cuando aceptas una ventana de pérdida y quieres archivos compactos y reinicios rápidos.
El coste aparece en dos sitios: CPU/memoria durante el fork y E/S de disco durante la escritura de la instantánea.

El fork en sí suele ser barato, hasta que tu dataset es grande y la memoria está fragmentada. Entonces los stalls por fork pueden aparecer como picos de latencia.
El coste sigiloso real es el copy-on-write: mientras Redis escribe la instantánea en un proceso hijo, el padre sigue atendiendo peticiones. Cada página modificada se duplica.
Eso genera presión adicional de memoria y trabajo extra.

En Docker, la presión de memoria es menos indulgente. Al contenedor no le importa que “solo tengas 60% usado”—le importa que ahora superaste el límite.
Con RDB activado, tu memoria pico no es el tamaño steady-state del dataset. Planifícalo.

AOF: muchas escrituras, más semanas de “dieta” periódicas

AOF registra operaciones. Eso significa appends frecuentes, más fsync según la configuración.
Si configuras appendfsync always, Redis llamará a fsync en cada escritura. Es la máxima durabilidad y la máxima oportunidad de odiar tu subsistema de almacenamiento.

La postura productiva por defecto es appendfsync everysec. Redis añade al page cache del SO y pide al kernel que haga flush una vez por segundo.
Si el kernel no puede mantenerse al día, Redis aún puede quedar bloqueado porque el buffer se llena, o porque el backend de almacenamiento convierte fsync en un evento bloqueante con latencias altas.

Luego está la reescritura del AOF. Con el tiempo, el AOF incluye comandos redundantes. Redis lo reescribe a una forma compacta.
Las reescrituras son background, pero no “gratis”. Alocan, escanean, escriben archivos secuenciales grandes y pueden colisionar con la ruta de escritura de tu aplicación.

Los mandos de durabilidad que deciden tu presupuesto de latencia

• appendfsync always: ventana de pérdida mínima, máxima sensibilidad a la latencia. Úsalo solo si realmente lo necesitas y tu almacenamiento está probado.
• appendfsync everysec: intercambio típico en producción. Ventana de pérdida de un segundo; puede aún picos bajo contención de E/S.
• appendfsync no: el kernel decide cuándo hacer flush. Es “rápido hasta que reinicias”, y a veces “tampoco es rápido”.

Primer chiste (corto y pertinente): Si activas appendfsync always en un almacenamiento de red barato, has inventado una nueva base de datos: Redis Pero Más Lento.

Qué cambia Docker (y qué no)

Redis en un contenedor sigue siendo Redis. Mismo código de persistencia, mismo modelo de fork, mismas llamadas fsync.
Lo que cambia es la ruta al disco: sistemas de archivos overlay, plugins de volúmenes, límites de cgroup y el hábito de tratar contenedores como mascotas desechables mientras esperas que recuerden cosas.

Almacenamiento en Docker: overlay2, bind mounts, volúmenes nombrados y por qué te debes importar

No pongas la persistencia de Redis en la capa escribible del contenedor

La capa escribible del contenedor (overlay2 en la mayoría de instalaciones Linux) está bien para logs y estado pequeño. El AOF de Redis no es “estado pequeño”.
Overlay2 añade semántica copy-on-write y operaciones de metadatos adicionales. Bajo patrones de escritura intensiva, puede añadir latencia y amplificar escrituras.

Si solo recuerdas una regla: los archivos de persistencia de Redis deben vivir en un montaje real—un volumen nombrado o un bind mount respaldado por un sistema de archivos que entiendas.

Bind mount vs volumen nombrado

Un bind mount apunta a una ruta del host. Es transparente y fácil de inspeccionar. También hereda las opciones de montaje del host, lo que es poder y riesgo a la vez.
Un volumen nombrado lo gestiona Docker bajo /var/lib/docker/volumes. Es más limpio operativamente y tiende a evitar incidentes de “ups, permisos equivocados”.

En cuanto a rendimiento, ambos pueden ser excelentes. El factor decisivo suele ser gobernanza: quién gestiona la ruta, las copias y las opciones de montaje.

Sistema de archivos y opciones de montaje: no eliges una religión, eliges modos de fallo

Para la persistencia de Redis, normalmente quieres:

• fsync rápido y consistente: SSD/NVMe local supera al almacenamiento en red en la latencia de cola.
• rendimiento de escritura estable: la reescritura AOF es escritora secuencial; RDB también es un gran escritor secuencial.
• latencia predecible bajo presión: no “buena de media, trágica en p99.9”.

Ext4 con valores sensatos es aburrido y bueno. XFS también es sólido. Si usas ZFS, puedes obtener resultados excelentes, pero solo si sabes cómo se manejan las escrituras sync.
Si no lo sabes, lo aprenderás a las 3 a.m.

Almacenamiento que miente sobre los flushes

Algunas capas reconocen flushes temprano. Algunos controladores RAID usan cache sin batería. Algunos volúmenes en la nube tienen un modelo de flush que es “eventualmente consistente en espíritu.”
Redis llamará a fsync. Si la pila hace trampa, tu AOF puede estar “escrito con éxito” y aún así desaparecer tras un corte de energía.

Por eso los requisitos de durabilidad deben incluir la plataforma de almacenamiento, no solo la configuración de Redis.

Qué ejecutar en producción: recetas de persistencia con opinión

Receta A: “Necesito caché rápido y supervivencia al reinicio” (común)

Usa instantáneas RDB, acepta una ventana de pérdida (minutos) y mantén Redis rápido.
Si tu fuente de verdad está en otro lado (base de datos, log de eventos), Redis es una caché con beneficios.

• Activa RDB con puntos de guardado razonables.
• Desactiva AOF.
• Pon dump.rdb en un volumen del host.
• Monitoriza la duración de las instantáneas y el tiempo de fork.

Receta B: “Puedo perder 1 segundo, no 10 minutos” (la mayoría de usos stateful)

Usa AOF con appendfsync everysec.
Mantén el comportamiento de reescritura predecible. Mantén la ruta de disco limpia. No ejecutes esto sobre overlay2 y luego abras un ticket titulado “Redis es lento”.

• Activa AOF.
• appendfsync everysec.
• Mantén RDB deshabilitado o como instantánea de seguridad periódica adicional (depende de la estrategia de restauración).
• Asegúrate de tener margen de memoria para la reescritura.

Receta C: “Realmente quiero durabilidad” (raro y caro)

Si requieres “ninguna escritura reconocida se pierde”, Redis por sí solo no es toda la respuesta. Aun así, si insistes:

• Considera AOF always solo si tu almacenamiento está probado para escrituras sync.
• Usa replicación y configura WAIT en el cliente para confirmaciones de replicación síncronas.
• Prueba escenarios de fallo, no solo benchmarks.

Segundo chiste (corto y pertinente): “Always fsync” es como llevar casco en la oficina—más seguro, pero igual te tropiezas con la alfombra.

Configuraciones que me gustan (y por qué)

Para muchas cargas en producción:

• appendonly yes
• appendfsync everysec
• no-appendfsync-on-rewrite yes para reducir stalls inducidos por reescrituras (aceptando una ventana de pérdida ligeramente mayor durante la reescritura)
• auto-aof-rewrite-percentage y auto-aof-rewrite-min-size configurados para que las reescrituras ocurran antes de que el archivo sea absurdo

La controvertida es no-appendfsync-on-rewrite. Si no toleras riesgo adicional de pérdida durante la reescritura, no la actives.
Si puedes tolerarlo, a menudo te compra estabilidad de latencia.

Consejos específicos para contenedores que evitan un Redis dependiente de disco lento

• Monta los archivos de persistencia en un volumen/bind mount, no en la capa del contenedor.
• Limita memoria apropiadamente, pero deja margen para fork/rewrite copy-on-write.
• Reserva CPU suficiente para evitar inanición del hilo de fsync.
• No mezcles la ruta de datos con vecinos ruidosos (mismo disco para logs, descargas de imágenes y fsync de Redis).

Tareas prácticas: comandos, salidas y la decisión que tomas

Estas son las comprobaciones que hago cuando alguien dice “Redis está lento después de activar la persistencia.” Cada tarea incluye qué significa la salida y qué decides a continuación.
Ejecútalas en el host Docker salvo que se indique lo contrario.

Tarea 1: Verificar modo de persistencia de Redis desde dentro del contenedor

cr0x@server:~$ docker exec -it redis redis-cli CONFIG GET appendonly appendfsync save
1) "appendonly"
2) "yes"
3) "appendfsync"
4) "everysec"
5) "save"
6) "900 1 300 10 60 10000"

Qué significa: AOF está activado con fsync cada segundo; también están activadas las instantáneas RDB.

Decisión: Si no necesitas ambos, desactiva uno. Ejecutar ambos aumenta I/O y eventos de fork/rewrite. Prefiere un método de persistencia primario.

Tarea 2: Confirmar dónde escribe Redis los datos (y si está en overlay2)

cr0x@server:~$ docker exec -it redis redis-cli CONFIG GET dir dbfilename appendfilename
1) "dir"
2) "/data"
3) "dbfilename"
4) "dump.rdb"
5) "appendfilename"
6) "appendonly.aof"

Qué significa: Redis escribe en /data dentro del contenedor.

Decisión: Comprueba si /data es un volumen/bind mount. Si es solo el sistema de archivos del contenedor, arréglalo ahora.

Tarea 3: Inspeccionar montajes de Docker para el contenedor

cr0x@server:~$ docker inspect redis --format '{{json .Mounts}}'
[{"Type":"volume","Name":"redis-data","Source":"/var/lib/docker/volumes/redis-data/_data","Destination":"/data","Driver":"local","Mode":"z","RW":true,"Propagation":""}]

Qué significa: Bien: /data es un volumen Docker mapeado a una ruta del host.

Decisión: Si falta Type o Destination no es /data, probablemente estás escribiendo en overlay2. Mueve la persistencia a un montaje.

Tarea 4: Identificar el sistema de archivos que soporta el directorio de datos

cr0x@server:~$ df -Th /var/lib/docker/volumes/redis-data/_data
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/nvme0n1p2 ext4  450G  120G  307G  29% /

Qué significa: Los datos viven en ext4 en el filesystem raíz respaldado por NVMe local.

Decisión: Si esto muestra un tipo de sistema de archivos en red (como nfs) o un disco compartido lento, espera dolor con fsync. Considera mover los datos de Redis a SSD local.

Tarea 5: Comprobar opciones de montaje que afectan durabilidad y latencia

cr0x@server:~$ findmnt -no TARGET,FSTYPE,OPTIONS /var/lib/docker/volumes/redis-data/_data
/ ext4 rw,relatime,errors=remount-ro

Qué significa: Opciones estándar de ext4. Nada obviamente peligroso como data=writeback aquí.

Decisión: Si ves opciones exóticas que no entiendes en el montaje de datos de Redis, detente y valida. “Desconocido” no es una opción de montaje; es un incidente futuro.

Tarea 6: Medir latencia relacionada con persistencia desde Redis

cr0x@server:~$ docker exec -it redis redis-cli INFO persistence | egrep 'aof_enabled|aof_last_write_status|aof_last_fsync_status|aof_delayed_fsync|rdb_last_bgsave_status|rdb_last_bgsave_time_sec'
aof_enabled:1
aof_last_write_status:ok
aof_last_fsync_status:ok
aof_delayed_fsync:37
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:4

Qué significa: aof_delayed_fsync indica operaciones fsync que tardaron más de lo esperado (el kernel no pudo vaciar rápido).

Decisión: Si aof_delayed_fsync sube durante picos, céntrate en latencia y contención de almacenamiento, no en CPU de Redis.

Tarea 7: Revisar si la reescritura AOF está ocurriendo y causando stalls

cr0x@server:~$ docker exec -it redis redis-cli INFO persistence | egrep 'aof_rewrite_in_progress|aof_current_size|aof_base_size|aof_pending_rewrite|aof_current_rewrite_time_sec'
aof_rewrite_in_progress:0
aof_current_size:2147483648
aof_base_size:1073741824
aof_pending_rewrite:0
aof_current_rewrite_time_sec:-1

Qué significa: No hay reescritura ahora; el AOF se ha duplicado desde la base. Probablemente se disparará una reescritura según los umbrales.

Decisión: Si las reescrituras coinciden con picos de latencia, ajusta umbrales y confirma margen de E/S. Considera programar ventanas de mantenimiento solo si no puedes hacerla estable.

Tarea 8: Confirmar que el contenedor no está siendo estrangulado en CPU (la inanición del hilo fsync es real)

cr0x@server:~$ docker inspect redis --format '{{.HostConfig.NanoCpus}} {{.HostConfig.CpuQuota}} {{.HostConfig.CpuPeriod}}'
0 50000 100000

Qué significa: La cuota de CPU es 50% de un núcleo (50,000/100,000). Redis bajo carga con persistencia puede sufrir si tiene CPU limitada.

Decisión: Si los picos de latencia se correlacionan con estrangulamiento de CPU, aumenta la cuota o elimínala. No intentes engañar a la física con medio núcleo y escrituras síncronas.

Tarea 9: Comprobar margen de memoria para fork/rewrite

cr0x@server:~$ docker exec -it redis redis-cli INFO memory | egrep 'used_memory_human|maxmemory_human|mem_fragmentation_ratio'
used_memory_human:7.82G
maxmemory_human:8.00G
mem_fragmentation_ratio:1.41

Qué significa: Básicamente estás en el límite. Fork/rewrite te empujará a territorio OOM, especialmente con fragmentación en 1.41.

Decisión: Aumenta el margen de maxmemory (o reduce el dataset), o acepta que los eventos de persistencia puedan matar el proceso. Los contenedores no negocian.

Tarea 10: Observar latencia real del disco en el host (rápido y sucio)

cr0x@server:~$ iostat -x 1 5
Linux 6.2.0 (server) 	01/03/2026 	_x86_64_	(8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.11    0.00    6.05    8.90    0.00   72.94

Device            r/s     rkB/s   rrqm/s  %rrqm  r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm  w_await wareq-sz  aqu-sz  %util
nvme0n1         12.00   1400.00     0.00   0.00    1.10   116.67  950.00  18000.00  120.00  11.20   22.30    18.95   21.40  98.00

Qué significa: El disco está saturado (%util cerca de 100) y la espera de escritura es alta. El fsync de Redis va a notar esto.

Decisión: Encuentra la contención: otras cargas, tormentas de logs, descargas de imágenes o vecinos ruidosos en el mismo dispositivo. Mueve los datos de Redis o aísla el disco.

Tarea 11: Comprobar si el host está limitando el writeback de páginas sucias

cr0x@server:~$ sysctl vm.dirty_background_ratio vm.dirty_ratio
vm.dirty_background_ratio = 10
vm.dirty_ratio = 20

Qué significa: Valores más o menos por defecto. Si las proporciones dirty son demasiado bajas, el kernel puede forzar writeback síncrono más a menudo; si son altas puede causar tormentas de writeback grandes.

Decisión: Si ves stalls periódicos de varios segundos que coinciden con writeback, ajusta con cuidado y prueba. No “optimices” haciendo cargo de valores de sysctl por moda.

Tarea 12: Confirmar que Redis está realmente persistiendo en disco (archivos y tamaños)

cr0x@server:~$ ls -lh /var/lib/docker/volumes/redis-data/_data
total 3.1G
-rw-r--r-- 1 redis redis 2.0G Jan  3 10:12 appendonly.aof
-rw-r--r-- 1 redis redis 1.1G Jan  3 10:10 dump.rdb

Qué significa: Existen AOF y RDB y son de tamaño significativo.

Decisión: Decide si necesitas ambos. Si no, desactiva uno y recupera presupuesto de I/O. Si mantienes ambos, planifica capacidad y prueba tiempos de reinicio.

Tarea 13: Revisar logs del contenedor por advertencias de persistencia

cr0x@server:~$ docker logs --tail 200 redis | egrep -i 'AOF|fsync|rewrite|RDB|fork|latency|WARNING'
1:C 03 Jan 2026 10:12:05.101 # Background append only file rewriting started by pid 42
1:C 03 Jan 2026 10:12:12.220 # AOF rewrite child asks to stop sending diffs.
1:M 03 Jan 2026 10:12:12.221 # Parent agreed to stop sending diffs. Finalizing...
1:M 03 Jan 2026 10:12:12.980 # Background AOF rewrite finished successfully
1:M 03 Jan 2026 10:12:13.005 # Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.

Qué significa: Redis te está diciendo explícitamente que el disco está ocupado y que fsync es lento.

Decisión: Trata esto como un incidente de almacenamiento, no como un bug de la aplicación. Ve al nivel host: E/S, contención y ruta de montaje.

Tarea 14: Medir la distribución de latencia de comandos Redis (no adivines)

cr0x@server:~$ docker exec -it redis redis-cli --latency-history -i 1
min: 0, max: 87, avg: 2.41 (320 samples) -- 1.00 seconds range

Qué significa: Estás viendo picos ocasionales de 80+ ms. Eso concuerda con stalls por fsync o pausas por fork/rewrite.

Decisión: Si los picos se alinean con reescrituras AOF o saturación de disco, ajusta la persistencia y arregla el almacenamiento. Si se alinean con estrangulamiento de CPU, corrige límites de CPU.

Tarea 15: Verificar que la persistencia sobrevive al reinicio del contenedor (la única prueba que importa)

cr0x@server:~$ docker exec -it redis redis-cli SET durability_test 123
OK
cr0x@server:~$ docker restart redis
redis
cr0x@server:~$ docker exec -it redis redis-cli GET durability_test
"123"

Qué significa: Tu ruta y configuración de persistencia sobreviven un reinicio normal.

Decisión: Si esto falla, no estás persistiendo donde crees o tu configuración no está aplicada. Arregla eso antes de discutir sobre afinado.

Tarea 16: Comprobar si por accidente usas overlay2 para persistencia de todos modos

cr0x@server:~$ docker exec -it redis sh -lc 'mount | egrep " /data |overlay"'
/dev/nvme0n1p2 on /data type ext4 (rw,relatime,errors=remount-ro)
overlay on / type overlay (rw,relatime,lowerdir=/var/lib/docker/overlay2/l/...,upperdir=/var/lib/docker/overlay2/.../diff,workdir=/var/lib/docker/overlay2/.../work)

Qué significa: Genial: /data es un montaje ext4 real, separado de la raíz overlay.

Decisión: Si /data aparece como overlay, has encontrado tu respuesta a “¿por qué va lento?”. Muévelo a un volumen/bind mount.

Guion de diagnóstico rápido

Cuando la latencia de Redis empeora tras activar persistencia, quieres identificar el cuello de botella en minutos, no después de tres reuniones y una hoja de cálculo.
Comprueba esto en orden.

Primero: ¿estamos escribiendo en el lugar equivocado?

• Confirma dir y nombres de archivos: redis-cli CONFIG GET dir dbfilename appendfilename
• Confirma que existe un montaje: docker inspect ...Mounts y mount | grep /data
• Si los archivos de persistencia están en overlay2, detente. Muévelos a un volumen/bind mount y vuelve a probar.

Segundo: ¿la latencia del almacenamiento es la culpable?

• Busca advertencias de Redis sobre fsync lento en los logs.
• Revisa aof_delayed_fsync y si aumenta durante picos.
• Ejecuta iostat -x y observa w_await, aqu-sz y %util.
• Si el disco está saturado, encuentra al vecino ruidoso: backups, ingesta de logs, descargas de imágenes u otra base de datos en el mismo dispositivo.

Tercero: ¿presión de memoria/fork/rewrite?

• Comprueba margen de memoria: INFO memory y límites de memoria del contenedor.
• Revisa si la reescritura AOF o RDB bgsave se correlaciona con picos.
• Busca OOM kills en los logs del host si Redis desaparece durante eventos de persistencia.

Cuarto: ¿el estrangulamiento de CPU empeora todo?

• Inspecciona cuotas y límites de CPU.
• Correlaciona picos de latencia con métricas de estrangulamiento de CPU (estadísticas de cgroup si las tienes).
• La persistencia de Redis no es gratis; no la ejecutes como proceso de juguete en segundo plano y esperes latencia determinista.

Tres micro-historias corporativas desde las trincheras de durabilidad

1) Incidente por una suposición errónea: “Los volúmenes Docker siempre son persistentes”

Un equipo de producto de tamaño medio containerizó Redis para un servicio de sesiones. Usaron Docker Compose, pusieron appendonly yes y se sintieron responsables.
El despliegue “funcionó” durante semanas. Luego hicieron una actualización del SO del host y reconstruyeron el stack.

Tras la ventana de mantenimiento, las sesiones habían desaparecido. La aplicación se recuperó mal porque asumió que las sesiones existían y trató de validarlas contra claves ausentes.
Sus paneles mostraban Redis en ejecución, CPU bien, memoria bien. Pero los usuarios estaban efectivamente desconectados.

La causa raíz no fue Redis. Fue la suposición de que los datos persistían porque activaron persistencia.
No tenían montaje de volumen. /data vivía en la capa escribible del contenedor. Cuando reemplazaron el contenedor, reemplazaron el sistema de archivos.

La solución fue aburrida: un volumen nombrado montado en /data, más una prueba de reinicio en CI que escribe una clave, reinicia el contenedor y comprueba que sigue ahí.
También documentaron qué significa “persistencia” en su entorno: persistencia a una ruta de host específica, no “activé una opción”.

2) Optimización que salió mal: “Poner AOF en almacenamiento en red para sobrevivir al nodo”

Otra compañía quería resiliencia ante fallo de nodo sin usar replicación de Redis (larga historia, mayormente organigrama).
Alguien sugirió montar /data de Redis en un volumen de red para que cualquier nodo lo pudiera coger. Sonaba elegante en la diapositiva.

En pruebas, el throughput parecía bien. En producción, la latencia p99 se disparó en horas pico.
El equipo de app vio timeouts ocasionales y culpó a Redis. El equipo de plataforma vio CPU de Redis al 20% y dijo “no puede ser Redis”.
El SRE de guardia vio las advertencias de fsync en AOF y no se hizo popular.

El problema: almacenamiento en red con latencia de fsync inconsistente.
El flush con everysec aún necesita que el backend complete escrituras durables regularmente; cuando el almacenamiento encontró contención, fsync bloqueó más tiempo.
Redis hizo lo correcto: esperó; mientras tanto la app se derritió.

La resolución fue dejar de fingir que la persistencia remota es gratis. Movieron el AOF de vuelta a SSD local, añadieron replicación para resiliencia
y mantuvieron el almacenamiento en red solo para backups RDB periódicos copiados fuera de banda. La latencia se estabilizó de inmediato.

3) Práctica aburrida pero correcta que salvó el día: “Capacidad y margen para reescrituras”

Un servicio financiero usaba Redis como almacén de estado rápido. Activaron AOF con everysec y tenían un SLO ordenado.
El equipo tenía un hábito poco glamuroso: presupuestaban memoria y disco para eventos de persistencia en el peor caso, no para el uso medio.

Seguían tres números semanalmente: tamaño del dataset, tamaño del AOF y memoria pico durante la reescritura. Si el AOF crecía rápido, ajustaban umbrales.
Si la fragmentación de memoria subía, planificaban una ventana de reinicio controlada (con réplicas) en lugar de esperar un OOM aleatorio.

Un día cambió el patrón de tráfico—más escrituras, más churn. El AOF creció, las reescrituras se hicieron más frecuentes.
En un sistema menos disciplinado, aquí es donde obtienes una tormenta de reescrituras y picos de latencia que parecen un DDoS desde dentro del edificio.

Su sistema no se inmutó. Tenían margen. Las reescrituras terminaron antes de saturar discos y los picos de memoria por fork se mantuvieron bajo límites.
El informe del incidente fue corto y profundamente poco emocionante, que es el mayor elogio en operaciones.

Errores comunes: síntoma → causa raíz → solución

1) Redis es rápido sin persistencia, lento con AOF

Síntoma: Activar AOF hace que la latencia p99 salte y el throughput baje.

Causa raíz: latencia de fsync y contención de almacenamiento; a menudo empeorado por volúmenes de red o discos saturados.

Solución: Usa un volumen local respaldado por SSD, mantén appendfsync everysec, aísla los datos de Redis de I/O ruidoso y vigila aof_delayed_fsync.

2) Los datos desaparecen tras recrear el contenedor

Síntoma: Reiniciar el contenedor a veces mantiene los datos; redeploy los pierde.

Causa raíz: Archivos de persistencia almacenados en la capa escribible del contenedor (overlay2), no en un volumen/bind mount.

Solución: Monta /data en un volumen Docker o bind mount; verifica con docker inspect y una prueba de reinicio.

3) Picos de latencia periódicos cada pocos minutos

Síntoma: Picos que se correlacionan con tareas en segundo plano.

Causa raíz: Instantáneas RDB o reescrituras AOF causando fork copy-on-write, ráfagas de disco y presión de caché.

Solución: Ajusta el horario de snapshots; afina umbrales de reescritura AOF; asegura margen de memoria; considera desactivar RDB si AOF es primario.

4) Redis es OOM-kill durante reescritura o snapshot

Síntoma: El contenedor muere, se reinicia y los logs muestran actividad de persistencia alrededor del evento.

Causa raíz: Fork + copy-on-write incrementa temporalmente la memoria; límite de contenedor demasiado estrecho; fragmentación alta.

Solución: Aumenta límite/margen de memoria; reduce el dataset; considera un maxmemory menor que el límite del contenedor; vigila la relación de fragmentación.

5) AOF crece para siempre y los reinicios son lentos

Síntoma: Reinicio tarda mucho; AOF es enorme.

Causa raíz: Umbrales de reescritura AOF demasiado conservadores o reescritura fallando por falta de espacio en disco.

Solución: Establece auto-aof-rewrite-percentage/min-size sensatos; asegura espacio libre; revisa logs por fallos de reescritura.

6) Redis es “durable” pero aún pierde datos en un crash del host

Síntoma: Tras una pérdida de energía, el AOF tiene huecos aunque fsync estaba configurado.

Causa raíz: La pila de almacenamiento mintió sobre los flushes, cache de escritura volátil o comportamiento del layer de virtualización.

Solución: Usa almacenamiento con semántica de flush verificada; evita cache RAID insegura; valida escenarios de fallo; considera replicación y WAIT para garantías más fuertes.

7) Activar no-appendfsync-on-rewrite “arregló” latencia pero aumentó pérdida

Síntoma: La latencia se suaviza, pero tras un crash durante reescritura falta más datos de lo esperado.

Causa raíz: Aceptaste explícitamente una ventana de durabilidad mayor durante la reescritura.

Solución: Si la ventana de pérdida es inaceptable, desactívala y en su lugar arregla la ruta de disco y la contención I/O; o reduce la frecuencia de reescrituras.

Listas de verificación / plan paso a paso

Paso a paso: acertar la persistencia en Docker sin matar el rendimiento

1. Decide tu ventana de pérdida.
   ¿Minutos? Usa RDB. ¿Alrededor de un segundo? Usa AOF everysec. ¿“Ninguna”? Prepárate para replicación y almacenamiento serio.
2. Monta /data en un volumen real.
   Un volumen nombrado está bien. Un bind mount está bien. Overlay2 no está bien para esto.
3. Elige un método de persistencia primario.
   Ejecutar ambos es válido pero cuesta I/O y memoria. Si los mantienes, hazlo intencionadamente.
4. Presupuesta memoria para fork/rewrite.
   Deja margen. Si limitas el contenedor a “tamaño del dataset más un bocadillo”, el bocadillo desaparecerá en tiempo de ejecución.
5. Confirma el comportamiento de latencia del almacenamiento con comprobaciones reales.
   Vigila advertencias fsync y aof_delayed_fsync. No confíes en “es SSD” como métrica de rendimiento.
6. Fija umbrales de reescritura para evitar reescrituras sorpresa.
   Quieres que las reescrituras sean regulares y aburridas, no raras y catastróficas.
7. Prueba: escribe una clave → reinicia → lee la clave.
   Pónlo en CI o en un hook pre-despliegue. Si esta prueba falla, todo lo demás es teatro.
8. Monitoriza las señales correctas.
   Latencia de Redis, estadísticas de persistencia, latencia de disco, utilización de disco, fragmentación de memoria y eventos OOM de contenedor.

Checklist: cuando cambias la configuración de persistencia

• Confirma que la configuración se aplica (CONFIG GET).
• Confirma que la ruta de datos es un montaje (docker inspect, mount).
• Confirma que el disco tiene espacio libre para reescritura/snapshot.
• Ejecuta una prueba de carga que incluya escrituras y mida latencia p95/p99.
• Simula reinicio y verifica supervivencia de claves.
• Registra nueva línea base: aof_delayed_fsync, duración de snapshot, duración de reescritura.

Checklist: sanidad del almacenamiento para la persistencia de Redis

• SSD/NVMe local preferido para AOF.
• Evita compartir el dispositivo con escrituras pesadas de logs y backups.
• Valida semántica de flushs si reclamas durabilidad.
• Conoce tu tipo de sistema de archivos y opciones de montaje.

Preguntas frecuentes (FAQ)

1) ¿Debo activar RDB y AOF?

Solo si tienes una estrategia de restauración específica que se beneficie de ambos. AOF da mejor granularidad de durabilidad; RDB da instantáneas compactas y a veces reinicios en frío más rápidos.
Ejecutar ambos aumenta trabajo en background e I/O. Si no sabes por qué quieres ambos, probablemente no los necesitas.

2) ¿Por qué Redis se puso lento después de activar AOF?

AOF añade amplificación de escritura y comportamiento de flush. Incluso con everysec, Redis depende de que la ruta de almacenamiento complete flushes regulares.
fsync lento, discos saturados o volúmenes de red con latencia inconsistente se traducirán directamente en latencia de peticiones.

3) ¿Overlay2 de Docker es realmente tan malo para la persistencia de Redis?

Overlay2 está bien para imágenes de contenedores y escrituras pequeñas. La persistencia de Redis es intensiva en escrituras y sensible a latencia.
Overlay2 añade copy-on-write y overhead de metadatos. Puede que funcione a bajo volumen, hasta que deje de hacerlo. Pon la persistencia en un montaje.

4) ¿Cuál es el mejor ajuste de appendfsync?

Para la mayoría en producción: everysec. Es el equilibrio pragmático entre rendimiento y durabilidad.
Usa always solo cuando hayas validado el almacenamiento y realmente lo necesites. Usa no cuando Redis sea caché desechable y aceptes más pérdida.

5) ¿Puedo usar tmpfs para AOF para hacerlo rápido?

Puedes, pero derrotas el propósito de la persistencia: si el host pierde energía, tmpfs olvida todo con entusiasmo.
tmpfs puede ser útil para caches efímeros o como área intermedia combinada con otra estrategia de replicación/backup, pero no lo llames durabilidad.

6) Mi reescritura AOF causa picos de latencia. ¿Qué debo ajustar primero?

Primero asegúrate de que los datos estén en un camino de disco rápido y aislado. Luego ajusta umbrales de reescritura para evitar reescrituras frecuentes.
Si la ventana de pérdida lo permite, no-appendfsync-on-rewrite yes puede reducir stalls, pero es un trade-off consciente de durabilidad.

7) ¿Cómo sé si estoy perdiendo datos debido a la ventana de un segundo?

Con everysec, puedes perder hasta aproximadamente un segundo de escrituras reconocidas en un crash, a veces más si el sistema está bajo fuerte presión de E/S.
Vigila aof_delayed_fsync y métricas de almacenamiento; si los flushes se retrasan, tu ventana efectiva de pérdida crece.

8) ¿La persistencia de Redis es un backup?

No. La persistencia es recuperación ante fallos para ese nodo. Los backups requieren copias separadas, políticas de retención y verificación de restauración.
Trata la persistencia como “puedo reiniciar sin recargar todo desde upstream”, no como “tengo seguridad archivística”.

9) ¿Y si ejecuto Redis en Kubernetes—la misma historia?

La misma física, más abstracción. Aún necesitas un volumen persistente con rendimiento conocido, aún necesitas margen de memoria para fork/rewrite,
y aún necesitas probar el comportamiento de reinicio. Kubernetes facilita mover pods; no hace que fsync sea más rápido.

10) ¿Cuánto disco necesito para AOF?

Suficiente para el AOF actual, más espacio para la reescritura (ya que la reescritura escribe un archivo nuevo antes de sustituir) y un margen de seguridad.
Si vas justo de disco, las reescrituras fallan, el AOF crece, los reinicios son lentos y acabas depurando espacio en disco en lugar de servir tráfico.

Próximos pasos prácticos

Si ejecutas Redis en Docker y quieres persistencia sin convertirlo en una app lenta de disco, haz esto en orden:

1. Confirma que los archivos de persistencia están en un montaje real (volumen o bind mount) y no en overlay2.
2. Elige tu objetivo de durabilidad: RDB para recuperación gruesa, AOF everysec para recuperación más apretada.
3. Mide el dolor de fsync usando INFO persistence de Redis y iostat -x del host. No ajustes a ciegas.
4. Presupuesta margen de memoria para que fork/rewrite no active OOM.
5. Ejecuta la prueba de supervivencia al reinicio como puerta antes de cualquier despliegue que toque almacenamiento o configuración de Redis.

Redis puede ser rápido y persistente. Simplemente no lo hará por ti mientras escondes sus archivos dentro de un laberinto copy-on-write y lo llamas “cloud-native”.