La última vez, hablamos de la compatibilidad del conector Kafka de Couchbase con compresión e IPv6. Desde entonces, hemos mejorado el conector del sumidero con soporte para establecer valores de tiempo de vida para los documentos entrantes, y hemos añadido la capacidad de asignar IDs de documentos compuestos por múltiples campos del documento.
Recientemente nos hemos centrado en garantizar que el conector Kafka sea lo más tolerante posible a fallos. Hoy me gustaría presentar la versión beta 3.4 del conector Kafka y hablar de una importante mejora en la forma en que se gestionan las reversiones después de una conmutación por error. Nuestro objetivo al lanzar una versión beta es poner esta característica en sus manos lo antes posible para que podamos incorporar sus comentarios en la versión final.
Un pesimista es un realista que mantiene un sistema distribuido
El hardware falla todo el tiempo. Ahora mismo, en algún lugar del mundo, un controlador de E/S quemado está enviando señales de humo. Los nodos de Couchbase pueden fallar y fallan, pero una de las mejores razones para construir tu aplicación en Couchbase es que cuando ocurre el inevitable fallo de hardware, la recuperación es pan comido.
Cada bucket de Couchbase se divide en varios "buckets virtuales", y cada partición se replica en los nodos del clúster. En un momento dado, una de las copias está "activa", es decir, es con la que hablarán los clientes. (Un cliente también puede leer de una réplica, pero tiene que desviarse para hacerlo). Puedes pensar en una réplica como una copia de seguridad en tiempo real de una instancia activa.
Entonces, ¿qué pasa cuando esa señal de humo proviene de un nodo en un clúster Couchbase? En algún momento, querrás fallar sobre el nodo fallido (eliminándolo del cluster) y reequilibrar (reasignando las tareas del nodo fallido a los nodos restantes). Por cada partición que estaba activa en el nodo que ha fallado, una de las réplicas pasa a estado "activo". Los nodos restantes también recogen la carga y comienzan a alojar réplicas adicionales para reemplazar las que estaban en el nodo que ha fallado.
Dependiendo de las necesidades de su despliegue, todo el proceso de conmutación por error y reequilibrio puede iniciarse pulsando un botón o mediante un algoritmo de detección automática de fallos. Genial, ¿verdad?
Ahora que el escenario está preparado, consideremos una cuestión importante: ¿qué ocurre cuando una réplica no está completamente actualizada cuando falla la instancia activa?
La respuesta (que espero no sorprenda a nadie) es que los cambios que aún no se hayan guardado en la réplica se pierden. En términos de ciencia ficción, esos cambios estaban en una línea temporal alternativa que ha dejado de existir. Han sido "retrocedidos".
No estoy tratando de causar una gran sensación / Sólo talkin 'bout mitigación rollback
¿Qué tiene que ver todo esto con el conector Kafka? El conector utiliza el protocolo Database Change Protocol (DCP) para recibir notificaciones de cambios. La implementación del protocolo DCP está diseñada para ser rápida, y anuncia los cambios incluso antes de que se escriban en el disco. Para compensar este optimismo, el protocolo también incluye un mecanismo de reversión que dice: "Lo siento, he hablado demasiado pronto. ¿Recuerdas los últimos cambios de los que te hablé? Bueno, en realidad no ocurrieron". Esto funciona muy bien en Couchbase Server, donde somos conscientes de estos detalles de particionamiento y podemos adaptarnos a las nuevas realidades a medida que suceden. Es exactamente lo que hacemos con la replicación, actualizaciones de texto completo, actualizaciones de índices, etc.
Las versiones anteriores del conector Kafka publicaban los eventos en el tema Kafka inmediatamente. En cuanto el servidor DCP anunciaba un cambio, éste se publicaba en el tema. Cuando se producía un retroceso, no había mucho que hacer al respecto; los mensajes de Kafka no se pueden retractar una vez publicados, ya que los temas son sólo append. Los consumidores recibirían mensajes irreales de esa línea temporal alternativa de la que hablamos.
Dependiendo de su aplicación, los mensajes de salto de dimensión pueden ser inofensivos, o pueden causar pánico. Si prefieres que tus temas de Kafka solo contengan cambios reales, persistentes y replicados en la base de datos, prepárate para recibir buenas noticias.
Detalles para desorientados
Suficiente acumulación. Hablemos de lo que hay en la beta y de cómo funciona la mitigación del retroceso.
Cuando la mitigación de rollback está habilitada (que es por defecto), el conector comprobará automáticamente con Couchbase Server qué cambios han sido realmente persistidos en disco. El conector almacenará los cambios hasta que se observe la persistencia en todas las réplicas. En ese momento es muy poco probable que los cambios sean revertidos (aunque todavía es posible en algunos escenarios que involucran múltiples fallos). Entonces, y sólo entonces, el conector publicará los mensajes en el tema Kafka.
Naturalmente, hay algo de latencia y un poco de sobrecarga con este esquema. Si desea volver al comportamiento anterior de publicar los cambios inmediatamente, la mitigación de reversión puede desactivarse fácilmente; consulte la documentación para obtener más detalles.
Seguir la corriente
El control de flujo es una técnica para evitar que los productores superen a los consumidores. En nuestro caso, el conector Kafka envía mensajes de acuse de recibo al servidor DCP para informar de cuántos datos se han procesado. El servidor detiene el flujo cuando la cantidad de datos no reconocidos supera un umbral denominado "tamaño del búfer de control de flujo".
Dado que la mitigación de la reversión implica el almacenamiento en búfer de un número potencialmente grande de mensajes, es importante que el tamaño del búfer de control de flujo sea ajustable.
Las versiones anteriores del conector utilizaban un tamaño de búfer de 20 megabytes. El nuevo valor por defecto es de 128 megabytes, lo que permite un almacenamiento en búfer más agresivo. Siéntase libre de ajustar este valor para ver lo que funciona mejor para su carga de trabajo. Si quiere aumentarlo mucho, puede asignar más memoria al conector mediante la opción KAFKA_HEAP_OPTS variable de entorno.
Todas las buenas corrientes deben llegar a un EOF
Esperamos que pruebes la beta 3.4 con mitigación de retrocesos. Descárgala desde el enlace de la parte superior de la página Guía de inicio rápido. Por favor, publique sus impresiones en el Foro Couchbase y haremos todo lo posible por incorporar sus comentarios a la versión final. Gracias y hasta la próxima.
