Elegir la Mejor Estrategia de Persistencia de Redis: RDB vs AOF.

Redis almacena datos en memoria, por lo que necesitas una estrategia de persistencia antes de confiar en él para cualquier cosa que no puedas reconstruir fácilmente. La elección entre RDB y AOF afecta la cantidad de datos que puedes perder, la rapidez con que Redis se reinicia y la cantidad de E/S de disco que genera tu carga de trabajo.

Usa RDB cuando las instantáneas periódicas sean suficientes. Usa AOF cuando necesites una mayor durabilidad. Usa ambos cuando necesites durabilidad práctica más copias de seguridad más fáciles, pero aún así prueba la recuperación con tu conjunto de datos real.

Comprendiendo la Persistencia en Redis

La persistencia en Redis se refiere a la capacidad de guardar el conjunto de datos en memoria en el disco, para que pueda recargarse después de un reinicio o fallo del servidor. Sin persistencia, todos los datos almacenados en Redis se perderían si el servidor se detiene o falla. Redis ofrece dos métodos distintos para lograr esto:

RDB (Base de Datos Redis): Una instantánea puntual de tu conjunto de datos.
AOF (Archivo de Solo Anexión): Un registro de cada operación de escritura realizada por el servidor.

Ambos métodos tienen sus propias características y son adecuados para diferentes escenarios.

Base de Datos Redis (RDB)

La persistencia RDB realiza instantáneas puntuales de tu conjunto de datos de Redis en intervalos especificados. Cuando se activa una operación de guardado RDB, Redis bifurca un proceso hijo. El proceso hijo luego escribe todo el conjunto de datos en un archivo RDB temporal. Una vez que el archivo está completo, el archivo RDB antiguo se reemplaza con el nuevo.

Cómo Funciona RDB

Bifurcación: El servidor Redis bifurca un nuevo proceso hijo.
Instantánea: El proceso hijo comienza a escribir todo el conjunto de datos en un archivo RDB temporal.
Finalización: Una vez que el proceso hijo termina de escribir, reemplaza el archivo RDB antiguo con el nuevo archivo temporal.
Limpieza: El proceso hijo finaliza.

Este proceso asegura que Redis pueda seguir atendiendo solicitudes de clientes mientras se toma la instantánea, ya que el proceso padre permanece receptivo.

Ventajas de RDB

Copias de Seguridad Compactas: Los archivos RDB están comprimidos en binario, ofreciendo una representación muy compacta de tu conjunto de datos de Redis. Esto los hace ideales para copias de seguridad y recuperación ante desastres.
Reinicios Rápidos: Recargar un archivo RDB es significativamente más rápido que reproducir un archivo AOF, especialmente para conjuntos de datos grandes, ya que implica cargar un único archivo binario preformateado.
E/S de Disco Mínima: Los guardados RDB solo ocurren en intervalos configurados, lo que significa que Redis realiza una E/S de disco mínima cuando no está guardando. Esto puede llevar a un mayor rendimiento durante las operaciones normales.
Fácil de Transferir: Al ser un único archivo compacto, las copias de seguridad RDB son fáciles de transferir a centros de datos remotos para recuperación ante desastres o fines de archivo.

Desventajas de RDB

Posible Pérdida de Datos: El principal inconveniente es la posible pérdida de datos. Si Redis falla entre puntos de guardado, todos los datos escritos desde el último guardado RDB exitoso se perderán.
Pico de Rendimiento durante la Bifurcación: Para conjuntos de datos muy grandes, la operación inicial fork() puede ser lenta y bloquear el servidor Redis por un corto período, especialmente si el uso de memoria es alto.
Persistencia No en Tiempo Real: RDB no está diseñado para la persistencia de datos en tiempo real. Es más adecuado para escenarios donde perder unos minutos de datos es aceptable.

Configuración de RDB

La persistencia RDB está habilitada por defecto en redis.conf usando la directiva save. Puedes especificar múltiples reglas save:

# Guardar la base de datos cada 900 segundos (15 minutos) si al menos 1 clave cambió
save 900 1

# Guardar la base de datos cada 300 segundos (5 minutos) si al menos 10 claves cambiaron
save 300 10

# Guardar la base de datos cada 60 segundos si al menos 10000 claves cambiaron
save 60 10000

# Deshabilitar la persistencia RDB (comentar todas las directivas save, o establecer explícitamente lo siguiente)
# save ""

También puedes activar un guardado RDB manualmente usando los comandos SAVE (bloqueante) o BGSAVE (no bloqueante) en redis-cli.

Archivo de Solo Anexión (AOF)

La persistencia AOF registra cada operación de escritura recibida por el servidor Redis. En lugar de guardar todo el conjunto de datos periódicamente, AOF registra los comandos que modifican el conjunto de datos. Cuando Redis se reinicia, re-ejecuta estos comandos en el archivo AOF para reconstruir el conjunto de datos original.

Cómo Funciona AOF

Registro de Comandos: Cada comando de escritura ejecutado por Redis se añade al archivo AOF.
Política fsync: Redis tiene varias políticas fsync para controlar la frecuencia con la que el búfer AOF se sincroniza con el disco:
- appendfsync always: Sincroniza después de cada comando. Esto ofrece la mejor durabilidad pero es el más lento.
- appendfsync everysec: Sincroniza una vez por segundo. Este es un buen equilibrio entre durabilidad y rendimiento (predeterminado y recomendado).
- appendfsync no: Depende del sistema operativo para vaciar el búfer AOF al disco. Ofrece el mejor rendimiento pero la menor durabilidad.
Reescritura AOF: Con el tiempo, el archivo AOF puede crecer mucho debido a comandos redundantes (por ejemplo, actualizar la misma clave varias veces). La reescritura AOF optimiza el archivo AOF creando un nuevo archivo AOF más pequeño que contiene solo los comandos necesarios para reconstruir el conjunto de datos actual. Este proceso es similar al mecanismo de bifurcación de RDB.

Ventajas de AOF

Mejor Durabilidad: Con appendfsync always o everysec, AOF ofrece una durabilidad más fuerte que las instantáneas RDB periódicas. Con everysec, Redis generalmente limita la pérdida a aproximadamente un segundo de escrituras confirmadas, aunque los fallos del sistema operativo o del disco aún pueden afectar la durabilidad.
Menos Pérdida de Datos: En caso de fallo, pierdes significativamente menos datos, si es que pierdes alguno, dependiendo de tu política fsync.
Formato Inspeccionable: AOF almacena comandos del protocolo Redis, por lo que puede ser inspeccionado y reparado con herramientas de Redis más fácilmente que un archivo RDB.

Desventajas de AOF

Tamaño de Archivo Más Grande: Los archivos AOF son generalmente mucho más grandes que los archivos RDB para el mismo conjunto de datos porque almacenan comandos en lugar de datos compactos.
Recuperación Más Lenta: Reproducir un archivo AOF grande al inicio puede ser más lento que cargar un archivo RDB, ya que Redis necesita ejecutar cada comando.
Impacto en el Rendimiento: Dependiendo de la política fsync, AOF puede introducir más E/S de disco, impactando potencialmente el rendimiento de escritura. appendfsync always es especialmente impactante.
Sobrecarga de Reescritura AOF: Si bien la reescritura AOF ayuda a gestionar el tamaño del archivo, el proceso de reescritura en sí consume recursos de CPU y E/S y puede bloquear momentáneamente a Redis si el conjunto de datos es muy grande, similar a la bifurcación de RDB.

Configuración de AOF

Para habilitar AOF, necesitas establecer appendonly yes en tu redis.conf:

# Habilitar persistencia AOF
appendonly yes

# El nombre del archivo de solo anexión (predeterminado: "appendonly.aof")
appendfilename "appendonly.aof"

# Opciones de appendfsync: always, everysec, no
appendfsync everysec

# Reescritura automática del archivo AOF cuando es el doble del tamaño base y tiene al menos 64MB
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

RDB vs. AOF: Una Visión Comparativa

Característica	RDB (Copia de Seguridad de Base de Datos Redis)	AOF (Archivo de Solo Anexión)
Mecanismo	Instantáneas puntuales (archivo binario)	Registro de operaciones de escritura en formato de protocolo Redis
Pérdida de Datos	Pérdida potencial entre puntos de guardado	Generalmente alrededor de un segundo con `everysec`; más fuerte con `always`
Rendimiento	Mayor rendimiento de escritura durante operaciones normales, posible bloqueo en `fork()`	Escrituras más lentas con `fsync` fuerte, E/S más consistente
Tamaño de Archivo	Archivos binarios muy compactos	Generalmente más grande, crece con las operaciones
Tiempo de Recuperación	Más rápido para conjuntos de datos grandes	Más lento para conjuntos de datos grandes (reproduciendo comandos)
Facilidad de Copia de Seguridad	Archivo único y compacto; fácil para copias de seguridad/recuperación ante desastres	Archivo más grande, potencialmente más difícil de gestionar sin reescritura
Legibilidad	No legible por humanos	Más inspeccionable que RDB
Predeterminado en Redis	Sí (con directivas `save`)	No (`appendonly no` por defecto)

El Enfoque Híbrido: RDB y AOF Juntos

Redis puede usar instantáneas RDB y AOF juntos. Cuando AOF está habilitado, Redis usa AOF para la recuperación al inicio porque generalmente está más actualizado. Redis moderno también puede usar un preámbulo RDB dentro de archivos AOF reescritos cuando aof-use-rdb-preamble yes está habilitado, lo que acelera las reescrituras y los reinicios.

Reescrituras Más Rápidas: La parte RDB del AOF híbrido proporciona una instantánea inicial mucho más rápida para el proceso de reescritura.
Reinicios Más Rápidos (Potencialmente): Cuando Redis se reinicia, primero carga la porción RDB del archivo AOF, que es más rápida, y luego reproduce los comandos AOF subsiguientes.
Mejor Durabilidad: Aún se beneficia de la pérdida mínima de datos de AOF.

Verifica tu versión de Redis y configuración antes de asumir que el AOF híbrido está habilitado.

Elegir la Estrategia de Persistencia Correcta

La estrategia de persistencia ideal depende de los requisitos específicos de tu aplicación en cuanto a durabilidad de datos, rendimiento y tiempo de recuperación.

1. Cuándo Usar Solo RDB

Caso de Uso Principal: Caché / Datos No Críticos: Si Redis se usa principalmente como caché donde perder algunos datos en un fallo es aceptable, o si tus datos pueden reconstruirse fácilmente desde otra fuente.
Altos Requisitos de Rendimiento: Cuando el rendimiento de escritura es primordial y la pérdida ocasional de datos es tolerable.
Copias de Seguridad para Recuperación ante Desastres: Los archivos RDB son excelentes para crear instantáneas periódicas para archivo a largo plazo o recuperación ante desastres. Puedes programar un BGSAVE con cron y luego mover el archivo .rdb fuera del sitio.
Eficiencia de Memoria: Si estás muy limitado en espacio en disco.

2. Cuándo Usar Solo AOF

Caso de Uso Principal: Durabilidad Absoluta: Cuando cada operación de escritura es crítica y perder incluso unos segundos de datos es inaceptable (por ejemplo, transacciones financieras, datos críticos de usuario). En este caso, se podría considerar appendfsync always, aunque con un costo de rendimiento significativo.
Depuración/Auditoría: La naturaleza legible por humanos de AOF puede ser beneficiosa para entender los cambios en los datos.

3. Cuándo Usar Ambos RDB y AOF (Recomendado para la Mayoría de Aplicaciones Críticas)

Durabilidad y Recuperación Equilibradas: Este es generalmente el enfoque recomendado para sistemas de producción donde la durabilidad de los datos es importante, pero también deseas reinicios y copias de seguridad eficientes.
Robustez: Proporciona una capa adicional de protección. Si un método de persistencia se corrompe, aún podrías recuperarte con el otro.
AOF Híbrido: Aprovecha el formato AOF con preámbulo RDB donde sea compatible y esté habilitado.

Consejos Prácticos y Mejores Prácticas

Monitorear el Uso del Disco: Tanto RDB como AOF pueden consumir espacio en disco significativo. Monitorea tu uso de disco para asegurarte de no quedarte sin espacio, especialmente antes de reescrituras AOF o guardados RDB.
Política fsync: Para AOF, appendfsync everysec es la opción más común y recomendada, ofreciendo un buen equilibrio entre durabilidad y rendimiento. Evita appendfsync no para datos críticos.
Reescritura AOF: Configura auto-aof-rewrite-percentage y auto-aof-rewrite-min-size cuidadosamente para asegurar que los archivos AOF se optimicen regularmente sin un consumo excesivo de recursos.
Discos/Ubicaciones Separados: Si es posible, almacena tus archivos de persistencia (AOF y RDB) en un disco o partición diferente a la de tu sistema operativo y registros de aplicación para prevenir contención de E/S.
Copias de Seguridad Externas: Independientemente de tu estrategia de persistencia, realiza copias de seguridad periódicas de tus archivos RDB y AOF en una ubicación fuera del sitio (por ejemplo, S3, Google Cloud Storage) para una recuperación ante desastres robusta.
Probar la Recuperación: Prueba periódicamente tu proceso de recuperación con la estrategia de persistencia elegida para asegurar que los datos puedan restaurarse exitosamente.

Conclusión

Elige la persistencia según los requisitos de recuperación, no por costumbre. Redis solo para caché a menudo puede usar RDB o ninguna persistencia. Redis usado para sesiones, colas o estado de aplicación generalmente necesita AOF, copias de seguridad probadas y un simulacro de reinicio que demuestre que los datos regresan lo suficientemente rápido.