Mejores Prácticas para Prevenir la Pérdida de Datos: Configuración RDB vs. AOF

La persistencia de Redis es fácil de malinterpretar porque Redis se siente como una base de datos pero se comporta primero como memoria. Si lo reinicias sin persistencia, los datos desaparecen. Si la persistencia está habilitada pero ajustada descuidadamente, aún puedes perder escrituras recientes, bloquear clientes durante presión de disco, o descubrir durante una interrupción que la única copia de tus datos reside en el mismo volumen fallido que el proceso de Redis.

La estrategia correcta de pérdida de datos de Redis comienza con una pregunta honesta: ¿qué sucede si desaparecen las últimas escrituras de segundos, minutos u horas? Un caché de páginas de producto generalmente se puede reconstruir. Un almacén de sesiones puede molestar a los usuarios pero no destruir el negocio. Una cola, un libro de contabilidad de límite de tasa, un almacén de carritos o un almacén de indicadores de características pueden necesitar una durabilidad mucho más estricta. RDB y AOF son las dos herramientas que Redis te ofrece, y resuelven diferentes partes de ese problema.

Comprendiendo los Mecanismos de Persistencia de Redis

Redis tiene dos modos principales de persistencia:

Instantáneas RDB

RDB escribe una instantánea puntual del conjunto de datos en el disco, usualmente como dump.rdb. Redis bifurca un proceso hijo, el hijo serializa el conjunto de datos y el padre sigue atendiendo clientes. Esto hace que RDB sea útil para copias de seguridad, réplicas y reinicios rápidos, pero tiene una compensación clara: cualquier cosa escrita después de la última instantánea exitosa puede perderse si el proceso o el host falla.

Las configuraciones típicas de RDB se ven así:

save 900 1       # Guardar después de 15 minutos si al menos 1 clave cambió
save 300 10      # Guardar después de 5 minutos si al menos 10 claves cambiaron
save 60 10000    # Guardar después de 1 minuto si al menos 10000 claves cambiaron
dbfilename dump.rdb
dir /var/lib/redis

Esas líneas save no son una promesa de que Redis guardará exactamente en ese horario. Son reglas de activación: si suficientes claves cambiaron durante el intervalo, Redis inicia un guardado en segundo plano. Si el disco es lento, el conjunto de datos es enorme o el host tiene poca memoria, el guardado en segundo plano puede fallar o crear latencia a través de la presión de bifurcación y copia en escritura.

RDB es más fuerte cuando deseas instantáneas compactas y un comportamiento de restauración rápido. Es más débil cuando tu tolerancia a la pérdida de datos recientes es baja.

Registro AOF

AOF, o persistencia de archivo de solo añadidura, registra comandos de escritura para que Redis pueda reproducirlos al reiniciar. Generalmente ofrece mejor durabilidad que RDB porque puede vaciar las escrituras con más frecuencia que un horario de instantáneas. La compensación es más E/S de disco, archivos más grandes antes de la reescritura y, a veces, un inicio más lento si Redis tiene que reproducir un registro grande.

Las configuraciones principales son:

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
aof-auto-rewrite-percentage 100
aof-auto-rewrite-min-size 64mb
aof-rewrite-incremental-fsync yes

La línea importante es appendfsync. Con everysec, Redis le pide al sistema operativo que vacíe el AOF aproximadamente una vez por segundo. En un fallo normal del proceso de Redis, eso generalmente limita la pérdida a aproximadamente el último segundo de escrituras. En un fallo completo del host o una falla de almacenamiento, la pérdida exacta depende del SO, sistema de archivos, caché de disco y comportamiento del almacenamiento, así que no lo describas como una garantía matemática.

appendfsync always vacía después de cada escritura y es mucho más costoso. Puede ser apropiado para una implementación pequeña y crítica de Redis con un volumen de escritura modesto, pero puede perjudicar gravemente la latencia bajo tráfico real. appendfsync no permite que el SO decida cuándo vaciar; es rápido, pero te da una ventana de pérdida mucho más amplia y menos predecible.

Mejores Prácticas para la Prevención de Pérdida de Datos

Usa ambos solo cuando entiendas qué archivo cargará Redis

Muchas implementaciones de Redis en producción habilitan tanto RDB como AOF. Eso es un valor predeterminado sensato cuando Redis almacena datos que serían dolorosos de reconstruir. RDB te da artefactos de copia de seguridad compactos. AOF te da una ventana de pérdida reciente más pequeña.

Usa una configuración como esta:

save 900 1
save 300 10
save 60 10000
appendonly yes
appendfsync everysec

Un detalle importa durante la restauración: cuando AOF está habilitado, Redis normalmente carga los datos AOF al inicio porque se espera que sean más completos que la instantánea RDB. No asumas que Redis cargará RDB primero y recurrirá a AOF. Prueba la ruta de restauración para tu versión de Redis y diseño de implementación, especialmente en versiones de Redis que usan el formato AOF multiparte más nuevo.

Elige appendfsync desde la ventana de pérdida hacia atrás

Comienza con el impacto en el negocio, no con la configuración de Redis.

Si Redis es un caché desechable, RDB solo puede ser suficiente, o incluso ninguna persistencia si tu aplicación se repuebla de manera segura. Si Redis contiene sesiones, appendfsync everysec suele ser un equilibrio práctico. Si Redis es parte de un flujo de trabajo donde perder escrituras reconocidas crea daños comerciales reales, la persistencia de Redis sola puede no ser el límite de durabilidad adecuado. Puede que necesites una base de datos principal, una cola duradera o un comportamiento de registro de escritura por adelantado a nivel de aplicación fuera de Redis.

Para la mayoría de los usos operativos de Redis, comienza con:

appendonly yes
appendfsync everysec

Luego observa la latencia, el tiempo de escritura en disco, el comportamiento de reescritura AOF y el tiempo de reinicio antes de decidir si moverte hacia always o alejarte de AOF.

Mantén instantáneas RDB, pero no las hagas demasiado agresivas

Los guardados RDB frecuentes reducen la cantidad de datos perdidos entre instantáneas, pero también aumentan la frecuencia de bifurcación. Bifurcar un proceso grande de Redis puede ser costoso, y las escrituras durante el guardado del hijo crean presión de memoria por copia en escritura. Si tu instancia de Redis tiene un conjunto de datos de 40 GB y la tasa de escritura es alta, guardar cada minuto puede crear peor confiabilidad porque el host pasa demasiado tiempo bajo presión de memoria y disco.

Las reglas de guardado RDB razonables dependen de la tasa de escritura y las expectativas de recuperación. Un caché pequeño puede tomar instantáneas con frecuencia sin problemas. Un almacén de sesiones grande puede necesitar menos instantáneas RDB más AOF para durabilidad reciente. Observa INFO persistence, los registros de Redis y la memoria del host durante BGSAVE, no solo el archivo de configuración de Redis.

Trata la reescritura AOF como mantenimiento normal, no como una emergencia

Los archivos AOF crecen porque registran escrituras. Redis los reescribe en una representación compacta en segundo plano. Los valores predeterminados suelen ser un punto de partida decente:

aof-auto-rewrite-percentage 100
aof-auto-rewrite-min-size 64mb

Eso significa que Redis considera la reescritura cuando el AOF ha crecido significativamente en comparación con el tamaño después de la reescritura anterior, una vez que alcanza al menos el tamaño mínimo. Si las reescrituras ocurren constantemente, aumenta el tamaño mínimo o investiga un patrón de escritura ruidoso. Si el AOF crece durante mucho tiempo sin reescribirse, verifica los registros, el espacio en disco y INFO persistence.

Puedes activar una reescritura manualmente:

redis-cli BGREWRITEAOF

Hazlo durante un período tranquilo si es posible. Una reescritura es más segura que dejar que el archivo crezca para siempre, pero aún consume CPU, ancho de banda de disco y memoria de copia en escritura.

Haz una copia de seguridad de los archivos de persistencia en otro lugar

La persistencia no es una copia de seguridad. Los archivos de persistencia en el mismo host te protegen de un reinicio del proceso de Redis. No te protegen de un disco perdido, eliminación accidental, una implementación incorrecta que sobrescribe el directorio de datos, o un error del operador que ejecuta FLUSHALL.

Copia los archivos RDB y AOF a un almacenamiento separado. Si usas instantáneas del sistema de archivos o instantáneas de volumen en la nube, prueba la restauración en una instancia separada. Para copias RDB, prefiere copiar un archivo de instantánea completado en lugar de un archivo que se está escribiendo. Para AOF, comprende el diseño del archivo para tu versión de Redis antes de construir scripts de copia de seguridad basados en nombres de archivo.

Observa las señales que predicen la pérdida de datos

El comando útil durante un incidente es:

redis-cli INFO persistence

Busca guardados en segundo plano fallidos, estado de reescritura AOF, última hora de guardado e indicadores de fsync retrasado. Combínalo con métricas del host: latencia de disco, espacio libre en disco, margen de memoria y eventos OOM del kernel. Si BGSAVE falla durante horas y nadie lo nota, la configuración de Redis puede parecer segura mientras el punto de recuperación real se vuelve cada vez más antiguo.

Usa replicación o Sentinel para disponibilidad, no como tu única copia de seguridad

Las réplicas, Redis Sentinel y Redis Cluster ayudan con la disponibilidad. No resuelven automáticamente todos los problemas de pérdida de datos. Una escritura incorrecta, eliminación accidental o error de aplicación puede replicarse rápidamente. La conmutación por error también puede promover una réplica que carece de escrituras recientes si existe retraso de replicación. Mantén la persistencia, las copias de seguridad y las pruebas de restauración en el diseño.

La configuración práctica para muchos equipos es AOF con appendfsync everysec, instantáneas RDB a un ritmo razonable, copias de seguridad externas, monitoreo de fallos de persistencia y un runbook de restauración probado. Redis puede ser confiable en esa forma, pero solo si tratas la persistencia como un sistema operativo en lugar de una casilla de verificación.