Impacto de los reinicios del broker durante la aplicación de parches y otros tipos de mantenimiento - Transmisión gestionada de Amazon para Apache Kafka

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Impacto de los reinicios del broker durante la aplicación de parches y otros tipos de mantenimiento

Amazon MSK actualiza periódicamente el software de sus corredores. Estas actualizaciones no tienen ningún impacto en la redacción y lectura de sus solicitudes si sigue las mejores prácticas.

Amazon MSK utiliza actualizaciones continuas de software para mantener una alta disponibilidad de sus clústeres. Durante este proceso, los corredores se reinician de uno en uno y Kafka traslada automáticamente el liderazgo a otro corredor en línea. Los clientes de Kafka disponen de mecanismos integrados para detectar automáticamente el cambio de dirección de las particiones y seguir escribiendo y leyendo los datos en un clúster. MSK

Tras la desconexión de un bróker, es normal que sus clientes cometan errores transitorios de desconexión. También observará durante un breve período (hasta 2 minutos, normalmente menos) algunos picos en la latencia de lectura y escritura del p99 (normalmente altos milisegundos, hasta aproximadamente 2 segundos). Estos picos son esperados y se deben a que el cliente vuelve a conectarse con un nuevo bróker líder; no repercuten en sus productos ni en su consumo y se resolverán al volver a conectarse. Para obtener más información, consulte Broker offline y cliente por error.

También observará un aumento en la métricaUnderReplicatedPartitions, lo cual es de esperar, ya que las particiones del broker que se cerró ya no replican datos. Esto no afecta a las escrituras y lecturas de las aplicaciones, ya que las réplicas de estas particiones alojadas en otros intermediarios ahora atienden las solicitudes.

Tras la actualización del software, cuando el corredor vuelva a estar en línea, tendrá que «ponerse al día» con los mensajes producidos mientras estaba fuera de línea. Durante la recuperación, también puede observar un aumento en el uso del rendimiento del volumen yCPU. Esto no debería afectar a las escrituras y lecturas del clúster si dispone de suficientes recursos de memoriaCPU, red y volumen en sus corredores.