Descripción breve

Amazon Managed Streaming para Apache Kafka (Amazon MSK) utiliza actualizaciones sucesivas para mantener una alta disponibilidad y admite la E/S del clúster durante la aplicación de parches. Durante este proceso, los corredores se reinician uno por uno y el siguiente corredor no se reinicia hasta que las particiones del corredor reiniciado actual se recuperen por completo (sincronizadas). Es normal ver errores de desconexión transitorios en sus clientes durante este proceso de actualización.

Para evitar que los clientes sufran períodos de inactividad durante la aplicación de parches de seguridad, utilice las siguientes prácticas recomendadas para que los clústeres tengan una alta disponibilidad.

Resolución

Configurar un clúster Three-AZ

Si se produce un error en una zona de disponibilidad, un clúster Three-AZ protege contra cualquier tiempo de inactividad.

Amazon MSK establece la propiedad de corredor broker.rack para lograr una asignación de replicación con reconocimiento de rack para la tolerancia a errores a nivel de zona de disponibilidad. Esto significa que cuando utiliza un clúster Three-AZ con un factor de replicación (RF) de tres, cada una de las tres réplicas de particiones se encuentra en una zona de disponibilidad independiente.

Nota: Tener un clúster Two-AZ con un RF-3 no permite que cada una de las tres réplicas de particiones se encuentre en una zona de disponibilidad independiente. Amazon MSK no permite crear un clúster en una única zona de disponibilidad.

Asegúrese de que el factor de replicación sea el recuento de zonas de disponibilidad

Al reiniciar un corredor durante la aplicación del parche de seguridad, el líder deja de estar disponible. Como resultado, se elige a una de las réplicas seguidoras como nueva líder para que el clúster pueda seguir prestando servicios a los clientes.

Un RF-1 puede provocar que las particiones no estén disponibles durante una actualización continua, ya que el clúster no tiene réplicas que promocionar como nuevo líder. Un RF-2, con una réplica sincronizada (miniSR) mínima de una, puede provocar la pérdida de datos, incluso cuando el acuse de recibo del productor (acks) esté configurado en «all» (todos). Para que una escritura tenga éxito, una miniSR de una solo requiere que el líder reconozca la escritura. Si el corredor de la réplica líder deja de funcionar inmediatamente después del acuse de recibo, pero antes de que la réplica seguidora se ponga al día, se producen pérdidas de datos. Para obtener más información sobre min.insync.replicas, consulte la documentación de Apache Kafka.

Establezca el miniSR mínimo en RF-1 como máximo

Fijar miniSR al valor de RF puede provocar fallos en el productor cuando un corredor está fuera de servicio debido a una actualización continua. Si las réplicas no envían un acuse de recibo para que el productor lo escriba, entonces el productor hace una excepción. Por ejemplo, si AZ es igual a tres y RF es igual a tres, el productor espera a que las tres réplicas de particiones (incluida la principal) confirmen los mensajes. Cuando uno de los corredores está fuera de servicio, solo dos de las tres particiones devuelven los acuses de recibo, lo que da lugar a excepciones para los productores.

En este escenario, se asume que los paquetes del productor están configurados en «all» (todos). Si configura los paquetes del productor en «all» (todos), el registro no se pierde mientras permanezca viva al menos una réplica sincronizada. Para obtener más información sobre los paquetes de producción, consulte la documentación de Apache Kafka.

Incluya al menos un corredor de cada AZ en la cadena de conexión del cliente

El cliente utiliza un único punto de conexión de corredor para iniciar una conexión al clúster. Durante la conexión inicial con el cliente, el corredor envía metadatos con información sobre los corredores a los que el cliente debe acceder.

Cuando un corredor deja de estar disponible, se produce un error en la conexión. Por ejemplo, solo tiene un corredor en la cadena de conexión de un cliente. Durante la aplicación de parches, el cliente no establece una conexión inicial con el clúster cuando se reinicia el corredor.

O bien, tiene varios corredores en una cadena de conexión de cliente. En este caso, la cadena de conexión del cliente permite la conmutación por error cuando el corredor que se utiliza para establecer la conexión se desconecta. Para obtener más información sobre cómo configurar una cadena de conexión con varios corredores, consulte Obtener los corredores de arranque para un clúster de Amazon MSK.

Permitir reintentos

Al reiniciar un corredor, las particiones principales de ese corredor dejan de estar disponibles. Como resultado, Apache Kafka promueve las réplicas de particiones en otro corredor como nuevos líderes. El cliente ahora solicita una actualización de metadatos para localizar las nuevas particiones principales. Durante este cambio, es normal que su cliente experimente errores transitorios.

De forma predeterminada, los clientes tienen incorporados reintentos para gestionar este tipo de errores transitorios. Confirme que su cliente esté configurado para reintentos. Para obtener más información sobre la configuración de los reintentos, consulte la documentación de Apache Kafka.