View a markdown version of this page

Recaída por error - Transmisión administrada 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.

Recaída por error

Puede volver por recuperación a la AWS región principal una vez finalizado el evento de servicio en esa región.

Identical topic name replication

  1. Cree un nuevo Replicador MSK con el clúster secundario como origen y el clúster principal como destino; la posición inicial se establece como la más temprana y la replicación de nombres de temas idénticos (Mantener el mismo nombre de tema en la consola). Esto comienza a copiar todos los datos escritos en el clúster secundario después de la conmutación por error a la región principal.

  2. Supervise la MessageLag métrica en el nuevo replicador de Amazon CloudWatch hasta que llegue0, lo que indica que todos los datos se han replicado del secundario al principal.

  3. Una vez que se hayan replicado todos los datos, detenga la conexión de todos los productores al clúster secundario e inicie la conexión de los productores al clúster principal.

  4. Espere a que los consumidores que se conecten al clúster secundario se conviertan en MaxOffsetLag métricas 0 para asegurarse de que han procesado todos los datos. Consulte Supervisión del desfase del consumidor.

  5. Una vez que se hayan procesado todos los datos, detenga a los consumidores en la región secundaria e inicie la conexión de los consumidores al clúster principal para completar la conmutación por recuperación.

  6. Elimine el Replicador que creó en el primer paso y que consiste en replicar los datos del clúster secundario al principal.

  7. Compruebe que su replicador actual que copia datos del clúster principal al secundario tenga el estado «EN EJECUCIÓN» y que la ReplicatorThroughput métrica de Amazon CloudWatch sea superior 0 a.

    Tenga en cuenta que, al crear un replicador nuevo con la posición inicial de recuperación temprana, empezará a leer todos los datos de los temas del clúster secundario. En función de la configuración de retención de datos, es posible que los temas contengan datos procedentes del clúster de origen. Si bien el Replicador MSK filtra automáticamente esos mensajes, usted seguirá incurriendo en cargos por el procesamiento de datos y la transferencia de todos los datos de su clúster secundario. Puede realizar un seguimiento del total de datos procesados por el Replicador mediante ReplicatorBytesInPerSec.

Prefixed topic name replication

Debe iniciar los pasos de recuperación solo después de que la replicación del clúster de la región secundaria al clúster de la región principal se haya puesto al día y la MessageLag métrica de Amazon CloudWatch esté cerca de 0. Una conmutación por recuperación planificada no debería provocar la pérdida de datos.

  1. Desactive todos los productores y consumidores que se conectan al clúster de MSK de la región secundaria.

  2. Para una topología activa-pasiva, elimine el replicador que está replicando los datos del clúster de la región secundaria a la región principal. No es necesario eliminar el replicador para una topología activo-activo.

  3. Inicie los productores que se conectan al clúster de MSK de la región principal.

  4. Si su aplicación no requiere ordenar los mensajes, utilice un operador comodín para que los consumidores de la AWS región principal lean tanto los temas locales como los replicados. Si su aplicación requiere ordenar los mensajes, inicie primero con solo los temas replicados, espere a que el retraso llegue a 0 y, a continuación, cambie a los temas locales.

  5. Compruebe que el replicador existente desde el clúster de la región principal hasta el clúster de la región secundaria esté en ejecución y funcione según lo previsto utilizando las métricas ReplicatorThroughput y de latencia.