A ver, seamos honestos. Cuando te topas con un problema en Kafka, especialmente si estás en local y algo se atasca, la solución más rápida que se te viene a la cabeza es: “borro el topic y lo creo de nuevo”. De hecho, yo mismo lo hice un par de veces al principio, antes de entender bien cómo funcionaba el bicho por dentro. Es intuitivo, ¿verdad? Si algo está mal, lo eliminas y empiezas de cero.
Pero ojo que, aunque borrar y recrear funciona, casi nunca es la mejor solución cuando lo que quieres es simplemente purgar el contenido de un topic, sobre todo si tienes configuraciones específicas que no quieres perder o si el topic ya está en producción.
El problema: un mensaje gigante y un topic atascado
Imagínate esto: estás probando algo, empujas un mensaje a tu topic de Kafka en local, y resulta que el mensaje es tan, pero tan grande, que el consumidor empieza a fallar con un error tipo RecordTooLargeException o algo similar. La consola se llena de errores y no puedes procesar nada más allá de ese mensaje maldito. La pregunta de Stack Overflow que me dio la idea para esto es un buen ejemplo de ese escenario.
Tu primera reacción podría ser pensar en aumentar el fetch.size de tu consumidor para que pueda manejar mensajes más grandes. Pero, tal como menciona el tipo de la pregunta, no quieres aceptar mensajes de ese tamaño en tu sistema, así que esa no es una solución real, es solo parchar el síntoma.
La solución elegante: el retention.ms
Aquí es donde entra el truco del retention.ms. Kafka tiene una configuración para cada topic que define por cuánto tiempo se guardan los mensajes. Si configuras ese tiempo a un valor muy bajo (como un segundo), Kafka purgará rápidamente todos los mensajes que estén en el topic, incluyendo ese mensaje gigante que te está dando problemas.
Así es como lo harías:
kafka-configs.sh \
--bootstrap-server localhost:9092 \
--entity-type topics \
--alter \
--entity-name mi-topic-problema \
--add-config retention.ms=1000
Este comando cambia la configuración de retention.ms para tu topic mi-topic-problema a 1000 milisegundos (1 segundo). Después de ejecutarlo, dale un par de minutos, dependiendo del tamaño del topic y la cantidad de mensajes que tenía. Kafka empezará a borrar automáticamente los mensajes que ya expiraron.
Una vez que estés seguro de que el topic está limpio y el mensaje gigante ya no está (puedes verificarlo intentando consumir de nuevo), restauras el valor original de retention.ms:
kafka-configs.sh \
--bootstrap-server localhost:9092 \
--entity-type topics \
--alter \
--entity-name mi-topic-problema \
--add-config retention.ms=604800000
# O el valor que tenias antes, por ejemplo 7 dias (604800000 ms)
Si aún usas Zookeeper (algo que ya está medio obsoleto, pero sé que en algunos setups todavía aparece), el comando sería con kafka-topics.sh:
kafka-topics.sh \
--zookeeper localhost:2181 \
--alter \
--topic mi-topic-problema \
--config retention.ms=1000
¿Por qué esta es una mejor solución?
- Preserva la configuración: No pierdes particiones, replication factors, ni otras configuraciones personalizadas que le hayas puesto al topic.
- Menos disruptivo: Especialmente en ambientes que no son local, borrar un topic puede tener implicaciones en otros componentes que dependan de él y de su configuración.
- Más limpio: Estás usando una característica propia de Kafka para gestionar sus datos, en lugar de un “reseteo” forzado.
¿Cuándo sirve borrar y recrear?
No todo es blanco o negro, y mi frustración con la sobreingeniería a veces me hace sonar más extremo de lo que soy. La opción de borrar y recrear un topic, que mencionaba la segunda respuesta en Stack Overflow, sí tiene su lugar. Yo la uso cuando:
- Estoy haciendo pruebas muy iniciales en mi máquina local y realmente no me importa ninguna configuración o dato.
- Quiero asegurarme de que el topic está absolutamente vacío y con sus configuraciones por defecto (o muy básicas) para empezar un test desde cero.
- El topic tiene una configuración tan desastrosa que es más rápido y seguro empezar de cero que intentar arreglarlo. Esto me ha pasado con repos de clientes que estaban muy mal configurados.
Sin embargo, para purgar datos específicos sin afectar la estructura y configuración del topic, la opción de retention.ms es, en mi opinión, la forma más limpia y profesional de hacerlo. Es una de esas cosas que, una vez que la aprendes, te das cuenta de que te ahorra varios dolores de cabeza y te da un control mucho más granular sobre tus temas de Kafka.
Conclusión: el tradeoff real
Al final, todo se reduce a un tradeoff. Si estás en local, en un ambiente de desarrollo que puedes borrar y recrear sin dramas, y no tienes configuraciones complejas que mantener, entonces borrar y recrear el topic es una solución rápida y funciona. Es lo que yo llamo una solución “de emergencia”.
Pero si tu topic ya tiene configuraciones específicas, estás en un ambiente compartido, o simplemente quieres una solución más elegante que respete la infraestructura de Kafka, entonces ajustar temporalmente el retention.ms es la vía correcta. Te da control, evita perder configuraciones y es una práctica mucho más robusta. Es, en mi caso, la solución que prefiero y la que recomiendo para la mayoría de escenarios reales.