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á.
# Solução de problemas para o cluster do Amazon MSK
As informações a seguir podem ajudar você a solucionar problemas que possam surgir com seu cluster do Amazon MSK. Você também pode publicar seu problema no [AWS re:Post](https://repost.aws/). Para a solução de problemas do Replicador do Amazon MSK, consulte [Solucionar problemas do Replicador do MSK](msk-replicator-troubleshooting.md).
**Topics**
+ [A substituição do volume causa a saturação do disco devido à sobrecarga de replicação](#replication-overload-disk-saturation)
+ [Grupo de consumidores preso no estado `PreparingRebalance`](#consumer-group-rebalance)
+ [Erro ao entregar os registros do corretor para o Amazon CloudWatch Logs](#cw-broker-logs-error)
+ [Nenhum grupo de segurança padrão](#troubleshooting-shared-vpc)
+ [O cluster parece estar preso no estado CRIANDO](#troubleshooting-cluster-stuck)
+ [O estado do cluster é alterado de CRIANDO para COM FALHA](#troubleshooting-cluster-failed)
+ [O estado do cluster está ATIVO, mas os produtores não conseguem enviar dados ou os consumidores não conseguem receber dados](#troubleshooting-nodata)
+ [AWS CLI não reconhece o Amazon MSK](#troubleshooting-nocli)
+ [As partições ficam offline ou as réplicas estão fora de sincronia](#troubleshooting-offlinepartition-outofsyncreplicas)
+ [O espaço em disco está acabando](#troubleshooting-lowdiskspace)
+ [A memória está baixa](#troubleshooting-lowmemory)
+ [O produtor recebe NotLeaderForPartitionException](#troubleshooting-NotLeaderForPartitionException)
+ [Número de partições com replicação insuficiente (URP) maior que zero](#troubleshooting-urp)
+ [O cluster tem tópicos chamados \$1\$1amazon\$1msk\$1canary e \$1\$1amazon\$1msk\$1canary\$1state](#amazon_msk_canary)
+ [Falha na replicação de partições](#partition_replication_fails)
+ [Não é possível acessar o cluster que está com o acesso público ativado](#public-access-issues)
+ [Não é possível acessar o cluster por meio de IPv6 bootstrap](#dualstack-issues)
+ [Não é possível acessar o cluster de dentro AWS: problemas de rede](#networking-trouble)
+ [Falha na autenticação: muitas conexões](#troubleshoot-too-many-connects)
+ [Falha na autenticação: sessão muito curta](#troubleshoot-session-too-short)
+ [MSK com tecnologia sem servidor: falha na criação do cluster](#troubleshoot-serverless-create-cluster-failure)
+ [Não é possível atualizar KafkaVersionsList na configuração do MSK](#troubleshoot-kafkaversionslist-cfn-update-failure)
## A substituição do volume causa a saturação do disco devido à sobrecarga de replicação
Durante uma falha de hardware de volume não planejada, o Amazon MSK pode substituir o volume por uma nova instância. O Kafka preenche novamente o novo volume replicando partições de outros agentes no cluster. Depois que as partições são replicadas e recuperadas, elas se qualificam para associação de liderança e réplica em sincronia (ISR).
**Problema**
Em um agente se recuperando da substituição de volume, algumas partições de tamanhos variados podem voltar a ficar on-line antes de outras. Isso pode ser problemático, pois essas partições podem estar fornecendo tráfego do mesmo agente que ainda está recuperando (replicando) outras partições. Às vezes, esse tráfego de replicação pode saturar os limites de throughput do volume subjacente, que são de 250 MiB por segundo no caso padrão. Quando essa saturação ocorre, todas as partições que já estão atualizadas serão afetadas, resultando em latência em todo o cluster para qualquer agente que compartilhe a ISR com essas partições atualizadas (não apenas partições líderes devido a acks remotos `acks=all`). Esse problema é mais comum em clusters maiores que têm um número maior de partições que variam em tamanho.
**Recomendação**
+ Para melhorar a I/O postura de replicação, certifique-se de que [as configurações de thread de melhores práticas](https://docs.aws.amazon.com/msk/latest/developerguide/bestpractices.html#optimize-broker-threads) estejam em vigor.
+ Para reduzir a probabilidade de saturação do volume subjacente, habilite o armazenamento provisionado com um throughput mais alto. Um valor mínimo de taxa de transferência de 500 MiB/s é recomendado para casos de replicação de alta taxa de transferência, mas o valor real necessário variará de acordo com a taxa de transferência e o caso de uso. [Provisionar o throughput do armazenamento para agentes Standard em um cluster do Amazon MSK](msk-provision-throughput.md).
+ Para minimizar a pressão de replicação, reduza `num.replica.fetchers` para o valor padrão de `2`.
## Grupo de consumidores preso no estado `PreparingRebalance`
Se um ou mais de seus grupos de consumidores estiverem presos em um estado perpétuo de rebalanceamento, a causa disso pode ser o problema [KAFKA-9752](https://issues.apache.org/jira/browse/KAFKA-9752) do Apache Kafka, que afeta as versões 2.3.1 e 2.4.1 do Apache Kafka.
Para solucionar esse problema, recomendamos que você atualize seu cluster para a versão [Correção de bugs do Amazon MSK versão 2.4.1.1](supported-kafka-versions.md#2.4.1.1), que contém uma correção para esse problema. Para obter informações sobre a atualização de um cluster existente para a versão 2.4.1.1 de correção de bugs do Amazon MSK, consulte [Atualizar a versão do Apache Kafka](version-upgrades.md).
As soluções alternativas para resolver esse problema sem atualizar o cluster para a versão 2.4.1.1 de correção de bugs do Amazon MSK são definir os clientes do Kafka para usar [Protocolo de associação estática](#consumer-group-rebalance-static) ou [Identificar e reiniciar](#consumer-group-rebalance-reboot) o nó do agente de coordenação do grupo de consumidores que está preso.
### Implementação de protocolo de associação estática
Para implementar o protocolo de associação estática em seus clientes, faça o seguinte:
1. Defina a propriedade `group.instance.id` da sua configuração [Consumidores do Kafka](https://kafka.apache.org/26/javadoc/index.html?org/apache/kafka/clients/consumer/KafkaConsumer.html) como uma string estática que identifica o consumidor no grupo.
1. Certifique-se de que outras instâncias da configuração sejam atualizadas para usar a string estática.
1. Implante as mudanças em seus consumidores do Kafka.
O uso do Protocolo de associação estática é mais eficaz se o tempo limite da sessão na configuração do cliente for definido para uma duração que permita ao consumidor se recuperar sem acionar prematuramente um rebalanceamento do grupo de consumidores. Por exemplo, se sua aplicação consumidora conseguir tolerar 5 minutos de indisponibilidade, um valor razoável para o tempo limite da sessão seria 4 minutos em vez do valor padrão de 10 segundos.
**nota**
O uso do protocolo de associação estática simplesmente reduz a probabilidade de se deparar com esse problema. Você ainda poderá se deparar com esse problema mesmo ao usar o protocolo de associação estática.
### Como reinicializar o nó do agente de coordenação
Para reinicializar o nó agente de coordenação, faça o seguinte:
1. Identifique o coordenador do grupo usando o comando `kafka-consumer-groups.sh`.
1. Reinicie o coordenador do grupo de consumidores bloqueados usando a ação [ RebootBroker](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-reboot-broker.html#RebootBroker)da API.
## Erro ao entregar os registros do corretor para o Amazon CloudWatch Logs
Ao tentar configurar seu cluster para enviar registros do agente para a Amazon CloudWatch Logs, você pode obter uma das duas exceções.
Se você receber uma exceção `InvalidInput.LengthOfCloudWatchResourcePolicyLimitExceeded`, tente novamente, mas use grupos de log que começam com `/aws/vendedlogs/`. Para obter mais informações, consulte [Habilitar o registro em log de determinados serviços da Amazon Web Services](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html).
Se você receber uma `InvalidInput.NumberOfCloudWatchResourcePoliciesLimitExceeded` exceção, escolha uma política existente do Amazon CloudWatch Logs em sua conta e acrescente o seguinte JSON a ela.
```
{"Sid":"AWSLogDeliveryWrite","Effect":"Allow","Principal":{"Service":"delivery.logs.amazonaws.com"},"Action":["logs:CreateLogStream","logs:PutLogEvents"],"Resource":["*"]}
```
Se você tentar anexar o JSON acima a uma política existente, mas receber um erro informando que você atingiu o tamanho máximo da política escolhida, tente anexar o JSON a outra de suas políticas do Amazon Logs. CloudWatch Depois de acrescentar o JSON a uma política existente, tente novamente configurar a entrega de registros do corretor para o Amazon Logs. CloudWatch
## Nenhum grupo de segurança padrão
Se você tentar criar um cluster e obter um erro indicando que não há grupo de segurança padrão, talvez esteja usando uma VPC que foi compartilhada com você. Peça para o administrador conceder permissão para descrever os grupos de segurança nesta VPC e tente novamente. Para obter um exemplo de uma política que permita esta ação, consulte [Amazon EC2: permite o gerenciamento de grupos de segurança do EC2 associados a uma VPC específica de forma programática e no console](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_ec2_securitygroups-vpc.html).
## O cluster parece estar preso no estado CRIANDO
Às vezes a criação do cluster pode levar até 30 minutos. Aguarde 30 minutos e verifique o estado do cluster novamente.
## O estado do cluster é alterado de CRIANDO para COM FALHA
Tente criar o cluster novamente.
## O estado do cluster está ATIVO, mas os produtores não conseguem enviar dados ou os consumidores não conseguem receber dados
+ Se a criação do cluster tiver êxito (o estado do cluster será `ACTIVE`), mas não será possível enviar nem receber dados. Certifique-se de que os aplicativos produtor e consumidor tenham acesso ao cluster. Para obter mais informações, consulte as diretrizes no [Etapa 3: criar uma máquina cliente](create-client-machine.md).
+ Caso os produtores e os consumidores tenham acesso ao cluster, mas ainda assim enfrentem problemas ao gerar e consumir dados, a causa pode ser [KAFKA-7697](https://issues.apache.org/jira/browse/KAFKA-7697), que afeta o Apache Kafka versão 2.1.0 e pode levar a um deadlock em um ou mais agentes. Considere migrar para o Apache Kafka 2.2.1, que não é afetado por este bug. Para obter informações sobre como migrar, consulte [Migrar workloads do Kafka para um cluster do Amazon MSK](migration.md).
## AWS CLI não reconhece o Amazon MSK
Se você o tiver AWS CLI instalado, mas ele não reconhecer os comandos do Amazon MSK, atualize-o AWS CLI para a versão mais recente. Para obter instruções detalhadas sobre como atualizar o AWS CLI, consulte [Instalando AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) o. Para obter informações sobre como usar os comandos AWS CLI para executar o Amazon MSK, consulte[Principais recursos e conceitos do Amazon MSK](operations.md).
## As partições ficam offline ou as réplicas estão fora de sincronia
Estes podem ser sintomas de pouco espaço em disco. Consulte [O espaço em disco está acabando](#troubleshooting-lowdiskspace).
## O espaço em disco está acabando
Consulte as melhores práticas para gerenciar o espaço em disco: [Monitorar o espaço em disco](bestpractices.md#bestpractices-monitor-disk-space) e [Ajustar os parâmetros de retenção de dados](bestpractices.md#bestpractices-retention-period).
## A memória está baixa
Caso a métrica `MemoryUsed` esteja alta ou a `MemoryFree` esteja baixa, isso não significa que existe um problema. O Apache Kafka foi desenvolvido para usar o máximo de memória possível, que é gerenciada de forma ideal.
## O produtor recebe NotLeaderForPartitionException
Geralmente, isto é um erro transitório. Defina o parâmetro de configuração de `retries` do produtor com um valor mais alto que o atual.
## Número de partições com replicação insuficiente (URP) maior que zero
A `UnderReplicatedPartitions` é uma métrica importante e deve ser monitorada. Em um cluster MSK íntegro, essa métrica tem o valor igual a 0. Se for maior que zero, isso pode ocorrer por um dos motivos a seguir.
+ Se `UnderReplicatedPartitions` estiver apresentando picos, o problema pode ser que o cluster não foi provisionado no tamanho correto para tratar o tráfego de entrada e saída. Consulte [Melhores práticas para agentes Standard](bestpractices.md).
+ Se `UnderReplicatedPartitions` for consistentemente maior que 0, inclusive durante períodos de baixo tráfego, o problema pode ser que você tenha definido restrições ACLs que não concedem acesso ao tópico aos corretores. Para replicar partições, os agentes devem estar autorizados a READ (ler) e DESCRIBE (descrever) os tópicos. DESCRIBE é concedido por padrão com a autorização READ. Para obter informações sobre configuração ACLs, consulte [Autorização e ACLs](https://kafka.apache.org/documentation/#security_authz) na documentação do Apache Kafka.
## O cluster tem tópicos chamados \$1\$1amazon\$1msk\$1canary e \$1\$1amazon\$1msk\$1canary\$1state
Você pode ver que seu cluster do MSK tem um tópico com o nome `__amazon_msk_canary` e outro com o nome `__amazon_msk_canary_state`. Trata-se de tópicos internos que o Amazon MSK cria e usa para métricas de integridade e diagnóstico do cluster. Esses tópicos têm um tamanho insignificante e não podem ser excluídos.
## Falha na replicação de partições
Certifique-se de que você não tenha definido ACLs CLUSTER\$1ACTIONS.
## Não é possível acessar o cluster que está com o acesso público ativado
Siga as etapas abaixo se o seu cluster estiver com o acesso público ativado, mas você ainda não conseguir acessá-lo pela Internet:
1. Certifique-se de que as regras de entrada do grupo de segurança do cluster tenham permissão para seu endereço IP e a porta do cluster. Para obter uma lista dos números de portas do cluster, consulte [Informações de porta](port-info.md). Certifique-se também de que as regras de saída do grupo de segurança permitam comunicações de saída. Para ter mais informações sobre grupos de segurança e suas regras de entrada e saída, consulte [Grupos de segurança para sua VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) no Guia do usuário da Amazon VPC.
1. Certifique-se de que seu endereço IP e a porta do cluster tenham permissão nas regras de entrada da ACL da rede VPC do cluster. Ao contrário dos grupos de segurança, ACLs as redes não têm estado. Isso significa que você deve configurar as regras de entrada e saída. Nas regras de saída, permita que todo o tráfego (intervalo de portas: 0-65535) chegue ao seu endereço IP. Para obter mais informações, consulte [Adicionar e excluir regras](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#Rules) no Guia do usuário da Amazon VPC.
1. Verifique se você está usando a string bootstrap-brokers de acesso público para acessar o cluster. Um cluster do MSK com acesso público ativado tem duas strings distintas de agentes de inicialização, uma para acesso público e outra para acesso interno diretamente da AWS. Para obter mais informações, consulte [Obtenha os corretores de bootstrap usando o Console de gerenciamento da AWS](get-bootstrap-console.md).
## Não é possível acessar o cluster por meio de IPv6 bootstrap
Se você estiver tendo problemas para se conectar a um cluster usando as strings de IPv6 bootstrap fornecidas, siga estas etapas:
1. Certifique-se de que seu cliente tenha endereços IPv4 e IPv6 atribuídos. Seu aplicativo cliente deve estar sendo executado em uma sub-rede que tenha o endereçamento IPv4 e IPv6 habilitado e configurado corretamente. Verifique se sua VPC tem um bloco CIDR IPv4 e um bloco CIDR IPv6 associado, confirme se sua sub-rede tem endereços IPv4 e IPv6 ativados e verifique se sua instância EC2 ou ambiente de cliente tem endereços e endereços atribuídos. IPv4 IPv6 Para obter mais informações, consulte o [endereçamento IP para você VPCs e suas sub-redes no Guia](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html) do usuário da Amazon VPC.
1. Certifique-se de que as IPv6 portas relevantes estejam presentes nas regras de entrada e saída do grupo de segurança. Adicione regras de entrada para permitir o tráfego nas portas do cluster a partir de seus IPv6 endereços e configure as regras de saída para permitir IPv6 o tráfego. Para obter números de porta específicos, consulte [Informações sobre portas](https://docs.aws.amazon.com/msk/latest/developerguide/port-info.html) na documentação do MSK. Lembre-se de atualizar ambas IPv4 as IPv6 regras se estiver executando no modo de pilha dupla. Para ter mais informações sobre grupos de segurança e suas regras de entrada e saída, consulte [Grupos de segurança para sua VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html) no Guia do usuário da Amazon VPC.
1. Verifique se a configuração da propriedade da JVM está correta para IPv6 suporte. Em seu aplicativo cliente, `java.net.preferIPv6Addresses` defina como `true` e `java.net.preferIPv4Stack` para`false`. Essas configurações podem ser definidas como propriedades do sistema ou argumentos da JVM. Reinicie seu aplicativo depois de fazer essas alterações para que elas entrem em vigor.
## Não é possível acessar o cluster de dentro AWS: problemas de rede
Se você tiver uma aplicação do Apache Kafka que não consiga se comunicar com êxito com um cluster do MSK, comece executando o teste de conectividade a seguir.
1. Use qualquer um dos métodos descritos em [Obter os agentes de bootstrap para um cluster do Amazon MSK](msk-get-bootstrap-brokers.md) para obter os endereços dos agentes de bootstrap.
1. No comando a seguir, *bootstrap-broker* substitua por um dos endereços do broker que você obteve na etapa anterior. *port-number*Substitua por 9094 se o cluster estiver configurado para usar a autenticação TLS. Se o cluster não usar a autenticação TLS, *port-number* substitua por 9092. Execute o comando usando a máquina cliente.
```
telnet bootstrap-broker port-number
```
Em que o número da porta será:
+ 9094 se o cluster estiver configurado para usar a autenticação TLS.
+ 9092 se o cluster não usar a autenticação TLS.
+ Um número de porta diferente será necessário se o acesso público estiver habilitado.
Execute o comando usando a máquina cliente.
1. Repita o comando anterior para todos os agentes de bootstrap.
Se a máquina cliente é capaz de acessar os agentes, isso significa que não há problemas de conectividade. Nesse caso, execute o comando a seguir para verificar se o cliente do Apache Kafka está configurado corretamente. Para obter*bootstrap-brokers*, use qualquer um dos métodos descritos em[Obter os agentes de bootstrap para um cluster do Amazon MSK](msk-get-bootstrap-brokers.md). *topic*Substitua pelo nome do seu tópico.
```
/bin/kafka-console-producer.sh --broker-list bootstrap-brokers --producer.config client.properties --topic topic
```
Se o comando anterior for bem-sucedido, isso indica que o cliente está configurado corretamente. Se você ainda não consegue produzir e consumir de um aplicativo, depure o problema no nível do aplicativo.
Se a máquina cliente não consegue acessar os agentes, consulte as subseções a seguir para obter orientações baseadas na configuração da máquina cliente.
### Cliente do Amazon EC2 e cluster do MSK na mesma VPC
Se a máquina cliente estiver na mesma VPC que o cluster do MSK, verifique se o grupo de segurança do cluster tem uma regra de entrada que aceite tráfego do grupo de segurança da máquina cliente. Para obter informações sobre como configurar essas regras, consulte [Regras do grupo de segurança](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SecurityGroupRules). Para obter um exemplo de como acessar um cluster de uma instância do Amazon EC2 que esteja na mesma VPC do cluster, consulte [Conceitos básicos sobre como usar o Amazon MSK](getting-started.md).
### Cliente Amazon EC2 e cluster MSK em diferentes VPCs
Se a máquina cliente e o cluster estiverem em duas partes diferentes VPCs, verifique o seguinte:
+ Os dois VPCs são examinados.
+ O status da conexão de emparelhamento está ativo.
+ As tabelas de rotas dos dois VPCs estão configuradas corretamente.
Para obter informações sobre o emparelhamento de VPC, consulte [Trabalhar com conexões de emparelhamento de VPC](https://docs.aws.amazon.com/vpc/latest/peering/working-with-vpc-peering.html).
### Cliente on-premises
No caso de um cliente local configurado para se conectar ao cluster MSK usando Site-to-Site VPN, verifique o seguinte:
+ O status da conexão VPN é `UP`. Para obter informações sobre como verificar o status da conexão VPN, consulte [Como verificar o status atual do meu túnel VPN?](https://aws.amazon.com/premiumsupport/knowledge-center/check-vpn-tunnel-status/).
+ A tabela de rotas da VPC do cluster contém a rota para um CIDR on-premises, cujo destino tem o formato `Virtual private gateway(vgw-xxxxxxxx)`.
+ O grupo de segurança do cluster do MSK permite tráfego na porta 2181, na porta 9092 (se o cluster aceitar tráfego em texto simples) e na porta 9094 (se o cluster aceitar tráfego com criptografia TLS).
Para obter mais orientações sobre Site-to-Site VPN solução de problemas, consulte [Solução de problemas do Client VPN](https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/troubleshooting.html).
### Direct Connect
Se o cliente usar Direct Connect, consulte [Solução de problemas Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Troubleshooting.html).
Se as orientações para a solução de problemas anteriores não resolverem a situação, certifique-se de que nenhum firewall esteja bloqueando o tráfego de rede. Para depuração adicional, use ferramentas como `tcpdump` e `Wireshark` para analisar o tráfego e garantir que ele esteja alcançando o cluster do MSK.
## Falha na autenticação: muitas conexões
O erro `Failed authentication ... Too many connects` indica que um agente está se protegendo porque um ou mais clientes do IAM estão tentando se conectar a ele em um ritmo agressivo. Para ajudar os agentes a aceitarem uma taxa maior de novas conexões do IAM, você pode aumentar o parâmetro de configuração [https://kafka.apache.org/documentation/#producerconfigs_reconnect.backoff.ms](https://kafka.apache.org/documentation/#producerconfigs_reconnect.backoff.ms).
Para saber mais sobre os limites de taxa para novas conexões por agente, consulte a página [Cota do Amazon MSK](limits.md).
## Falha na autenticação: sessão muito curta
O erro `Failed authentication ... Session too short` ocorre quando seu cliente tenta se conectar a um cluster usando credenciais do IAM que estão prestes a expirar. Certifique-se de verificar como suas credenciais do IAM têm sido atualizadas. Provavelmente as credenciais estão sendo substituídas muito perto da expiração da sessão, o que causa problemas no servidor e falhas de autenticação.
## MSK com tecnologia sem servidor: falha na criação do cluster
Se você tentar criar um cluster do MSK com a tecnologia sem servidor e o fluxo de trabalho falhar, talvez você não tenha permissão para criar um endpoint da VPC. Verifique se o administrador concedeu permissão para você criar um endpoint da VPC permitindo a ação `ec2:CreateVpcEndpoint`.
Para obter uma lista completa das permissões necessárias para realizar todas as ações do Amazon MSK, consulte [AWS política gerenciada: Amazon MSKFull Access](security-iam-awsmanpol-AmazonMSKFullAccess.md).
## Não é possível atualizar KafkaVersionsList na configuração do MSK
Quando você atualiza a [KafkaVersionsList](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html#cfn-msk-configuration-kafkaversionslist)propriedade no [AWS::MSK::Configuration](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html)recurso, a atualização falha com o seguinte erro.
```
Resource of type 'AWS::MSK::Configuration' with identifier '' already exists.
```
Ao atualizar a `KafkaVersionsList` propriedade, AWS CloudFormation recria uma nova configuração com a propriedade atualizada antes de excluir a configuração antiga. A atualização da CloudFormation pilha falha porque a nova configuração usa o mesmo nome da configuração existente. Essa atualização requer uma [substituição de recurso](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-update-behaviors.html#update-replacement). Para atualizar `KafkaVersionsList` com êxito, você também deve atualizar a propriedade [Nome](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html#cfn-msk-configuration-name) na mesma operação.
Além disso, se sua configuração estiver vinculada a qualquer cluster criado usando o Console de gerenciamento da AWS ou AWS CLI, adicione o seguinte ao seu recurso de configuração para evitar [tentativas malsucedidas de exclusão de recursos](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#troubleshooting-errors-resource-removed-not-deleted).
```
UpdateReplacePolicy: Retain
```
Depois que a atualização for bem-sucedida, acesse o console do Amazon MSK e exclua a configuração antiga. Para obter informações sobre configurações do MSK, consulte [Configurações do Amazon MSK Provisioned](msk-configuration.md).