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á.
# O que é o replicador do Amazon MSK?
O Replicador do Amazon MSK é um recurso do Amazon MSK que permite replicar dados de modo confiável em clusters do Amazon MSK de regiões diferentes ou nas mesmas Região da AWS. No entanto, os clusters de origem e de destino devem estar na mesma conta da Conta da AWS. Com o Replicador do MSK, você pode criar facilmente aplicações de streaming regionalmente resilientes para aumentar a disponibilidade e a continuidade dos negócios. O replicador do MSK fornece replicação assíncrona automática em clusters do MSK, eliminando a necessidade de criar código personalizado, gerenciar a infraestrutura ou configurar redes entre regiões.
O replicador do MSK escala automaticamente os recursos subjacentes, permitindo que você replique dados sob demanda sem precisar monitorar ou escalar a capacidade. O MSK Replicator também replica os metadados necessários do Kafka, incluindo configurações de tópicos, listas de controle de acesso () ACLs e compensações de grupos de consumidores. Se ocorrer um evento inesperado em uma região, você pode fazer o failover para a outra AWS região e retomar o processamento sem problemas.
O replicador do MSK é compatível com Cross-Region Replication (CRR – Replicação entre regiões) e Same-Region Replication (SRR – Replicação na mesma região). Na replicação entre regiões, os clusters MSK de origem e de destino estão em regiões diferentes. AWS Na replicação na mesma região, os clusters MSK de origem e de destino estão na mesma região. AWS Você precisa criar clusters de origem e de destino do MSK antes de usá-los com o Replicador do MSK.
**nota**
O MSK Replicator suporta as seguintes AWS regiões: Leste dos EUA (us-east-1, Norte da Virgínia); Leste dos EUA (us-east-2, Ohio); Oeste dos EUA (us-west-2, Oregon); Europa (eu-west-1, Irlanda); Europa (eu-central-1, Frankfurt); Ásia-Pacífico (ap-southeast-1 Ásia-Pacífico, Cingapura); Ásia-Pacífico (ap-southeast-2, Sydney); Europa (eu-north-1, Estocolmo); Ásia-Pacífico (ap-south-1, Mumbai); Europa (eu-west-3, Paris); América do Sul (sa-east-1, São Paulo); Ásia Pacífico (ap-northeast-2, Seul); Europa (eu-west-2, Londres); Ásia-Pacífico (ap-northeast-1, Tóquio); Oeste dos EUA (us-west-1, Norte da Califórnia); Canadá (ca-central-1, Central); China (Pequim) (cn-north-1); China (Ningxia) (cn-northwest-1); Ásia-Pacífico (Hyderabad) (ap-south-2), Ásia-Pacífico (Malásia) (ap-southeast-5), Ásia-Pacífico (Tailândia) (ap-sudeste-7), México (Central) (mx-central-1), Ásia-Pacífico (Taipei) (ap-east-2), Oeste do Canadá (Calgary) (ca-west-1), Europa (Espanha) (eu-south-2), Oriente Médio (Bahrein) (me-south-1), Ásia-Pacífico (Jacarta) (ap-southeast-3), África (Cidade do Cabo) (af-south-1), Oriente Médio (EAU) (me-central-1), Ásia-Pacífico (Hong Kong) (ap-east-1), Ásia-Pacífico (Osaka) (ap-northeast-3), Ásia Pacífico (Melbourne) (ap-southeast-4), Europa (Milão) (eu-sul-1), Israel (Tel Aviv) (il-central-1), Europa (Zurique) (eu-central-2) e Ásia-Pacífico (Nova Zelândia) (ap-southeast-6)
Veja alguns usos comuns do Replicador do Amazon MSK.
+ Crie aplicações de streaming multirregionais: crie aplicações de streaming altamente disponíveis e tolerantes a falhas para aumentar a resiliência sem configurar soluções personalizadas.
+ Acesso a dados com menor latência: forneça acesso a dados com menor latência para consumidores em diferentes regiões geográficas.
+ Distribua dados para seus parceiros: copie dados de um cluster do Apache Kafka para vários clusters do Apache Kafka, para que os diferentes teams/partners tenham suas próprias cópias dos dados.
+ Agregar dados para analytics: copie dados de vários clusters do Apache Kafka em um cluster para gerar facilmente insights sobre dados agregados em tempo real.
+ Escreva localmente, acesse seus dados globalmente: configure a replicação multiativa para propagar automaticamente as gravações realizadas em uma AWS região para outras regiões, fornecendo dados com menor latência e custo.
# Funcionamento do replicador do Amazon MSK
Para começar a usar o MSK Replicator, você precisa criar um novo replicador na região do seu cluster de destino. AWS *O MSK Replicator copia automaticamente todos os dados do cluster na AWS região primária chamada *origem* para o cluster na região de destino chamada destino.* Os clusters de origem e de destino podem estar na mesma região ou em AWS regiões diferentes. Você precisará criar o cluster de destino se ele não existir.
Quando você cria um replicador, o MSK Replicator implanta todos os recursos necessários na AWS região do cluster de destino para otimizar a latência da replicação de dados. A latência de replicação varia com base em muitos fatores, incluindo a distância da rede entre as AWS regiões dos seus clusters MSK, a capacidade de taxa de transferência dos clusters de origem e de destino e o número de partições nos clusters de origem e de destino. O replicador do MSK escala automaticamente os recursos subjacentes, permitindo que você replique dados sob demanda sem precisar monitorar ou escalar a capacidade.
## Replicação de dados
Por padrão, o Replicador do MSK copia todos os dados de maneira assíncrona do deslocamento mais recente nas partições de tópicos do cluster de origem para o cluster de destino. Se a configuração “Detectar e copiar novos tópicos” estiver ativada, o Replicador do MSK detectará e copiará automaticamente novos tópicos ou partições de tópicos para o cluster de destino. No entanto, pode levar até 30 segundos para que o replicador detecte e crie os novos tópicos ou partições de tópicos no cluster de destino. Qualquer mensagem produzida no tópico de origem antes da criação do tópico no cluster de destino não será replicada. Como alternativa, você pode [configurar o replicador durante a criação](msk-replicator-prepare-cluster.md) para iniciar a replicação a partir do primeiro deslocamento nas partições de tópicos do cluster de origem, caso queira replicar as mensagens existentes nos tópicos para o cluster de destino.
O Replicador do MSK não armazena seus dados. Os dados são consumidos do cluster de origem, armazenados em buffer na memória e gravados no cluster de destino. O buffer é limpo automaticamente quando os dados são gravados com êxito ou falham após novas tentativas. Toda a comunicação e os dados entre o Replicador do MSK e os clusters são sempre criptografados em trânsito. Todas as chamadas da API do MSK Replicator`DescribeClusterV2`, como,`CreateTopic`, `DescribeTopicDynamicConfiguration` são capturadas em. AWS CloudTrail Os logs do agente do MSK também refletirão o mesmo.
O Replicador do MSK cria tópicos no cluster de destino com um fator de replicação de 3. Se necessário, você pode modificar o fator de replicação diretamente no cluster de destino.
## Replicação de metadados
O Replicador do MSK também é compatível com a cópia dos metadados do cluster de origem para o cluster de destino. Os metadados incluem configuração de tópicos, listas de controle de acesso (ACLs) e compensações de grupos de consumidores. Assim como a replicação de dados, a replicação de metadados também ocorre de forma assíncrona. Para uma melhor performance, o Replicador do MSK prioriza a replicação de dados sobre a replicação de metadados.
A tabela a seguir é uma lista das listas de controle de acesso (ACLs) que o MSK Replicator copia.
| Operation | Pesquisa | APIs permitido |
| --- | --- | --- |
| Alter | Tópico | CreatePartitions |
| AlterConfigs | Tópico | AlterConfigs |
| Criar | Tópico | CreateTopics, Metadados |
| Delete | Tópico | DeleteRecords, DeleteTopics |
| Descrever | Tópico | ListOffsets, Metadados,, OffsetFetch OffsetForLeaderEpoch |
| DescribeConfigs | Tópico | DescribeConfigs |
| Ler | Tópico | Busque, OffsetCommit TxnOffsetCommit |
| Write (deny only) | Tópico | Produzir, AddPartitionsToTxn |
O MSK Replicator copia o tipo de padrão LITERAL ACLs somente para o tipo de recurso Topic. O tipo de padrão PREFIXADO ACLs e outro tipo de recurso não ACLs são copiados. O MSK Replicator também não exclui ACLs no cluster de destino. Se você excluir uma ACL no cluster de origem, também deverá excluir no cluster de destino ao mesmo tempo. [Para obter mais detalhes sobre os ACLs recursos, padrões e operações do Kafka, consulte https://kafka.apache.org/documentation/\$1security\$1authz\$1cli.](https://kafka.apache.org/documentation/#security_authz_cli)
O MSK Replicator replica somente o Kafka ACLs, que o controle de acesso do IAM não usa. Se seus clientes estão usando o controle de acesso do IAM read/write aos seus clusters do MSK, você também precisa configurar as políticas relevantes do IAM no cluster de destino para um failover contínuo. Isso também é válido para configurações de replicação de nomes de tópicos prefixados e idênticos.
Como parte da sincronização de deslocamentos de grupos de consumidores, o Replicador do MSK otimiza para os consumidores no cluster de origem, que estão lendo de uma posição mais próxima à ponta do stream (final da partição do tópico). Se os grupos de consumidores estiverem em atraso no cluster de origem, você poderá observar um atraso maior para esses grupos de consumidores no destino em comparação com a origem. Isso significa que, após o failover para o cluster de destino, os consumidores reprocessarão mais mensagens duplicadas. Para reduzir esse atraso, os consumidores no cluster de origem precisariam se atualizar e começar a consumir a partir da ponta do stream (final da partição do tópico). À medida que os consumidores se atualizarem, o Replicador do MSK reduzirá automaticamente o atraso.
![\[Clusters de origem e destino do replicador do MSK\]](http://docs.aws.amazon.com/pt_br/msk/latest/developerguide/images/msk-replicator-diagram.png)
## Configuração do nome do tópico
O Replicador do MSK tem dois modos de configuração de nomes de tópicos: *Prefixado* (padrão) ou replicação de nomes de tópicos *Idênticos*.
**Replicação de nomes de tópicos prefixados**
Por padrão, o Replicador do MSK cria tópicos no cluster de destino com um prefixo gerado automaticamente adicionado ao nome do tópico do cluster de destino, como `.topic`. Isso serve para distinguir os tópicos replicados de outros no cluster de destino e para evitar a replicação circular de dados entre os clusters.
Por exemplo, o MSK Replicator replica dados em um tópico chamado “tópico” do cluster de origem para um novo tópico no cluster de destino chamado < Alias>.topic. sourceKafkaCluster Você pode encontrar o prefixo que será adicionado aos nomes dos tópicos no cluster de destino no campo **sourceKafkaClusterAlias** usando a `DescribeReplicator` API ou a página de detalhes do **Replicator** no console do MSK. O prefixo no cluster de destino é < sourceKafkaCluster Alias>.
Para garantir que os consumidores possam reiniciar o processamento de maneira confiável diretamente do cluster em espera, você precisa configurar os consumidores para ler os dados dos tópicos usando um operador curinga `.*`. Por exemplo, seus consumidores precisariam consumir usando. `*topic1`em ambas as AWS regiões. Esse exemplo também pode incluir um tópico como `footopic1`, portanto, ajuste o operador curinga de acordo com suas necessidades.
Você deve usar o Replicador do MSK, que adicionará um prefixo quando você quiser manter os dados do replicador em um tópico separado no cluster de destino, como para configurações de cluster ativo-ativo.
**Replicação de nomes de tópicos idênticos**
Como alternativa à configuração padrão, o Replicador do Amazon MSK permite que você crie um replicador com a replicação de tópicos definida como replicação de nomes de tópicos idênticos (**mantenha o mesmo nome de tópicos** no console). Você pode criar um novo replicador na AWS região que tenha seu cluster MSK de destino. Tópicos replicados com nomes idênticos permitem que você evite reconfigurar clientes para ler tópicos replicados.
A replicação de nomes de tópicos idênticos (**mantenha o mesmo nome de tópicos** no console) tem as seguintes vantagens:
+ Permite que você mantenha nomes de tópicos idênticos durante o processo de replicação, além de evitar automaticamente o risco de loops de replicação infinitos.
+ Simplifica a configuração e a operação de arquiteturas de streaming de vários clusters, pois você pode evitar a reconfiguração de clientes para ler os tópicos replicados.
+ Para arquiteturas de cluster ativo-passivo, a funcionalidade de replicação de nomes de tópicos idênticos também simplifica o processo de failover, permitindo que as aplicações façam o failover facilmente para um cluster em espera sem exigir nenhuma alteração no nome do tópico ou reconfiguração do cliente.
+ Pode ser usado para consolidar com mais facilidade dados de vários clusters do MSK em um único cluster para agregação de dados ou analytics centralizado. Isso exige que você crie replicadores separados para cada cluster de origem e para o mesmo cluster de destino.
+ Pode simplificar a migração de dados de um cluster do MSK para outro replicando dados para tópicos de nomes idênticos no cluster de destino.
O Replicador do Amazon MSK usa cabeçalhos do Kafka para evitar automaticamente que os dados sejam replicados de volta ao tópico de origem, eliminando o risco de ciclos infinitos durante a replicação. Um cabeçalho é um par de chave-valor que pode ser incluído com a chave, o valor e o carimbo de data e hora em cada mensagem do Kafka. O Replicador do MSK incorpora identificadores para o cluster e o tópico de origem no cabeçalho de cada registro que está sendo replicado. O Replicador do MSK usa as informações do cabeçalho para evitar loops de replicação infinitos. Você deve verificar se os clientes conseguem ler os dados replicados conforme o esperado.
# Tutorial: Configurar clusters de origem e destino para o Replicador do Amazon MSK
Este tutorial mostra como configurar um cluster de origem e um cluster de destino na mesma AWS região ou em AWS regiões diferentes. Posteriormente, você também pode usar esses clusters para criar um replicador do Amazon MSK.
# Preparar o cluster de origem do Amazon MSK
Se você já tiver um cluster de origem do MSK criado para o replicador do MSK, certifique-se de que ele atenda aos requisitos descritos nesta seção. Caso contrário, siga estas etapas para criar um cluster de origem com a tecnologia sem servidor ou provisionado do MSK.
O processo de criação de um cluster de origem do replicador do MSK entre regiões e na mesma região é semelhante. As diferenças estão nas chamadas nos procedimentos a seguir.
1. Crie um cluster provisionado ou com tecnologia sem servidor do MSK com o [controle de acesso do IAM ativado](create-iam-access-control-cluster-in-console.md) na região de origem. Seu cluster de origem deve ter, no mínimo, três agentes.
1. Para um replicador do MSK entre regiões, se a origem for um cluster provisionado, configure-o com a conectividade privada multi-VPC ativada para esquemas de controle de acesso do IAM. Observe que não há compatibilidade com o tipo de autenticação não autenticado quando o recurso multi-VPC estiver ativado. Você não precisa ativar a conectividade privada de várias VPCs para outros esquemas de autenticação (mTLS) ou esquemas de SASL/SCRAM). You can simultaneously use mTLS or SASL/SCRAM autenticação para seus outros clientes que se conectam ao seu cluster MSK. Você pode configurar a conectividade privada multi-VPC nos detalhes do cluster no console, nas **Configurações de rede** ou com a API `UpdateConnectivity`. Consulte [Proprietário do cluster ativa o recurso multi-VPC](mvpc-cluster-owner-action-turn-on.md). Se seu cluster de origem for um cluster do MSK Serverless, você não precisará ativar a conectividade privada multi-VPC.
Para um replicador do MSK na mesma região, o cluster de origem do MSK não exige conectividade privada multi-VPC e o cluster ainda pode ser acessado por outros clientes usando o tipo de autenticação não autenticada.
1. Para replicadores do MSK entre regiões, você deve anexar uma política de permissões baseada em recursos ao cluster de origem. Isso permite que o MSK se conecte a esse cluster para replicar dados. Você pode fazer isso usando os procedimentos da CLI ou AWS do console abaixo. Veja também as [Políticas baseadas em recursos do Amazon MSK](security_iam_service-with-iam.md). Não há necessidade de executar essa etapa para replicadores do MSK na mesma região.
------
#### [ Console: create resource policy ]
Atualize a política de cluster de origem com o seguinte JSON. Substitua o espaço reservado pelo ARN do cluster de origem.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"kafka.amazonaws.com"
]
},
"Action": [
"kafka:CreateVpcConnection",
"kafka:GetBootstrapBrokers",
"kafka:DescribeClusterV2"
],
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ab-cdef-1234567890ab-1"
}
]
}
```
Use a opção **Editar política de cluster** no menu **Ações** na página de detalhes do cluster.
![\[Editar política de cluster no console\]](http://docs.aws.amazon.com/pt_br/msk/latest/developerguide/images/edit-cluster-policy.png)
------
#### [ CLI: create resource policy ]
Observação: se você usar o AWS console para criar um cluster de origem e escolher a opção de criar uma nova função do IAM, AWS anexe a política de confiança necessária à função. Se você quiser que o MSK use um perfil existente do IAM ou se você criar um perfil, anexe as seguintes políticas de confiança a esse perfil para que o replicador do MSK possa assumi-lo. Para obter informações sobre como modificar a relação de confiança de um perfil, consulte [Modificação de um perfil](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage_modify.html).
1. Obtenha a versão atual da política de cluster do MSK usando esse comando. Substitua os espaços reservados pelo ARN efetivo do cluster.
```
aws kafka get-cluster-policy —cluster-arn
{
"CurrentVersion": "K1PA6795UKM GR7",
"Policy": "..."
}
```
1. Crie uma política baseada em recursos para permitir que o replicador do MSK acesse seu cluster de origem. Use a sintaxe a seguir como modelo, substituindo o espaço reservado pelo ARN efetivo do cluster de origem.
```
aws kafka put-cluster-policy --cluster-arn "" --policy '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"kafka.amazonaws.com"
]
},
"Action": [
"kafka:CreateVpcConnection",
"kafka:GetBootstrapBrokers",
"kafka:DescribeClusterV2"
],
"Resource": ""
}
]
```
------
# Preparar o cluster de destino do Amazon MSK
Crie um cluster de destino do MSK (provisionado ou com tecnologia sem servidor) com o controle de acesso do IAM ativado. O cluster de destino não exige que a conectividade privada multi-VPC esteja ativada. O cluster de destino pode estar na mesma AWS região ou em uma região diferente do cluster de origem. Os clusters de origem e de destino devem estar na mesma AWS conta. Seu cluster de destino deve ter, no mínimo, três agentes.
# Tutorial: Criar um Replicador do Amazon MSK
Depois de configurar os clusters de origem e de destino, você pode usá-los para criar um Replicador do Amazon MSK. Antes de criar o replicador do Amazon MSK, certifique-se de ter [Permissões necessárias do IAM para criar um Replicador do MSK](msk-replicator-requirements.md#replicator-role-permissions-successful).
**Contents**
+ [
# Considerações sobre a criação de um Replicador do Amazon MSK
](msk-replicator-requirements.md)
+ [
## Permissões necessárias do IAM para criar um Replicador do MSK
](msk-replicator-requirements.md#replicator-role-permissions-successful)
+ [
# Tipos e versões de clusters compatíveis para o Replicador do MSK
](msk-replicator-supported-clusters-versions.md)
+ [
# Configuração do cluster compatível do MSK Serverless
](msk-replicator-serverless-requirements.md)
+ [
## Alterações na configuração de cluster
](msk-replicator-serverless-requirements.md#msk-replicator-config-changes)
+ [
# Crie um replicador usando o AWS console na região do cluster de destino
](msk-replicator-create-console.md)
+ [
## Escolher seu cluster de origem
](msk-replicator-create-console.md#msk-replicator-create-console-choose-source)
+ [
## Escolher seu cluster de destino
](msk-replicator-create-console.md#msk-replicator-create-console-choose-target)
+ [
## Definir configurações e permissões do replicador
](msk-replicator-create-console.md#msk-replicator-create-settings)
# Considerações sobre a criação de um Replicador do Amazon MSK
As seções a seguir fornecem uma visão geral dos pré-requisitos, das configurações compatíveis e das práticas recomendadas para o uso do recurso Replicador do MSK. Ele abrange as permissões necessárias, a compatibilidade do cluster e os requisitos específicos da tecnologia sem servidor, bem como orientações sobre o gerenciamento do replicador após a criação.
## Permissões necessárias do IAM para criar um Replicador do MSK
Veja um exemplo da política do IAM necessária para criar um replicador do MSK. A ação `kafka:TagResource` só é necessária se as tags forem fornecidas ao criar o replicador do MSK. As políticas do replicador do IAM devem ser anexadas ao perfil do IAM correspondente ao seu cliente. Para obter informações sobre a criação de políticas de autorização, consulte [Criar políticas de autorização](https://docs.aws.amazon.com/msk/latest/developerguide/iam-access-control.html#create-iam-access-control-policies).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "MSKReplicatorIAMPassRole",
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::123456789012:role/MSKReplicationRole",
"Condition": {
"StringEquals": {
"iam:PassedToService": "kafka.amazonaws.com"
}
}
},
{
"Sid": "MSKReplicatorServiceLinkedRole",
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::123456789012:role/aws-service-role/kafka.amazonaws.com/AWSServiceRoleForKafka*"
},
{
"Sid": "MSKReplicatorEC2Actions",
"Effect": "Allow",
"Action": [
"ec2:DescribeSubnets",
"ec2:DescribeSecurityGroups",
"ec2:DescribeVpcs",
"ec2:CreateNetworkInterface"
],
"Resource": [
"arn:aws:ec2:us-east-1:123456789012:subnet/subnet-0abcd1234ef56789",
"arn:aws:ec2:us-east-1:123456789012:security-group/sg-0123abcd4567ef89",
"arn:aws:ec2:us-east-1:123456789012:network-interface/eni-0a1b2c3d4e5f67890",
"arn:aws:ec2:us-east-1:123456789012:vpc/vpc-0a1b2c3d4e5f67890"
]
},
{
"Sid": "MSKReplicatorActions",
"Effect": "Allow",
"Action": [
"kafka:CreateReplicator",
"kafka:TagResource"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-56ef-78gh-90ij-klmnopqrstuv",
"arn:aws:kafka:us-east-1:123456789012:replicator/myReplicator/wxyz9876-54vu-32ts-10rq-ponmlkjihgfe"
]
}
]
}
```
------
Veja a seguir um exemplo de política do IAM para descrever o replicador. É necessário usar a ação `kafka:DescribeReplicator` ou a ação `kafka:ListTagsForResource`, mas não ambas.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"kafka:DescribeReplicator",
"kafka:ListTagsForResource"
],
"Resource": "*"
}
]
}
```
------
# Tipos e versões de clusters compatíveis para o Replicador do MSK
Estes são os requisitos para tipos de instância, versões do Kafka e configurações de rede compatíveis.
+ O replicador do MSK oferece suporte a qualquer combinação de clusters provisionados do MSK e clusters do MSK com tecnologia sem servidor como clusters de origem e destino. No momento, o replicador do MSK não é compatível com outros tipos de clusters do Kafka.
+ Os clusters do MSK com a tecnologia sem servidor exigem controle de acesso do IAM, não oferecem suporte à replicação de ACL do Apache Kafka e têm compatibilidade limitada com a replicação de configuração no tópico. Consulte [O que é o MSK Serverless?](serverless.md).
+ O Replicador do MSK é compatível apenas com clusters que executem o Apache Kafka 2.7.0 ou superior, independentemente de seus clusters de origem e de destino estarem em regiões iguais ou diferentes das Regiões da AWS.
+ O Replicador do MSK é compatível com clusters usando tipos de instância m5.large ou maiores. Não há suporte para clusters t3.small.
+ Se você estiver usando o replicador do MSK com um cluster provisionado pelo MSK, precisará de, no mínimo, três agentes nos clusters de origem e de destino. É possível replicar dados entre clusters em duas zonas de disponibilidade, mas você precisaria de um mínimo de quatro agentes nesses clusters.
+ Os clusters MSK de origem e de destino devem estar na mesma AWS conta. Não há compatibilidade com a replicação entre clusters em contas diferentes.
+ Se os clusters MSK de origem e de destino estiverem em AWS regiões diferentes (entre regiões), o MSK Replicator exigirá que o cluster de origem tenha a conectividade privada de várias VPCs ativada para seu método de controle de acesso IAM.
Não é necessário ter multi-VPC para outros métodos de autenticação no cluster de origem do MSK para replicação em Regiões da AWS.
Também não é necessário ter multi-VPC se você estiver replicando dados entre clusters na mesma região da Região da AWS. Consulte [Conectividade privada multi-VPC do Amazon MSK em uma única região](aws-access-mult-vpc.md).
+ A replicação de nomes de tópicos idênticos (**mantenha o mesmo nome de tópicos** no console) requer um cluster do MSK executando o Kafka versão 2.8.1 ou superior.
+ Para configurações de replicação de nomes de tópicos idênticos (**mantenha o mesmo nome de tópicos** no console), para evitar o risco de replicação cíclica, não faça alterações nos cabeçalhos que o Replicador do MSK cria (`__mskmr`).
# Configuração do cluster compatível do MSK Serverless
+ O MSK Serverless é compatível com a replicação destas configurações de tópicos para clusters de destino do MSK Serverless durante a criação do tópico: `cleanup.policy`, `compression.type`, `max.message.bytes`, `retention.bytes`, `retention.ms`.
+ O MSK Serverless só é compatível com estas configurações de tópicos durante a sincronização da configuração de tópicos: `compression.type`, `max.message.bytes`, `retention.bytes`, `retention.ms`.
+ O replicador usa 83 partições compactadas nos clusters de destino do MSK Serverless. Certifique-se de que os clusters de destino do MSK Serverless tenham um número suficiente de partições compactadas. Consulte [Cota do MSK Serverless](limits.md#serverless-quota).
## Alterações na configuração de cluster
+ Recomenda-se que você não ative ou desative o armazenamento em camadas após a criação do replicador do MSK. Se seu cluster de destino não estiver em camadas, o MSK não copiará as configurações de armazenamento em camadas, independentemente de seu cluster de origem estar ou não com essa configuração. Se você ativar o armazenamento em camadas no cluster de destino após a criação do replicador, será necessário recriar o replicador. Se você quiser copiar dados de um cluster que não esteja em camadas para um cluster em camadas, você não deve copiar as configurações de tópico. Consulte [Habilitar e desabilitar o armazenamento em camadas em um tópico existente](https://docs.aws.amazon.com/msk/latest/developerguide/msk-enable-disable-topic-tiered-storage-cli.html).
+ Não altere as configurações do cluster após a criação do replicador do MSK. As configurações do cluster são validadas durante a criação do replicador do MSK. Para evitar problemas com o replicador do MSK, não altere as configurações a seguir após a criação do replicador do MSK.
+ Altere o cluster do MSK para o tipo de instância t3.
+ Altere as permissões do perfil de execução do serviço.
+ Desabilite a conectividade privada multi-VPC do MSK.
+ Altere a política baseada em recursos anexada do cluster.
+ Altere as regras de grupos de segurança de cluster.
# Crie um replicador usando o AWS console na região do cluster de destino
A seção a seguir explica o fluxo de trabalho do console por etapas para criar um replicador.
**Detalhes do replicador**
1. [Na AWS região em que seu cluster MSK de destino está localizado, abra o console do Amazon MSK em casahttps://console.aws.amazon.com/msk/? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Escolha **Replicadores** para exibir a lista de replicadores na conta.
1. Escolha **Criar replicador**.
1. No painel **Detalhes do replicador**, dê um nome exclusivo ao novo replicador.
## Escolher seu cluster de origem
O cluster de origem contém os dados que você deseja copiar para um cluster de destino do MSK.
1. No painel **Cluster de origem**, escolha a região da AWS do cluster de origem.
Você pode consultar a região de um cluster acessando **Clusters do MSK** e examinando o ARN dos detalhes do **cluster**. O nome da região está incorporado na string do ARN. No exemplo de ARN a seguir, `ap-southeast-2` é a região do cluster.
```
arn:aws:kafka:ap-southeast-2:123456789012:cluster/cluster-11/eec93c7f-4e8b-4baf-89fb-95de01ee639c-s1
```
1. Insira o ARN do seu cluster de origem ou navegue para escolher seu cluster de origem.
1. Escolha uma ou mais sub-redes para seu cluster de origem.
O console exibe as sub-redes disponíveis na região do cluster de origem para você selecionar. Você deve selecionar, no mínimo, duas sub-redes. Para um replicador do MSK na mesma região, as sub-redes que você seleciona para acessar o cluster de origem e as sub-redes para acessar o cluster de destino devem estar na mesma zona de disponibilidade.
1. Escolha grupos de segurança para que o Replicador do MSK acesse o cluster de origem.
+ Para replicação entre regiões (CRR), você não precisa fornecer grupos de segurança para o cluster de origem.
+ Para replicação na mesma região (SRR), acesse o console do Amazon EC2 https://console.aws.amazon.com/ec2/ em e garanta que os grupos de segurança que você fornecerá para o Replicator tenham regras de saída para permitir o tráfego para os grupos de segurança do seu cluster de origem. Além disso, certifique-se de que os grupos de segurança do cluster de origem tenham regras de saída que permitam o tráfego para os grupos de segurança do replicador fornecidos para a origem.
**Para adicionar regras de entrada ao seu grupo de segurança do cluster de origem:**
1. No AWS console, acesse os detalhes do cluster de origem selecionando o **nome do cluster**.
1. Selecione a guia **Propriedades** e, em seguida, role para baixo até o painel **Configurações de rede** para selecionar o nome do **Grupo de segurança** aplicado.
1. Acesse as regras de entrada e selecione **Editar regras de entrada**.
1. Selecione **Adicionar regra**.
1. Na coluna **Tipo** para a nova regra, selecione **TCP personalizado**.
1. Na coluna **Intervalo de portas**, digite `9098`. O Replicador do MSK usa o controle de acesso do IAM para se conectar ao cluster que usa a porta 9098.
1. Na coluna **Origem**, digite o nome do grupo de segurança que você fornecerá durante a criação do replicador para o cluster de origem (pode ser igual ao grupo de segurança do cluster de origem do MSK) e selecione **Salvar regras**.
**Para adicionar regras de saída ao grupo de segurança do replicador fornecido para a origem:**
1. No AWS console do Amazon EC2, acesse o grupo de segurança que você fornecerá durante a criação do Replicator para a fonte.
1. Acesse as regras de saída e selecione **Editar regras de saída**.
1. Selecione **Adicionar regra**.
1. Na coluna **Tipo** para a nova regra, selecione **TCP personalizado**.
1. Na coluna **Intervalo de portas**, digite `9098`. O Replicador do MSK usa o controle de acesso do IAM para se conectar ao cluster que usa a porta 9098.
1. Na coluna **Origem**, digite o nome do grupo de segurança do cluster de origem do MSK e selecione **Salvar regras**.
**nota**
Como alternativa, caso não queira restringir o tráfego usando os grupos de segurança, você poderá adicionar regras de entrada e saída que permitam todo o tráfego.
1. Selecione **Adicionar regra**.
2. Na coluna **Tipo**, escolha **Todo o tráfego**.
3. Na coluna Origem, digite `0.0.0.0/0` e selecione **Salvar regras**.
## Escolher seu cluster de destino
O cluster de destino é o cluster do MSK provisionado ou com tecnologia sem servidor para o qual os dados de origem são copiados.
**nota**
O replicador do MSK cria novos tópicos no cluster de destino com um prefixo gerado automaticamente adicionado ao nome do tópico. Por exemplo, o replicador do MSK replica dados em “`topic`” com base no cluster de origem para um novo tópico chamado `.topic` no cluster de destino. Isso serve para distinguir entre tópicos que contenham dados replicados do cluster de origem de outros tópicos no cluster de destino e para evitar que os dados sejam replicados circularmente entre os clusters. Você pode encontrar o prefixo que será adicionado aos nomes dos tópicos no cluster de destino no campo **sourceKafkaClusterAlias** usando a `DescribeReplicator` API ou a página de **detalhes do Replicator** no console MSK. O prefixo no cluster de destino é ``.
1. No painel **Cluster de destino**, escolha a AWS região em que o cluster de destino está localizado.
1. Insira o ARN do seu cluster de destino ou navegue para escolher seu cluster de destino.
1. Escolha uma ou mais sub-redes para seu cluster de destino.
O console exibe as sub-redes disponíveis na região do cluster de destino para você selecionar. Selecione ao menos duas sub-redes.
1. Escolha grupos de segurança para que o Replicador do MSK acesse o cluster de destino.
Os grupos de segurança disponíveis na região do cluster de destino são exibidos para você selecionar. O grupo de segurança escolhido será associado a cada conexão. Para obter mais informações sobre o uso de grupos de segurança, consulte [Controle o tráfego para seus AWS recursos usando grupos de segurança](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html) no Guia do *usuário da Amazon VPC*.
+ Tanto para replicação entre regiões (CRR) quanto para replicação na mesma região (SRR), acesse o console do Amazon EC2 em [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)e garanta que os grupos de segurança que você fornecerá ao Replicador tenham regras de saída para permitir o tráfego para os grupos de segurança do seu cluster de destino. Além disso, certifique-se de que os grupos de segurança do seu cluster de destino tenham regras de entrada que aceitem o tráfego proveniente dos grupos de segurança do replicador fornecidos para o destino.
**Para adicionar regras de entrada ao grupo de segurança do cluster de destino:**
1. No AWS console, acesse os detalhes do cluster de destino selecionando o **nome do cluster**.
1. Selecione a guia **Propriedades** e, em seguida, role para baixo até o painel Configurações de rede para selecionar o nome do **Grupo de segurança** aplicado.
1. Acesse as regras de entrada e selecione **Editar regras de entrada**.
1. Selecione **Adicionar regra**.
1. Na coluna **Tipo** para a nova regra, selecione **TCP personalizado**.
1. Na coluna **Intervalo de portas**, digite `9098`. O Replicador do MSK usa o controle de acesso do IAM para se conectar ao cluster que usa a porta 9098.
1. Na coluna **Origem**, digite o nome do grupo de segurança que você fornecerá durante a criação do replicador para o cluster de destino (pode ser igual ao grupo de segurança do cluster de destino do MSK) e selecione **Salvar regras**.
**Para adicionar regras de saída ao grupo de segurança do replicador fornecido para o destino:**
1. No AWS console, acesse o grupo de segurança que você fornecerá durante a criação do Replicator para o destino.
1. Selecione a guia **Propriedades** e, em seguida, role para baixo até o painel Configurações de rede para selecionar o nome do **Grupo de segurança** aplicado.
1. Acesse as regras de saída e selecione **Editar regras de saída**.
1. Selecione **Adicionar regra**.
1. Na coluna **Tipo** para a nova regra, selecione **TCP personalizado**.
1. Na coluna **Intervalo de portas**, digite `9098`. O Replicador do MSK usa o controle de acesso do IAM para se conectar ao cluster que usa a porta 9098.
1. Na coluna **Origem**, digite o nome do grupo de segurança do cluster de destino do MSK e selecione **Salvar regras**.
**nota**
Como alternativa, caso não queira restringir o tráfego usando os grupos de segurança, você poderá adicionar regras de entrada e saída que permitam todo o tráfego.
1. Selecione **Adicionar regra**.
2. Na coluna **Tipo**, escolha **Todo o tráfego**.
3. Na coluna Origem, digite `0.0.0.0/0` e selecione **Salvar regras**.
## Definir configurações e permissões do replicador
1. No painel **Configurações do replicador**, especifique os tópicos que deseja replicar usando expressões regulares nas listas de permissão e proibição. Todos os tópicos são replicados por padrão.
**nota**
O Replicador do MSK replica somente até 750 tópicos de forma ordenada. Se você precisar replicar mais tópicos, recomendamos criar um replicador separado. Acesse o Support Center do AWS console e [crie um caso de suporte](https://console.aws.amazon.com/support/home#/) se precisar de suporte para mais de 750 tópicos por replicador. Você pode monitorar o número de tópicos que estão sendo replicados usando a métrica TopicCount "”. Consulte [Cota de agente Standard do Amazon MSK](limits.md#msk-provisioned-quota).
1. Por padrão, o Replicador do MSK inicia a replicação a partir do *último* (mais recente) deslocamento nos tópicos selecionados. Como alternativa, você pode iniciar a replicação a partir do *primeiro* (mais antigo) deslocamento nos tópicos selecionados se quiser replicar os dados existentes em seus tópicos. Depois que o replicador for criado, você não poderá alterar essa configuração. Essa configuração corresponde ao [https://docs.aws.amazon.com/msk/1.0/apireference-replicator/v1-replicators-replicatorarn.html#v1-replicators-replicatorarn-model-replicationstartingposition](https://docs.aws.amazon.com/msk/1.0/apireference-replicator/v1-replicators-replicatorarn.html#v1-replicators-replicatorarn-model-replicationstartingposition)campo na [https://docs.aws.amazon.com/msk/1.0/apireference-replicator/v1-replicators.html#CreateReplicator](https://docs.aws.amazon.com/msk/1.0/apireference-replicator/v1-replicators.html#CreateReplicator)solicitação e na [https://docs.aws.amazon.com/msk/1.0/apireference-replicator/v1-replicators-replicatorarn.html#DescribeReplicator](https://docs.aws.amazon.com/msk/1.0/apireference-replicator/v1-replicators-replicatorarn.html#DescribeReplicator)resposta APIs.
1. Escolha uma configuração de nome de tópico:
+ Replicação do nome do tópico `PREFIXED` (**Adicionar prefixo ao nome dos tópicos** no console): a configuração padrão. O Replicador do MSK replica “topic1” do cluster de origem para um novo tópico no cluster de destino denominado `.topic1`.
+ Replicação de nomes do tópicos idênticos (**mantenha o mesmo nome de tópicos** no console): os tópicos do cluster de origem são replicados com nomes de tópicos idênticos no cluster de destino.
Essa configuração corresponde ao `TopicNameConfiguration` campo na `CreateReplicator` solicitação e na `DescribeReplicator` resposta APIs. Consulte [Funcionamento do replicador do Amazon MSK](msk-replicator-how-it-works.md).
**nota**
Por padrão, o Replicador do MSK cria tópicos no cluster de destino com um prefixo gerado automaticamente adicionado ao nome do tópico. Isso serve para distinguir entre tópicos que contenham dados replicados do cluster de origem de outros tópicos no cluster de destino e para evitar que os dados sejam replicados circularmente entre os clusters. Como alternativa, você pode criar um Replicador do MSK com replicação de nomes de tópicos idênticos (**mantenha o mesmo nome de tópicos** no console) para que os nomes dos tópicos sejam preservados durante a replicação. Essa configuração reduz a necessidade de reconfigurar aplicações cliente durante a configuração e simplifica a operação de arquiteturas de streaming de vários clusters.
1. Por padrão, o MSK Replicator copia todos os metadados, incluindo configurações de tópicos, listas de controle de acesso (ACLs) e compensações de grupos de consumidores para um failover contínuo. Se você não estiver criando o replicador para failover, é possível optar por desativar uma ou mais dessas configurações disponíveis na seção **Configurações adicionais**.
**nota**
O MSK Replicator não replica a gravação, ACLs pois seus produtores não devem escrever diretamente no tópico replicado no cluster de destino. Seus produtores devem gravar no tópico local no cluster de destino após o failover. Para mais detalhes, consulte [Execute um failover planejado para a região secundária AWS](msk-replicator-perform-planned-failover.md).
1. No painel **Replicação do grupo de consumidores**, especifique os grupos de consumidores que deseja replicar usando expressões regulares nas listas de permissão e proibição. Todos os grupos de consumidores são replicados por padrão.
1. No painel **Compactação**, você pode optar opcionalmente por compactar os dados gravados no cluster de destino. Se você for usar a compactação, recomendamos que use o mesmo método de compactação dos dados em seu cluster de origem.
1. No painel **Permissões de acesso**, execute uma das seguintes ações:
1. Selecione **Criar ou atualizar o perfil do IAM com as políticas necessárias**. O console do MSK anexará automaticamente as permissões e a política de confiança necessárias ao perfil de execução do serviço necessário para ler e gravar em seus clusters de origem e destino do MSK.
![\[Console do MSK para criar ou atualizar o perfil do IAM do replicador\]](http://docs.aws.amazon.com/pt_br/msk/latest/developerguide/images/msk-replicator-ezCRC.png)
1. Forneça seu próprio perfil do IAM selecionando **Escolher entre os perfis do IAM que o Amazon MSK pode assumir**. Recomendamos que você anexe a política `AWSMSKReplicatorExecutionRole` gerenciada do IAM ao perfil de execução do serviço, em vez de escrever sua própria política do IAM.
1. Crie o perfil do IAM que o replicador usará para ler e gravar em seus clusters de origem e destino do MSK com o JSON abaixo como parte da política de confiança e o `AWSMSKReplicatorExecutionRole` anexado ao perfil. Na política de confiança, substitua o espaço reservado pelo ID efetivo da sua conta.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "kafka.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": ""
}
}
}
]
}
```
------
1. No painel **Tags do replicador**, você pode, opcionalmente, atribuir tags ao recurso replicador do MSK. Para obter mais informações, consulte [Marcar um cluster do Amazon MSK](msk-tagging.md). Para um replicador do MSK entre regiões, as tags são sincronizadas automaticamente com a região remota quando o replicador é criado. Se você alterar as tags após a criação do replicador, a alteração não será sincronizada automaticamente com a região remota, então você precisará sincronizar manualmente as referências do replicador local e do replicador remoto.
1. Escolha **Criar**.
Se você quiser restringir a permissão `kafka-cluster:WriteData`, consulte a seção *Criar políticas de autorização* de [Como funciona o controle de acesso do IAM para o Amazon MSK](https://docs.aws.amazon.com/msk/latest/developerguide/iam-access-control.html#how-to-use-iam-access-control). Você precisará adicionar a permissão `kafka-cluster:WriteDataIdempotently` ao cluster de origem e de destino.
A criação e transferência do replicador do MSK para o status RUNNING leva aproximadamente 30 minutos.
Se você criar um novo replicador do MSK para substituir um que você excluiu, o novo replicador iniciará a replicação a partir do último deslocamento.
Se o replicador do MSK tiver passado para o status FAILED, consulte a seção [Solução de problemas do replicador do MSK](msk-replicator-troubleshooting.md).
# Editar configurações do replicador do MSK
Você não pode alterar o cluster de origem, o cluster de destino, a posição inicial do replicador ou a configuração de replicação do nome do tópico após o Replicador do MSK ter sido criado. Você precisa criar um novo replicador para usar a configuração de replicação de nomes de tópicos idênticos. No entanto, você pode editar outras configurações do replicador, como tópicos e grupos de consumidores a replicar.
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon MSK em [https://console.aws.amazon.com/msk/casa? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. No painel de navegação esquerdo, escolha **Replicadores** para exibir a lista de replicadores na conta e selecione o Replicador do MSK que deseja editar.
1. Escolha a guia **Properties (Propriedades)**.
1. Na seção **Configurações do replicador**, escolha **Editar replicador**.
1. Você pode editar as configurações do replicador do MSK alterando qualquer uma dessas configurações.
+ Especifique os tópicos que deseja replicar usando expressões regulares nas listas de permissão e proibição. Por padrão, o MSK Replicator copia todos os metadados, incluindo configurações de tópicos, listas de controle de acesso (ACLs) e compensações de grupos de consumidores para um failover contínuo. Se você não estiver criando o replicador para failover, é possível optar por desativar uma ou mais dessas configurações disponíveis na seção **Configurações adicionais**.
**nota**
O MSK Replicator não replica a gravação, ACLs pois seus produtores não devem escrever diretamente no tópico replicado no cluster de destino. Seus produtores devem gravar no tópico local no cluster de destino após o failover. Para mais detalhes, consulte [Execute um failover planejado para a região secundária AWS](msk-replicator-perform-planned-failover.md).
+ Em **Replicação do grupo de consumidores**, é possível especificar os grupos de consumidores que deseja replicar usando expressões regulares nas listas de permissão e proibição. Todos os grupos de consumidores são replicados por padrão. Se as listas de permissão e proibição estiverem vazias, a replicação do grupo de consumidores será desativada.
+ No painel **Tipo de compactação do destino**, você pode optar por compactar ou não os dados gravados no cluster de destino. Se você for usar a compactação, recomendamos que use o mesmo método de compactação dos dados em seu cluster de origem.
1. Salve as alterações.
A criação e transferência do replicador do MSK para o estado em execução leva aproximadamente 30 minutos. Se o replicador do MSK tiver passado para o status FAILED, consulte a seção de solução de problemas [Solucionar problemas do Replicador do MSK](msk-replicator-troubleshooting.md).
# Excluir um replicador do MSK
Talvez seja necessário excluir um replicador do MSK se ele falhar na criação (status FAILED). Os clusters de origem e destino atribuídos a um replicador do MSK não podem ser alterados após a criação do replicador do MSK. Você pode excluir um replicador do MSK existente e criar um novo. Se você criar um novo replicador do MSK para substituir o excluído, o novo replicador iniciará a replicação com base na última compensação.
1. Na AWS região em que seu cluster de origem está localizado, faça login e abra o Console de gerenciamento da AWS console do Amazon MSK em [https://console.aws.amazon.com/msk/casa? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. No painel de navegação, selecione **Replicadores**.
1. Na lista de replicadores do MSK, selecione o que você deseja excluir e escolha **Excluir**.
# Monitorar a replicação
Você pode usar [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)na região do cluster de destino para visualizar métricas de`ReplicationLatency`,`MessageLag`, e `ReplicatorThroughput` em um nível de tópico e agregado para cada Amazon MSK Replicator. As métricas são visíveis abaixo **ReplicatorName**no namespace “AWS/Kafka”. Você também pode ver as métricas `ReplicatorFailure`, `AuthError` e `ThrottleTime` para verificar se há problemas.
O console MSK exibe um subconjunto de CloudWatch métricas para cada replicador MSK. Na lista **Replicadores** do console, selecione o nome de um replicador e selecione a guia **Monitoramento**.
## Métricas de replicador do MSK
As métricas a seguir descrevem as métricas de desempenho ou conexão do replicador do MSK.
AuthError as métricas não abrangem erros de autenticação em nível de tópico. Para monitorar os erros de autenticação em nível de tópico do MSK Replicator, monitore as métricas do Replicator e as ReplicationLatency métricas em nível de tópico do cluster de origem,. MessagesInPerSec Se um tópico ReplicationLatency cair para 0, mas o tópico ainda tiver dados sendo produzidos, isso indica que o replicador tem um problema de autenticação com o tópico. Verifique se o perfil do IAM de execução do serviço do replicador tem permissão suficiente para acessar o tópico.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/msk/latest/developerguide/msk-replicator-monitor.html)
# Usar a replicação para aumentar a resiliência de uma aplicação de streaming do Kafka em todas as regiões
Você pode usar o MSK Replicator para configurar topologias de cluster ativo-ativo ou ativo-passivo para aumentar a resiliência do seu aplicativo Apache Kafka em todas as regiões. AWS Em uma configuração ativa-ativa, os dois clusters do MSK estão atendendo ativamente leituras e gravações. Em uma configuração ativa-passiva, somente um cluster do MSK por vez estará atendendo ativamente dados de streaming, enquanto o outro cluster estará em espera.
## Considerações para criar aplicações do Apache Kafka em várias regiões
Seus consumidores devem ser capazes de reprocessar mensagens duplicadas sem impacto posterior. O MSK Replicator replica dados at-least-once que podem resultar em duplicatas no cluster em espera. Quando você muda para a AWS região secundária, seus consumidores podem processar os mesmos dados mais de uma vez. O replicador do MSK prioriza a cópia de dados em vez das compensações do consumidor para melhorar o desempenho. Após um failover, o consumidor pode começar a ler as compensações anteriores, resultando em processamento duplicado.
Produtores e consumidores também devem tolerar a perda mínima de dados. Como o MSK Replicator replica dados de forma assíncrona, quando a AWS região primária começa a apresentar falhas, não há garantia de que todos os dados sejam replicados para a região secundária. Você pode usar a latência de replicação para determinar o máximo de dados que não foram copiados para a região secundária.
## Uso da topologia ativa-ativa vs. ativa-passiva de cluster
Uma topologia ativa-ativa de cluster oferece quase zero tempo de recuperação e a capacidade de sua aplicação de streaming operar simultaneamente em várias regiões da AWS . Quando um cluster em uma região está comprometido, as aplicações conectadas ao cluster na outra região continuam processando dados.
As configurações ativa-passiva são adequadas para aplicações que podem ser executadas em apenas uma região da AWS por vez ou quando você precisa de mais controle sobre a ordem de processamento de dados. As configurações ativa-passiva exigem mais tempo de recuperação do que as configurações ativa-ativa, pois você deve iniciar toda a configuração ativa-passiva, incluindo seus produtores e consumidores, na região secundária para retomar o streaming de dados após um failover.
# Criar uma configuração ativa-passiva de cluster do Kafka com as configurações de nomenclatura de tópicos recomendadas
Para uma configuração ativa-passiva, recomendamos que você opere uma configuração semelhante de produtores, clusters MSK e consumidores (com o mesmo nome de grupo de consumidores) em duas regiões diferentes. AWS É importante que os dois clusters do MSK tenham capacidade idêntica de leitura e gravação para garantir a replicação confiável dos dados. Você precisa criar um replicador do MSK para copiar continuamente os dados do cluster primário para o cluster em espera. Você também precisa configurar seus produtores para gravar dados em tópicos em um cluster na mesma AWS região.
Para uma configuração ativa-passiva, crie um replicador com replicação de nomes de tópicos idênticos (**mantenha o mesmo nome de tópicos** no console) para começar a replicar dados do cluster do MSK na região primária para o cluster na região secundária. Recomendamos que você opere um conjunto duplicado de produtores e consumidores nas duas AWS regiões, cada um se conectando ao cluster em sua própria região usando sua string de bootstrap. Isso simplifica o processo de failover, pois não exigirá alterações na string de bootstrap. Para garantir que os consumidores leiam próximo de onde pararam, os consumidores nos clusters de origem e de destino devem ter o mesmo ID de grupo de consumidores.
Se você usar a replicação de nomes de tópicos indênticos (**mantenha o mesmo nome de tópicos** no console) para o Replicador do MSK, ele replicará os tópicos com o mesmo nome dos tópicos de origem correspondentes.
Recomendamos que você defina as configurações e permissões no nível de cluster para os clientes no cluster de destino. Você não precisa definir as configurações de nível de tópico e a leitura literal, ACLs pois o MSK Replicator as copia automaticamente se você tiver selecionado a opção de copiar listas de controle de acesso. Consulte [Replicação de metadados](msk-replicator-how-it-works.md#msk-replicator-metadata-replication).
# Failover para a região secundária AWS
Recomendamos que você monitore a latência da replicação na AWS região secundária usando a Amazon. CloudWatch Durante um evento de serviço na AWS região principal, a latência da replicação pode aumentar repentinamente. Se a latência continuar aumentando, use o AWS Service Health Dashboard para verificar se há eventos de serviço na AWS região principal. Se houver um evento, você pode fazer o failover para a AWS região secundária.
# Execute um failover planejado para a região secundária AWS
Você pode realizar um failover planejado para testar a resiliência do seu aplicativo contra um evento inesperado em sua AWS região primária, que tem seu cluster MSK de origem. Um failover planejado não deve resultar em perda de dados.
Se você estiver usando a configuração de replicação de nomes de tópicos idênticos, siga estas etapas:
1. Desligue todos os produtores e consumidores que se conectam ao seu cluster de origem.
1. Crie um Replicador do MSK para replicar dados do cluster do MSK na região secundária para o cluster do MSK na região primári com replicação de nomes de tópicos idênticos (**mantenha o mesmo nome de tópicos** no console). Isso é necessário para copiar os dados que você gravará na região secundária de volta para a região primária, para que você possa fazer failback para a região primária após o término do evento inesperado.
1. Inicie produtores e consumidores conectados ao cluster de destino na AWS região secundária.
Se você estiver usando a configuração de nomes de tópicos prefixados, siga estas etapas para fazer o failover:
1. Desligue todos os produtores e consumidores que se conectam ao seu cluster de origem.
1. Crie um novo replicador do MSK para replicar dados do seu cluster do MSK na região secundária para o seu cluster do MSK na região primária. Isso é necessário para copiar os dados que você gravará na região secundária de volta para a região primária, para que você possa fazer failback para a região primária após o término do evento inesperado.
1. Inicie os produtores no cluster de destino na AWS região secundária.
1. Dependendo dos requisitos de ordenação de mensagens da aplicação, siga as etapas em uma das guias a seguir.
------
#### [ No message ordering ]
Se seu aplicativo não exigir a ordenação de mensagens, inicie consumidores na AWS região secundária que leiam os tópicos locais (por exemplo, tópico) e replicados (por exemplo,`.topic`) usando um operador curinga (por exemplo,). `.*topic`
------
#### [ Message ordering ]
Se sua aplicação exigir a ordenação de mensagens, inicie os consumidores somente para os tópicos replicados no cluster de destino (p. ex., `.topic`), mas não para os tópicos locais (p. ex., `topic`).
------
1. Aguarde até que todos os consumidores de tópicos replicados no cluster de destino do MSK concluam o processamento de todos os dados, para que o atraso do consumidor seja 0 e o número de registros processados também seja 0. Em seguida, interrompa os consumidores dos tópicos replicados no cluster de destino. Nesse ponto, todos os registros que foram replicados do cluster do MSK de origem para o cluster do MSK de destino foram consumidos.
1. Inicie consumidores para os tópicos locais (p. ex., `topic`) no cluster de destino do MSK.
# Execute um failover não planejado para a região secundária AWS
Você pode realizar um failover não planejado quando há um evento de serviço na AWS região primária que tem seu cluster MSK de origem e você deseja redirecionar temporariamente seu tráfego para a região secundária que tem seu cluster MSK de destino. Um failover não planejado pode resultar na perda de alguns dados, pois o Replicador do MSK replica dados de modo assíncrono. Você pode monitorar o atraso da mensagem usando as métricas em [Monitorar a replicação](msk-replicator-monitor.md).
Se você estiver usando uma configuração de replicação de nomes de tópicos idênticos (**mantenha o mesmo nome de tópicos** no console), siga estas etapas:
1. Tente desligar todos os produtores e consumidores que se conectam ao cluster de origem do MSK na região primária. Essa operação pode não ter êxito devido a deficiências na região.
1. Faça com que produtores e consumidores se conectem ao cluster MSK de destino na AWS região secundária para concluir o failover. Como o MSK Replicator também replica metadados, incluindo compensações de leitura ACLs e de grupos de consumidores, seus produtores e consumidores retomarão o processamento sem problemas de onde pararam antes do failover.
Se você estiver usando a configuração de nomes de tópicos `PREFIX`, siga estas etapas para fazer o failover:
1. Tente desligar todos os produtores e consumidores que se conectam ao cluster de origem do MSK na região primária. Essa operação pode não ter êxito devido a deficiências na região.
1. Faça com que produtores e consumidores se conectem ao cluster MSK de destino na AWS região secundária para concluir o failover. Como o MSK Replicator também replica metadados, incluindo compensações de leitura ACLs e de grupos de consumidores, seus produtores e consumidores retomarão o processamento sem problemas de onde pararam antes do failover.
1. Dependendo dos requisitos de ordenação de mensagens da aplicação, siga as etapas em uma das guias a seguir.
------
#### [ No message ordering ]
Se seu aplicativo não exigir a ordenação de mensagens, inicie consumidores na AWS região de destino que leiam os tópicos locais (por exemplo`topic`) e replicados (por exemplo,`.topic`) usando um operador curinga (por exemplo,). `.*topic`
------
#### [ Message ordering ]
1. Inicie os consumidores somente para os tópicos replicados no cluster de destino (p. ex., `.topic`), mas não para os tópicos locais (p. ex., `topic`).
1. Aguarde até que todos os consumidores de tópicos replicados no cluster de destino do MSK concluam o processamento de todos os dados, para que o atraso do deslocamento seja 0 e o número de registros processados também seja 0. Em seguida, interrompa os consumidores dos tópicos replicados no cluster de destino. Nesse ponto, todos os registros que foram replicados do cluster do MSK de origem para o cluster do MSK de destino foram consumidos.
1. Inicie consumidores para os tópicos locais (p. ex., `topic`) no cluster de destino do MSK.
------
1. Depois que o evento de serviço terminar na região primária, crie um Replicador do MSK para replicar dados do cluster do MSK na região secundária para o cluster do MSK na região primária com a posição de início do replicador definida para *mais antigo*. Isso é necessário para copiar os dados que você gravará na região secundária de volta para a região primária, para que você possa fazer failback para a região primária após o término do evento de serviço. Se você não definir a posição de início do replicador como o *mais antigo*, todos os dados produzidos para o cluster na região secundária durante o evento de serviço na região primária não serão copiados de volta para o cluster na região primária.
# Execute o failback para a região primária AWS
Você pode retornar à AWS região primária após o término do evento de serviço nessa região.
Se você estiver usando a configuração de replicação de nomes de tópicos idênticos, siga estas etapas:
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 iniciará o processo de cópia de 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 métrica `MaxOffsetLag` 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 “RUNNING” e a `ReplicatorThroughput` métrica na Amazon CloudWatch `0`.
Observe que quando você cria um novo replicador com a posição de início como *Mais antigo* para failback, ele começa a ler todos os dados nos tópicos dos clusters secundários. 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`. Consulte [Métricas de replicador do MSK](msk-replicator-monitor.md#msk-replicator-metrics).
Se você estiver usando a configuração de nomes de tópicos prefixados, siga estas etapas:
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. Dependendo dos requisitos de ordenação de mensagens da aplicação, siga as etapas em uma das guias a seguir.
------
#### [ No message ordering ]
Se seu aplicativo não exigir a ordenação de mensagens, inicie consumidores na AWS região primária que leiam os tópicos locais (por exemplo,`topic`) e replicados (por exemplo,`.topic`) usando um operador curinga (por exemplo,). `.*topic` Os consumidores de tópicos locais (p. ex., tópico) retomarão com base no último deslocamento que consumiram antes do failover. Se houver algum dado não processado antes do failover, ele será processado agora. No caso de um failover planejado, esse registro não deverá existir.
------
#### [ Message ordering ]
1. Inicie os consumidores somente para os tópicos replicados na região primária (p. ex., `.topic`), mas não para os tópicos locais (p. ex., `topic`).
1. Aguarde até que todos os consumidores de tópicos replicados na região primária do cluster concluam o processamento de todos os dados, para que o atraso do deslocamento seja 0 e o número de registros processados também seja 0. Em seguida, interrompa os consumidores dos tópicos replicados no cluster na região primária. Nesse ponto, todos os registros que foram produzidos na região secundária após o failover terão sido consumidos na região primária.
1. Inicie consumidores para os tópicos locais (p. ex., `topic`) no cluster na região primária.
------
1. Verifique se o replicador existente do cluster na região primária para o cluster na região secundária está no estado EM EXECUÇÃO e funcionando conforme o esperado usando as métricas de latência e `ReplicatorThroughput`.
# Criar uma configuração ativa-ativa usando o Replicador do MSK
Caso queira criar uma configuração ativa-ativa em que os dois clusters do MSK estejam servindo ativamente leituras e gravações, recomendamos que você use um Replicador do MSK com replicação de nomes de tópicos prefixados (**Adicionar prefixo ao nome de tópicos** no console). No entanto, isso exigirá que você reconfigure os consumidores para ler os tópicos replicados.
Siga estas etapas para configurar a topologia ativa-ativa entre o cluster A de origem do MSK e o cluster B de destino do MSK.
1. Crie um replicador do MSK com o cluster A do MSK como origem e o cluster B do MSK como destino.
1. Depois que o replicador do MSK acima for criado com sucesso, crie um replicador com o cluster B como origem e o cluster A como destino.
1. Crie dois conjuntos de produtores, cada um gravando dados ao mesmo tempo no tópico local (p. ex., “topic”) no cluster na mesma região do produtor.
1. Crie dois conjuntos de consumidores, cada um lendo dados usando uma assinatura curinga (como”. \$1tópico”) do cluster MSK na mesma AWS região do consumidor. Dessa forma, seus consumidores lerão automaticamente os dados produzidos localmente na região com base no tópico local (p. ex., `topic`), bem como os dados replicados de outra região no tópico com o prefixo`.topic`. Esses dois conjuntos de consumidores devem ter grupos de consumidores diferentes IDs para que as compensações do grupo de consumidores não sejam sobrescritas quando o MSK Replicator as copia para o outro cluster.
Se quiser evitar a reconfiguração dos clientes, em vez da replicação do nome de tópicos prefixados (**Adicionar prefixo ao nome de tópicos** no console), você pode criar os Replicadores do MSK usando a replicação de nomes de tópicos (**mantenha o mesmo nome de tópicos** no console) para criar uma configuração ativa-ativa. No entanto, você pagará taxas adicionais de processamento e transferência de dados para cada replicador. Isso ocorre porque cada replicador precisará processar o dobro da quantidade normal de dados: uma vez para a replicação e outra para evitar loops infinitos. Você pode rastrear a quantidade total de dados processados por cada replicador usando a métrica `ReplicatorBytesInPerSec`. Consulte [Monitorar a replicação](msk-replicator-monitor.md). Essa métrica inclui os dados replicados para o cluster de destino, bem como os dados filtrados pelo Replicador do MSK para evitar que os dados sejam copiados de volta para o mesmo tópico de origem.
**nota**
Se você estiver usando a replicação de nomes de tópicos idênticos (**mantenha o mesmo nome de tópicos** no console) para configurar a topologia ativa-ativa, aguarde pelo menos 30 segundos após excluir um tópico antes de recriar outro tópico com o mesmo nome. Esse período de espera ajuda a evitar que mensagens duplicadas sejam replicadas de volta para o cluster de origem. Seus consumidores devem ser capazes de reprocessar mensagens duplicadas sem impacto posterior. Consulte [Considerações para criar aplicações do Apache Kafka em várias regiões](msk-replicator-increase-resiliency.md#msk-replication-multi-region-kafka-applications).
# Migrar um cluster do Amazon MSK para outro usando o Replicador do MSK
Você pode usar a replicação de nomes de tópicos idênticos para a migração de clusters, mas os consumidores devem ser capazes de lidar com mensagens duplicadas sem um impacto downstream. Isso ocorre porque o MSK Replicator fornece at-least-once replicação, o que pode levar à duplicação de mensagens em cenários raros. Se os consumidores atenderem a esse requisito, siga estas etapas.
1. Crie um replicador que replique dados do cluster antigo para o novo cluster com a posição de início do replicador definida como *Mais antigo* e usando a replicação de nomes de tópicos idênticos (**mantenha o mesmo nome de tópicos** no console).
1. Defina as configurações e permissões no nível de cluster no novo cluster. Você não precisa definir configurações em nível de tópico e leitura “literal”, pois o MSK Replicator ACLs as copia automaticamente.
1. Monitore a `MessageLag` métrica na Amazon CloudWatch até chegar a 0, o que indica que todos os dados foram replicados.
1. Depois que todos os dados tiverem sido replicados, impeça que os produtores gravem dados no cluster antigo.
1. Reconfigure esses produtores para se conectarem ao novo cluster e iniciá-los.
1. Monitore a métrica `MaxOffsetLag` dos consumidores lendo dados do cluster antigo até que eles cheguem a `0`, o que indica que todos os dados existentes foram processados.
1. Interrompa os consumidores que estão se conectando ao cluster antigo.
1. Reconfigure os consumidores para se conectarem ao novo cluster e iniciá-los.
# Migre do autogerenciado MirrorMaker 2 para o MSK Replicator
Para migrar de MirrorMaker (MM2) para o MSK Replicator, siga estas etapas:
1. Interrompa o produtor que está gravando no cluster do Amazon MSK de origem.
1. Permita MM2 replicar todas as mensagens nos tópicos dos seus clusters de origem. Você pode monitorar o atraso do consumidor em relação MM2 ao consumidor em seu cluster MSK de origem para determinar quando todos os dados foram replicados.
1. Crie um novo replicador com a posição de início definida como *Mais recente* e a configuração dos nomes de tópicos definida como `IDENTICAL` (**replicação dos mesmos nomes de tópicos** no console).
1. Quando o replicador estiver no estado EM EXECUÇÃO, você poderá reiniciar a gravação dos produtores no cluster de origem.
# Solucionar problemas do Replicador do MSK
As informações a seguir podem ajudar você a solucionar problemas que você pode vir a enfrentar com o replicador do MSK. Consulte [Solução de problemas para o cluster do Amazon MSK](troubleshooting.md) para obter informações sobre a solução de problemas para outros recursos do Amazon MSK. Você também pode publicar seu problema no [AWS re:Post](https://repost.aws/).
## O estado do replicador do MSK vai de CREATING para FAILED
Aqui estão algumas causas comuns de falha na criação do replicador do MSK.
1. Verifique se os grupos de segurança que você forneceu para a criação do replicador na seção do cluster de destino têm regras de saída para permitir o tráfego para os grupos de segurança do seu cluster de destino. Além disso, verifique se os grupos de segurança do seu cluster de destino têm regras de entrada que aceitem o tráfego proveniente dos grupos de segurança fornecidos para a criação do replicador na seção do cluster de destino. Consulte [Escolher seu cluster de destino](msk-replicator-create-console.md#msk-replicator-create-console-choose-target).
1. Se você estiver criando o replicador para replicação entre regiões, verifique se o cluster de origem tem conectividade multi-VPC ativada para o método de autenticação IAM Access Control. Consulte [Conectividade privada multi-VPC do Amazon MSK em uma única região](aws-access-mult-vpc.md). Verifique também se a política de cluster está configurada no cluster de origem para que o replicador do MSK possa se conectar ao cluster de origem. Consulte [Preparar o cluster de origem do Amazon MSK](msk-replicator-prepare-cluster.md).
1. Verifique se a perfil do IAM que você forneceu durante a criação do replicador do MSK tem as permissões necessárias para ler e gravar nos clusters de origem e destino. Além disso, verifique se a perfil do IAM tem permissões para gravar em tópicos. Consulte [Definir configurações e permissões do replicador](msk-replicator-create-console.md#msk-replicator-create-settings)
1. Verifique se sua rede não ACLs está bloqueando a conexão entre o MSK Replicator e seus clusters de origem e destino.
1. É possível que os clusters de origem ou de destino não estivessem totalmente disponíveis quando o replicador do MSK tentou se conectar a eles. Isso pode decorrer de níveis excessivos de carga, uso do disco ou da CPU, o que faz com que o replicador não consiga se conectar aos agentes. Corrija o problema com os agentes e repita a criação do replicador.
Após realizar as validações acima, crie o replicador do MSK novamente.
## O replicador do MSK parece preso no estado CREATING
Às vezes a criação do replicador do MSK pode levar até 30 minutos. Aguarde 30 minutos e verifique o estado do replicador novamente.
## O replicador do MSK não está replicando dados ou replicando apenas dados parciais
Siga estas etapas para solucionar problemas de replicação de dados.
1. Verifique se seu replicador não está enfrentando nenhum erro de autenticação usando a AuthError métrica fornecida pelo MSK Replicator na Amazon. CloudWatch Se essa métrica estiver acima de 0, verifique se a política do perfil do IAM que você forneceu para o replicador é válida e se não há recusa de permissões definidas para as permissões do cluster. Com base na dimensão ClusterAlias, você pode identificar se o cluster de origem ou de destino está apresentando erros de autenticação.
1. Verifique se seus clusters de origem e destino não estão enfrentando problemas. É possível que o replicador não consiga se conectar ao seu cluster de origem ou de destino. Isso pode acontecer devido a muitas conexões, disco com capacidade total ou alto uso da CPU.
1. Verifique se seus clusters de origem e destino podem ser acessados pelo MSK Replicator usando a métrica KafkaClusterPingSuccessCount na Amazon. CloudWatch Com base na dimensão ClusterAlias, você pode identificar se o cluster de origem ou de destino está apresentando erros de autenticação. Se essa métrica for 0 ou não tiver ponto de dados, a conexão não está íntegra. Você deve verificar as permissões de rede e do perfil do IAM que o replicador do MSK está usando para se conectar aos seus clusters.
1. Verifique se seu replicador não está enfrentando falhas devido à falta de permissões em nível de tópico usando a métrica ReplicatorFailure na Amazon. CloudWatch Se essa métrica estiver acima de 0, verifique o perfil do IAM que você forneceu para obter permissões no nível de tópico.
1. Verifique se a expressão regular que você forneceu na lista de permissões ao criar o replicador corresponde aos nomes dos tópicos que você deseja replicar. Além disso, verifique se os tópicos não estão sendo excluídos da replicação devido a uma expressão regular na lista de proibição.
1. Observe que pode levar até 30 segundos para que o replicador detecte e crie os novos tópicos ou partições de tópicos no cluster de destino. Qualquer mensagem produzida no tópico de origem antes da criação do tópico no cluster de destino não será replicada se a posição de início do replicador for a mais recente (padrão). Como alternativa, você poderá iniciar a replicação a partir do primeiro deslocamento nas partições de tópicos do cluster de origem se quiser replicar as mensagens existentes nos tópicos no cluster de destino. Consulte [Definir configurações e permissões do replicador](msk-replicator-create-console.md#msk-replicator-create-settings).
## Deslocamentos de mensagens no cluster de destino são diferentes do cluster de origem
Como parte da replicação de dados, o Replicador do MSK consome mensagens do cluster de origem e as produz para o cluster de destino. Isso pode levar as mensagens a terem deslocamentos diferentes nos clusters de origem e de destino. No entanto, se você ativou a sincronização de deslocamentos de grupos de consumidores durante a criação do replicador, o Replicador do MSK converterá automaticamente os deslocamentos enquanto copia os metadados para que, após o failover para o cluster de destino, os consumidores possam retomar o processamento próximo de onde pararam no cluster de origem.
## O Replicador do MSK não está sincronizando deslocamentos de grupos de consumidores ou o grupo de consumidores não existe no cluster de destino
Siga estas etapas para solucionar problemas de replicação de metadados.
1. Verifique se a replicação de dados está funcionando conforme esperado. Se não, consulte [O replicador do MSK não está replicando dados ou replicando apenas dados parciais](#msk-replicator-troubleshooting-not-replicating).
1. Verifique se a expressão regular que você forneceu na lista de permissões ao criar o replicador corresponde aos nomes dos grupos de consumidores que você deseja replicar. Além disso, verifique se os grupos de consumidores não estão sendo excluídos da replicação devido a uma expressão regular na lista de proibições.
1. Verifique se o Replicador do MSK criou o tópico no cluster de destino. Pode levar até 30 segundos para que o replicador detecte e crie os novos tópicos ou partições de tópicos no cluster de destino. Qualquer mensagem produzida no tópico de origem antes da criação do tópico no cluster de destino não será replicada se a posição de início do replicador for a *mais recente* (padrão). Se o grupo de consumidores no cluster de origem tiver consumido somente as mensagens que não foram replicadas pelo Replicador do MSK, o grupo de consumidores não será replicado para o cluster de destino. Depois que o tópico for criado com sucesso no cluster de destino, o Replicador do MSK começará a replicar mensagens recém-gravadas no cluster de origem para o destino. Quando o grupo de consumidores começar a ler essas mensagens da origem, o Replicador do MSK replicará automaticamente o grupo de consumidores para o cluster de destino. Como alternativa, você poderá iniciar a replicação a partir do primeiro deslocamento nas partições de tópicos do cluster de origem se quiser replicar as mensagens existentes nos tópicos no cluster de destino. Consulte [Definir configurações e permissões do replicador](msk-replicator-create-console.md#msk-replicator-create-settings).
**nota**
O Replicador do MSK otimiza a sincronização do deslocamento de grupos de consumidores para os consumidores no cluster de origem, que estão lendo de uma posição mais próxima ao final da partição do tópico. Se os grupos de consumidores estiverem em atraso no cluster de origem, você poderá observar um atraso maior para esses grupos de consumidores no destino em comparação com a origem. Isso significa que, após o failover para o cluster de destino, os consumidores reprocessarão mais mensagens duplicadas. Para reduzir esse atraso, os consumidores no cluster de origem precisariam se atualizar e começar a consumir a partir da ponta do stream (final da partição do tópico). À medida que os consumidores se atualizarem, o Replicador do MSK reduzirá automaticamente o atraso.
## A latência de replicação é alta ou continua aumentando
Aqui estão algumas causas comuns da alta latência de replicação.
1. Verifique se você tem o número certo de partições nos clusters de origem e destino do MSK. Ter poucas ou muitas partições pode afetar o desempenho. Para obter orientação sobre como escolher o número de partições, consulte [Práticas recomendadas para usar o replicador do MSK](msk-replicator-best-practices.md). A tabela a seguir mostra o número mínimo recomendado de partições para obter o throughput desejado com o replicador do MSK.
**Throughput e número mínimo recomendado de partições**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/msk/latest/developerguide/msk-replicator-troubleshooting.html)
1. Verifique se você tem capacidade suficiente de leitura e gravação em seus clusters de origem e destino do MSK para atender o tráfego de replicação. O replicador do MSK atua como consumidor do cluster de origem (saída) e como produtor do cluster de destino (entrada). Portanto, você deve provisionar a capacidade do cluster para atender ao tráfego de replicação, além de outros tráfegos em seus clusters. Consulte [Práticas recomendadas para usar o replicador do MSK](msk-replicator-best-practices.md) para obter orientação sobre como dimensionar seus clusters do MSK.
1. A latência de replicação pode variar para clusters MSK em diferentes pares de AWS regiões de origem e destino, dependendo da distância geográfica entre os clusters. Por exemplo, a latência de replicação geralmente é menor ao replicar entre clusters nas regiões da Europa (Irlanda) e Europa (Londres) em comparação com a replicação entre clusters nas regiões da Europa (Irlanda) e Ásia-Pacífico (Sydney).
1. Verifique se o replicador não está sendo submetido ao controle de utilização devido às cotas excessivamente agressivas definidas em seus clusters de origem ou de destino. Você pode usar a ThrottleTime métrica fornecida pelo MSK Replicator na Amazon CloudWatch para ver o tempo médio em milissegundos em que uma solicitação foi limitada pelos corretores em seu cluster. source/target Se essa métrica estiver acima de 0, você deve ajustar as cotas do Kafka para reduzir o controle de utilização de modo que o replicador possa se atualizar. Consulte [Como gerenciar o throughput do replicador do MSK usando cotas do Kafka](msk-replicator-best-practices.md#msk-replicator-manage-throughput-kafka-quotas) para obter informações sobre o gerenciamento de cotas do Kafka para o replicador.
1. ReplicationLatency e MessageLag pode aumentar quando uma AWS região se degrada. Use o [AWS Service Health Dashboard](https://health.aws.amazon.com/health/status) para verificar se há um evento de serviço do MSK na região do seu cluster primário do MSK. Se houver um evento de serviço, você poderá redirecionar temporariamente as leituras e gravações da aplicação para a outra região.
## Solução de problemas de falhas do MSK Replicator usando métricas ReplicatorFailure
A ReplicatorFailure métrica ajuda você a monitorar e detectar problemas de replicação no MSK Replicator. Um valor diferente de zero nessa métrica normalmente indica um problema de falha na replicação, que pode ser resultado dos seguintes fatores:
+ limitações do tamanho de mensagem
+ violações da faixa de data e hora
+ problemas no tamanho de lote do log
Se a ReplicatorFailure métrica relatar um valor diferente de zero, siga estas etapas para solucionar o problema.
**nota**
Para obter mais informações sobre essa métrica, consulte [Métricas de replicador do MSK](msk-replicator-monitor.md#msk-replicator-metrics).
1. Configure um cliente que consiga se conectar ao cluster de destino do MSK e tenha as ferramentas de CLI configuradas do Apache Kafka. Para obter informações sobre como configurar o cliente e a ferramenta CLI do Kafka, consulte [Conectar-se a um cluster do Amazon MSK Provisioned](client-access.md).
1. Abra o console Amazon MSK em [https://console.aws.amazon.com/msk/casa? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
Faça o seguinte:
1. Obtenha o ARNs MSK Replicator e o cluster MSK de destino.
1. [Obtenha os endpoints do agente](get-bootstrap-console.md) do cluster de destino do MSK. Você usará esses endpoints nas etapas a seguir.
1. Execute os comandos a seguir para exportar o ARN do Replicador do MSK e os endpoints de agentes que você obteve na etapa anterior.
Certifique-se de substituir os valores de espaço reservado para < *ReplicatorARN* >, < *BootstrapServerString* > e < *ConsumerConfigFile* > usados nos exemplos a seguir por seus valores reais.
```
export TARGET_CLUSTER_SERVER_STRING=
```
```
export REPLICATOR_ARN=
```
```
export CONSUMER_CONFIG_FILE=
```
1. No seu diretório de `/bin`, faça o seguinte:
1. Salve e nomeie o script **query-replicator-failure-message.sh** a seguir.
```
#!/bin/bash
# Script: Query MSK Replicator Failure Message
# Description: This script queries exceptions from AWS MSK Replicator status topics
# It takes a replicator ARN and bootstrap server as input and searches for replicator exceptions
# in the replicator's status topic, formatting and displaying them in a readable manner
#
# Required Arguments:
# --replicator-arn: The ARN of the AWS MSK Replicator
# --bootstrap-server: The Kafka bootstrap server to connect to
# --consumer.config: Consumer config properties file
# Usage Example:
# ./query-replicator-failure-message.sh ./query-replicator-failure-message.sh --replicator-arn --bootstrap-server --consumer.config
print_usage() {
echo "USAGE: $0 ./query-replicator-failure-message.sh --replicator-arn --bootstrap-server --consumer.config "
echo "--replicator-arn REQUIRED: The ARN of AWS MSK Replicator."
echo "--bootstrap-server REQUIRED: The Kafka server to connect to."
echo "--consumer.config REQUIRED: Consumer config properties file."
exit 1
}
# Initialize variables
replicator_arn=""
bootstrap_server=""
consumer_config=""
# Parse arguments
while [[ $# -gt 0 ]]; do
case "$1" in
--replicator-arn)
if [ -z "$2" ]; then
echo "Error: --replicator-arn requires an argument."
print_usage
fi
replicator_arn="$2"; shift 2 ;;
--bootstrap-server)
if [ -z "$2" ]; then
echo "Error: --bootstrap-server requires an argument."
print_usage
fi
bootstrap_server="$2"; shift 2 ;;
--consumer.config)
if [ -z "$2" ]; then
echo "Error: --consumer.config requires an argument."
print_usage
fi
consumer_config="$2"; shift 2 ;;
*) echo "Unknown option: $1"; print_usage ;;
esac
done
# Check for required arguments
if [ -z "$replicator_arn" ] || [ -z "$bootstrap_server" ] || [ -z "$consumer_config" ]; then
echo "Error: --replicator-arn, --bootstrap-server, and --consumer.config are required."
print_usage
fi
# Extract replicator name and suffix from ARN
replicator_arn_suffix=$(echo "$replicator_arn" | awk -F'/' '{print $NF}')
replicator_name=$(echo "$replicator_arn" | awk -F'/' '{print $(NF-1)}')
echo "Replicator name: $replicator_name"
# List topics and find the status topic
topics=$(./kafka-topics.sh --command-config client.properties --list --bootstrap-server "$bootstrap_server")
status_topic_name="__amazon_msk_replicator_status_${replicator_name}_${replicator_arn_suffix}"
# Check if the status topic exists
if echo "$topics" | grep -Fq "$status_topic_name"; then
echo "Found replicator status topic: '$status_topic_name'"
./kafka-console-consumer.sh --bootstrap-server "$bootstrap_server" --consumer.config "$consumer_config" --topic "$status_topic_name" --from-beginning | stdbuf -oL grep "Exception" | stdbuf -oL sed -n 's/.*Exception:\(.*\) Topic: \([^,]*\), Partition: \([^\]*\).*/ReplicatorException:\1 Topic: \2, Partition: \3/p'
else
echo "No topic matching the pattern '$status_topic_name' found."
fi
```
1. Execute esse script para consultar as mensagens de falha do Replicador do MSK.
```
/bin/query-replicator-failure-message.sh --replicator-arn $REPLICATOR_ARN --bootstrap-server $TARGET_CLUSTER_SERVER_STRING --consumer.config $CONSUMER_CONFIG_FILE
```
Esse script gera todos os erros com suas mensagens de exceção e partições de tópicos afetadas. Você pode usar essas informações sobre exceções para mitigar as falhas, como descrito em [Falhas comuns do Replicador do MSK e suas soluções](#msk-replicator-ReplicatorFailure-error-mitigation). Como o tópico contém todos os históricos de falhas das mensagens, inicie a investigação usando a última mensagem. Veja a seguir um exemplo de uma mensagem de falha.
```
ReplicatorException: The request included a message larger than the max message size the server will accept. Topic: test, Partition: 1
```
### Falhas comuns do Replicador do MSK e suas soluções
A lista a seguir descreve algumas das falhas do Replicador do MSK que você pode enfrentar e como mitigá-las.
**Tamanho da mensagem maior que max.request.size**
**Causa**
Essa falha ocorre quando o Replicador do MSK não consegue replicar os dados porque o tamanho da mensagem individual excede 10 MB. Por padrão, o Replicador do MSK replica mensagens de até 10 MB de tamanho.
A seguir está um exemplo deste tipo de mensagem de falha.
```
ReplicatorException: The message is 20635370 bytes when serialized which is larger than 10485760, which is the value of the max.request.size configuration. Topic: test, Partition: 1
```
**Solução**
Reduza os tamanhos das mensagens individuais em seu tópico. Se você não conseguir fazer isso, siga estas instruções para [solicitar um aumento de limite](limits.md#request-msk-quota-increase).
**Tamanho de mensagem maior que o tamanho de mensagem máximo que o servidor aceitará**
**Causa**
Essa falha ocorre quando o tamanho da mensagem excede o tamanho de mensagem máximo do cluster de destino.
A seguir está um exemplo deste tipo de mensagem de falha.
```
ReplicatorException: The request included a message larger than the max message size the server will accept. Topic: test, Partition: 1
```
**Solução**
Aumente a configuração `max.message.bytes` no cluster de destino ou no tópico correspondente do cluster de destino. Defina a configuração `max.message.bytes` do cluster de destino para corresponder ao maior tamanho de mensagem não compactada. Para obter informações a respeito, consulte [max.message.bytes](https://kafka.apache.org/documentation/#topicconfigs_max.message.bytes).
**O carimbo de data/hora está fora do intervalo**
**Causa**
Essa falha ocorre porque o carimbo de data/hora da mensagem individual está fora do intervalo permitido do cluster de destino.
A seguir está um exemplo deste tipo de mensagem de falha.
```
ReplicatorException: Timestamp 1730137653724 of message with offset 0 is out of range. The timestamp should be within [1730137892239, 1731347492239] Topic: test, Partition: 1
```
**Solução**
Atualize a configuração `message.timestamp.before.max.ms` do cluster de destino para permitir mensagens com carimbos de data/hora mais antigos. Para obter informações a respeito, consulte [message.timestamp.before.max.ms](https://kafka.apache.org/documentation/#topicconfigs_message.timestamp.before.max.ms).
**Registrar lote muito grande**
**Causa**
Essa falha ocorre porque o tamanho do lote de registros excede o tamanho de segmento definido para o tópico no cluster de destino. O Replicador do MSK é compatível com um tamanho máximo de lote de 1 MB.
A seguir está um exemplo deste tipo de mensagem de falha.
```
ReplicatorException: The request included message batch larger than the configured segment size on the server. Topic: test, Partition: 1
```
**Solução**
A configuração segment.bytes do cluster de destino deve ser pelo menos tão grande quanto o tamanho do lote (1 MB) para que o Replicador continue sem erros. Atualize segment.bytes do cluster de destino para ter pelo menos 1048576 (1 MB). Para obter informações a respeito, consulte [segment.bytes](https://kafka.apache.org/documentation/#topicconfigs_segment.bytes).
**nota**
Se a ReplicatorFailure métrica continuar emitindo valores diferentes de zero após a aplicação dessas soluções, repita o processo de solução de problemas até que a métrica emita um valor zero.
# Práticas recomendadas para usar o replicador do MSK
Esta seção aborda práticas recomendadas e estratégias de implementação comuns para usar o Replicador do Amazon MSK.
**Contents**
+ [
## Como gerenciar o throughput do replicador do MSK usando cotas do Kafka
](#msk-replicator-manage-throughput-kafka-quotas)
+ [
## Definir o período de retenção do cluster
](#msk-replicator-retention-period)
## Como gerenciar o throughput do replicador do MSK usando cotas do Kafka
Como o replicador do MSK atua como consumidor do seu cluster de origem, a replicação pode fazer com que outros consumidores passem por controle de utilização em seu cluster de origem. A quantidade de controle de utilização depende da capacidade de leitura que você tem no cluster de origem e do throughput dos dados que você está replicando. Recomendamos que você provisione capacidade idêntica para seus clusters de origem e de destino e leve em conta o throughput de replicação ao calcular a capacidade necessária.
Você também pode definir cotas do Kafka para o replicador em seus clusters de origem e destino a fim de controlar a capacidade que o replicador do MSK pode usar. Recomenda-se usar uma cota de largura de banda da rede. Uma cota de largura de banda da rede define um limite de taxa de bytes, definido como bytes por segundo, para um ou mais clientes que compartilham uma cota. Essa cota é definida por agente.
Siga estas etapas para aplicar uma cota.
1. Recupere a string do servidor bootstrap para o cluster de origem. Consulte [Obter os agentes de bootstrap para um cluster do Amazon MSK](msk-get-bootstrap-brokers.md).
1. Recupere o Service execution role (SER – Perfil de execução de serviço) usado pelo replicador do MSK. Esse é o SER que você usou para uma solicitação `CreateReplicator`. Você também pode extrair o SER da DescribeReplicator resposta de um replicador existente.
1. Usando as ferramentas de CLI do Kafka, execute o comando a seguir no cluster de origem.
```
./kafka-configs.sh --bootstrap-server --alter --add-config 'consumer_byte_
rate=' --entity-type users --entity-name arn:aws:sts:::assumed-role// --command-config
```
1. Após executar o comando acima, verifique se a métrica `ReplicatorThroughput` não ultrapassa a cota que você definiu.
Observe que todos estarão sujeitos a essa cota se você reutilizar um perfil de execução de serviço entre vários replicadores do MSK. Se você quiser manter cotas separadas por replicador, use perfis de execução de serviço separados.
Para obter mais informações sobre o uso da autenticação do IAM no MSK com cotas, consulte [Clusters Apache Kafka multilocação no Amazon MSK com controle de acesso do IAM e cotas do Kafka: parte 1](https://aws.amazon.com/blogs/big-data/multi-tenancy-apache-kafka-clusters-in-amazon-msk-with-iam-access-control-and-kafka-quotas-part-1/).
**Atenção**
Definir uma taxa de consumer\$1byte\$1rate extremamente baixa pode fazer com que seu replicador do MSK atue de maneiras inesperadas.
## Definir o período de retenção do cluster
Você pode definir o período de retenção de log para clusters do MSK provisionados e com tecnologia sem servidor. O período recomendado de retenção é de 7 dias. Consulte [Alterações na configuração de cluster](msk-replicator-serverless-requirements.md#msk-replicator-config-changes) ou [Configuração do cluster compatível do MSK Serverless](msk-replicator-serverless-requirements.md).