Borrar Datos en Redis: FLUSHDB vs FLUSHALL y sus Riesgos

Quieres borrar absolutamente todo en Redis, dejar la base de datos limpia. Es una tarea común, sobre todo en desarrollo o testeo. Sin embargo, hay un par de comandos para esto y es crucial entender sus diferencias para no cometer un error grave.

Los dos comandos son FLUSHDB y FLUSHALL. Ambos borran datos, pero el alcance es muy distinto. Aquí te explico cuándo usar cada uno y por qué debes tener cuidado.

FLUSHDB: Limpia tu Base de Datos Actual

El comando FLUSHDB es el que uso con más frecuencia. Su función es simple: elimina todas las claves de la base de datos de Redis a la que tu cliente está conectado en ese momento. Redis, por defecto, viene configurado con múltiples bases de datos lógicas, numeradas del 0 al 15.

Si estás conectado a la base de datos 0 (que es la predeterminada) y ejecutas FLUSHDB, solo se borrarán las claves de la base de datos 0. Las claves en la base de datos 1, 2, o cualquier otra, permanecerán intactas. Esto es clave.

Para mí, este es el comando más seguro y el que deberías preferir en la mayoría de los casos de limpieza específica. Piensa en un entorno de desarrollo donde necesitas reiniciar los datos de una funcionalidad en particular, o limpiar una base de datos específica de un microservicio sin tocar otras.

Así lo ejecutas desde la línea de comandos con redis-cli, asumiendo que quieres limpiar la DB 0:

redis-cli -n 0 FLUSHDB

El -n 0 le dice a redis-cli que se conecte a la base de datos número 0. Si no lo especificas y ya estás en otra DB, el comando afectará a esa. Es buena práctica ser explícito.

FLUSHALL: El Borrado Total y Peligroso

Aquí es donde viene el peligro si no tienes claro lo que haces. El comando FLUSHALL borra todas las claves de todas las bases de datos en la instancia de Redis a la que estás conectado. Sí, leíste bien: todas.

Si tienes datos en la DB 0, DB 1, DB 2, y así sucesivamente, FLUSHALL los eliminará todos sin piedad. Esto es un arma de doble filo: extremadamente útil para reiniciar una instancia de Redis por completo (por ejemplo, en un entorno de staging antes de un despliegue grande), pero catastrófico si lo ejecutas por error en producción o en una instancia compartida.

De hecho, yo he visto errores costosos por usar FLUSHALL cuando bastaba con FLUSHDB. La sobreingeniería de usar múltiples bases de datos sin un buen control de acceso y luego un FLUSHALL descuidado es una receta para el desastre.

Su ejecución es tan directa como peligrosa:

redis-cli FLUSHALL

No hay opción -n aquí porque afecta a todo el servidor.

Entendiendo las Bases de Datos en Redis

Redis no está diseñado como una base de datos relacional con esquemas y tablas separadas. Sus bases de datos lógicas (DB 0, DB 1, etc.) son más bien una forma simple de particionar tu espacio de claves. Puedes cambiar entre ellas con el comando SELECT:

redis-cli
127.0.0.1:6379> SELECT 1
OK
127.0.0.1:6379[1]> FLUSHDB
OK

En mi experiencia, la mayoría de las aplicaciones terminan usando solo la DB 0. Crear múltiples bases de datos en una misma instancia de Redis para diferentes partes de una aplicación o para distintos microservicios puede sonar bien en teoría, pero a menudo complica la gestión, los backups y la seguridad, sin ofrecer los beneficios de aislamiento que tendrías con instancias de Redis separadas.

Prefiero tener instancias de Redis separadas para entornos o aplicaciones completamente distintas, en lugar de depender de las bases de datos lógicas dentro de una sola instancia. Así evito confusiones y el riesgo de un FLUSHALL accidental es menor.

La Opción ASYNC: No Bloquear el Servidor

Tanto FLUSHDB como FLUSHALL pueden ser operaciones que bloquean el servidor (blocking operations). Esto significa que Redis detendrá el procesamiento de otras operaciones mientras está ocupado borrando millones de claves. Si tienes una base de datos muy grande, esto puede traducirse en tiempos de inactividad significativos para tu aplicación.

Por suerte, Redis 4.0 introdujo la opción ASYNC. Esta permite que la operación de borrado se realice en segundo plano, en un hilo separado, sin bloquear el hilo principal de Redis. El borrado no será instantáneo, pero tu servidor seguirá respondiendo a otras peticiones.

redis-cli FLUSHDB ASYNC
redis-cli FLUSHALL ASYNC

Yo tardé en adoptar el ASYNC, pero una vez que tuve un problema de rendimiento por un FLUSHDB en una base de datos grande, entendí su valor. Ahora es mi opción por defecto para cualquier purga de datos que no sea en un entorno de desarrollo local con poca información.

Consideraciones Adicionales

• Borrar Claves Específicas: Si no quieres borrar todo, sino solo un patrón de claves, puedes usar DEL para claves individuales o combinar SCAN con DEL para patrones. Esto es más complejo que un FLUSH, pero mucho más preciso.
• Seguridad: Limita el acceso a estos comandos en producción. Usa listas de control de acceso (ACL) de Redis para que solo usuarios o roles específicos puedan ejecutar FLUSHDB o FLUSHALL.
• Backups: Si hay alguna posibilidad de que necesites los datos, haz un backup de Redis antes de cualquier operación de borrado masivo. Es obvio, pero la gente lo olvida.

Error Común y Advertencia Final

El error más común y grave que veo es no entender la diferencia fundamental entre FLUSHDB y FLUSHALL. La gente piensa que FLUSHDB borrará su base de datos, sin considerar que quizás tienen otras bases de datos o que un compañero usa una DB diferente en la misma instancia de Redis.

Usar FLUSHALL sin pensar en un entorno compartido o de producción es una receta garantizada para un problema serio. Siempre, siempre, verifica a qué instancia de Redis estás conectado y qué bases de datos existen antes de ejecutar cualquier comando de borrado masivo. Y cuando dudes, usa FLUSHDB con la opción ASYNC y sé explícito con el número de base de datos.