En Redis, hay dos opciones para almacenar datos de forma permanente: AOF (Append-Only File) y RDB (Redis Database Snapshot). En entornos de producción, generalmente se configuran ambas, pero muchos desarrolladores pueden preguntarse lo siguiente:
"Dado que AOF registra los datos en tiempo real, ¿tiene sentido la configuración de RDB?" "Dado que AOF tiene prioridad de recuperación, ¿no es innecesario RDB?"
Sin embargo, en un entorno de producción, RDB también es esencial. Veamos por qué.
1. El archivo AOF puede dañarse
AOF registra todos los cambios, pero tiene el riesgo de daño de archivo. Errores en el disco, fallos durante la operación, movimientos incorrectos de archivos, etc., pueden corromper el archivo AOF, haciéndolo difícil de recuperar.
redis-server --appendonly yes
Si el archivo AOF está dañado al reiniciar Redis, puede que no sea posible recuperar los datos. En tal caso, una copia de seguridad de RDB permite recuperar al menos algunos datos.
✅ ¿Qué pasa si solo usas AOF y el archivo se daña? Aumento del riesgo de pérdida de datos
✅ ¿Y si tienes RDB? Posibilidad de recuperar al menos algunos datos
2. La velocidad de recuperación de AOF es lenta
AOF necesita volver a ejecutar todos los cambios uno por uno para la recuperación. Cuanto más datos haya, más tiempo puede tomar la recuperación al reiniciar Redis.
Por ejemplo, si el archivo AOF tiene 2GB, Redis debe ejecutar millones de comandos SET. En cambio, RDB simplemente carga el archivo de volcado, lo que permite una recuperación mucho más rápida.
✅ Si usas solo AOF? Mayor riesgo de tiempos de recuperación prolongados
✅ ¿Y si usas RDB junto con AOF? Recuperación rápida posible
3. RDB es ventajoso para copias de seguridad y migración del servidor
Al hacer copias de seguridad de datos en un entorno de producción, AOF tiene un tamaño de archivo grande y su formato de registro hace que sea difícil de utilizar. Por otro lado, RDB tiene un tamaño de archivo pequeño y puede preservar los datos en un momento específico, lo que facilita la copia de seguridad.
✔ Ejemplo de copia de seguridad utilizando RDB:
cp /var/lib/redis/dump.rdb /backup/dump-2025-02-17.rdb
✔ Ejemplo de migración de datos a otro servidor:
scp /var/lib/redis/dump.rdb new-server:/var/lib/redis/
✅ AOF es más difícil de respaldar a medida que hay más datos
✅ RDB es favorable para respaldar y restaurar datos en momentos específicos
4. Se puede reducir la carga de I/O en disco
AOF debe registrar todos los cambios en el disco, lo que genera una alta carga de I/O en el disco. En cambio, RDB solo guarda los datos en intervalos regulares, lo que reduce la carga en el disco.
✅ ¿Si solo usas AOF? Posibilidad de aumento en la carga del disco
✅ ¿Y si lo usas junto con RDB? Posibilidad de optimizar el rendimiento
5. Configuración recomendada de RDB + AOF en entornos de producción
En un entorno de producción, se recomienda la siguiente configuración.
# Configuración de instantáneas de RDB (se guardan los datos en disco si se cumplen las condiciones)
# save <seconds> <changes> [<seconds> <changes> ...]
save 900 1 300 10 60 10000
# Guarda si hay cambios en más de 1 clave durante 900 segundos (15 minutos) o más de 10 claves durante 300 segundos (5 minutos), o más de 10,000 claves durante 60 segundos (1 minuto)
# Activación de AOF
appendonly yes
appendfsync everysec # Escribir en disco cada segundo para equilibrar rendimiento y estabilidad
# Optimización automática del tamaño del archivo AOF (reescritura)
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
🔍 ¿Cómo se evalúan múltiples condiciones de save?
En Redis, todas las condiciones save se evalúan como condiciones OR. Es decir, si se cumple cualquiera de las condiciones, se guarda la instantánea.
✔ Ejemplo 1: si se configuran save 900 1 y save 60 10000 - Se guarda la instantánea RDB si hay más de 1 cambio en 900 segundos o más de 10,000 cambios en 60 segundos.
✔ Ejemplo 2: si se añade la condición save 300 10 - La instantánea RDB se guarda si hay más de 10 cambios en 300 segundos o más de 1 cambio durante 900 segundos o más de 10,000 cambios durante 60 segundos.
✅ Todas las opciones de save se evalúan como condiciones OR
✅ Se guarda RDB inmediatamente si se cumple al menos una condición
Conclusión: A pesar de tener AOF, RDB es absolutamente necesario
✅ Con solo AOF, la protección de datos no es perfecta
✅ Si AOF se daña, RDB actúa como la última copia de seguridad
✅ Como la velocidad de recuperación de AOF puede ser lenta, la utilización de RDB permite recuperaciones rápidas
✅ RDB es favorable para copias de seguridad y migración del servidor
✅ Se puede reducir la carga de I/O en disco y optimizar el rendimiento
✅ La configuración de save funciona como condiciones OR, y se guarda RDB si se cumple alguna
Por lo tanto, en entornos de producción, la configuración de RDB + AOF es el método más seguro y óptimo.
Busque `Redis` en el cuadro de búsqueda de la derecha. Hay otros posts relacionados con Redis preparados para usted.
Revise también el artículo anterior que contiene un análisis sobre la función de Reescritura AOF.
Redis AOF Rewrite: Optimización de rendimiento y conservación de datos
Add a New Comment