Evitando una Elección de Líder Sucia de Kafka

Contexto:
Cluster de Kafka de 6 nodos. Alto volumen de lecturas/consumidores y escrituras.

Requisito/deseo:
Muy poco/ningún tiempo de inactividad.

Estado actual:
De vez en cuando (hasta ahora tal vez una vez cada 6 meses/año) ocurre una elección de líder no limpia.

Literatura/Referencias:

• Descripción de elección de líder no limpia: https://www.datadoghq.com/blog/kafka-at-datadog/#unclean-leader-elections-to-enable-or-not-to-enable

• Posible solución (dos clusters de Kafka): https://www.datadoghq.com/blog/kafka-at-datadog/#unclean-leader-elections-to-enable-or-not-to-enable

• Segunda posible solución en https://www.datadoghq.com/blog/kafka-at-datadog/#unclean-leader-elections-to-enable-or-not-to-enable es desactivar la configuración de elección de líder no limpia, pero esto no es aceptable para nosotros, porque en lugar de tener una elección de líder no limpia, cuando la configuración está desactivada una partición podría volverse inaccesible (cita: “Si no puede elegir un nuevo líder, Kafka detendrá todas las lecturas y escrituras en esa partición”). Y requerimos que todos los datos sean accesibles.

• ¿El nuevo Kafka no requiere ZooKeeper, cierto? ¿Entonces esto no es un problema simplemente actualizando Kafka?

Pregunta:
¿Hay algo inherente a nuestro cluster de Kafka que pueda causar la elección de líder no limpia que podamos evitar? Según la literatura anterior, Datadog parece sugerir simplemente ejecutar dos clusters de Kafka (presumiblemente con una capa de deduplicación que coordine entre los dos), pero por supuesto nos gustaría evitar los costos adicionales que esto conlleva. Causa aproximadamente de 10 a 20 minutos de tiempo de inactividad mientras se resuelve la elección de líder no limpia.