As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Failback
<a name="msk-replicator-failback"></a>

Você pode retornar à AWS região principal após o término do evento de serviço nessa região.

------
#### [ Identical topic name replication ]

1. Crie um Replicador do MSK com o cluster secundário como origem e o cluster primário como destino e a posição de início definida para a replicação *mais antiga* de nomes de tópicos idênticos (**mantenha o mesmo nome de tópicos** no console). Isso começa a copiar todos os dados gravados no cluster secundário após o failover de volta para a região primária.

1. Monitore a `MessageLag` métrica no novo replicador na Amazon CloudWatch até que ela chegue`0`, o que indica que todos os dados foram replicados do secundário para o primário.

1. Depois que todos os dados tiverem sido replicados, interrompa a conexão de todos os produtores com o cluster secundário e inicie a conexão dos produtores com o cluster primário.

1. Aguarde a `MaxOffsetLag` métrica de seus consumidores que se conectam ao cluster secundário `0` para garantir que eles tenham processado todos os dados. Consulte [Monitorar atrasos do consumidor](consumer-lag.md).

1. Depois que todos os dados forem processados, interrompa os consumidores na região secundária e inicie a conexão dos consumidores ao cluster primário para concluir o failback.

1. Exclua o replicador que você criou na primeira etapa que está replicando dados do seu cluster secundário para o primário.

1. Verifique se o replicador existente que copia dados do cluster primário para o secundário tem o status “EM EXECUÇÃO” e se a `ReplicatorThroughput` métrica na Amazon CloudWatch é maior que`0`.

   Observe que quando você cria um novo replicador com a posição *inicial* como Early for failback, ele começa a ler todos os dados nos tópicos do seu cluster secundário. Dependendo das configurações de retenção de dados, os tópicos podem ter dados provenientes do cluster de origem. Embora o Replicador do MSK filtre automaticamente essas mensagens, você ainda incorrerá em cobranças de processamento e transferência de dados para todos os dados no cluster secundário. Você pode rastrear o total de dados processados pelo replicador usando `ReplicatorBytesInPerSec`.

------
#### [ Prefixed topic name replication ]

Você deve iniciar as etapas de failback somente depois que a replicação do cluster na região secundária para o cluster na região primária for recuperada e a métrica `MessageLag` na Amazon CloudWatch estiver próxima de 0. Um failback planejado não deve resultar em nenhuma perda de dados.

1. Feche todos os produtores e consumidores que se conectam ao cluster do MSK na região secundária.

1. Para a topologia ativa-passiva, exclua o replicador que está replicando dados do cluster na região secundária para a região primária. Você não precisa excluir o replicador para a topologia ativa-ativa.

1. Inicie a conexão dos produtores com o cluster do MSK na região primária.

1. Se seu aplicativo não exigir a ordenação de mensagens, inicie consumidores na AWS região principal que leiam os tópicos locais e replicados usando um operador curinga. Se seu aplicativo exigir a ordenação de mensagens, primeiro inicie os consumidores apenas para os tópicos replicados, espere que o atraso chegue a 0 e, em seguida, mude para tópicos locais.

1. Verifique se o replicador existente do cluster na região primária para o cluster na região secundária está no estado RUNNING e funcionando conforme o esperado usando as `ReplicatorThroughput` métricas de latência e.

------