View a markdown version of this page

Solucionar problemas do Amazon MSK Replicator - Amazon Managed Streaming for Apache Kafka
O estado do replicador vai de CRIAÇÃO para FALHAO replicador parece preso no estado CREATINGO replicador não está replicando dados ou replicando apenas dados parciaisDeslocamentos de mensagens no cluster de destino são diferentes do cluster de origemO Replicator não está sincronizando compensações de grupos de consumidoresA latência de replicação é alta ou continua aumentandoSolução de problemas usando a ReplicatorFailure métricaSolucionar problemas de replicação a partir de clusters Kafka autogerenciados

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á.

Solucionar problemas do Amazon MSK Replicator

As informações a seguir podem ajudá-lo a solucionar problemas com o MSK Replicator. Consulte Solução de problemas para o cluster do Amazon MSK outros recursos do Amazon MSK. Você também pode publicar seu problema no AWS re:Post.

O estado do replicador vai de CRIAÇÃO para FALHA

Causas comuns de falha na criação do MSK Replicator:

  1. Verifique se os grupos de segurança que você forneceu para o cluster de destino têm regras de saída para permitir tráfego para os grupos de segurança do cluster de destino e se os grupos de segurança do cluster de destino têm regras de entrada que aceitam tráfego dos grupos de segurança do Replicator.

  2. Para replicação entre regiões, verifique se o cluster de origem tem conectividade de várias VPCs ativada para controle de acesso do IAM e se a política do cluster está configurada no cluster de origem.

  3. Verifique se a função do IAM fornecida durante a criação tem as permissões necessárias para ler e gravar nos clusters de origem e de destino, incluindo permissões para gravar em tópicos.

  4. Verifique se sua rede não ACLs está bloqueando a conexão entre o MSK Replicator e seus clusters.

  5. É possível que os clusters de origem ou de destino não estejam totalmente disponíveis quando o MSK Replicator tentou se conectar. Isso pode ser devido à carga excessiva, ao uso do disco ou ao uso da CPU. 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 parece preso no estado CREATING

A criação do MSK Replicator pode levar até 30 minutos. Aguarde 30 minutos e verifique o estado do replicador novamente.

O replicador não está replicando dados ou replicando apenas dados parciais

  1. Verifique se seu replicador não está enfrentando erros de autenticação usando a AuthError métrica na Amazon CloudWatch. Se essa métrica estiver acima de 0, verifique a política de função do IAM e garanta que não haja permissões de negação definidas para as permissões do cluster.

  2. Verifique se seus clusters de origem e destino não estão enfrentando problemas (muitas conexões, disco com capacidade total ou alto uso da CPU).

  3. Verifique se seus clusters estão acessíveis usando a métrica. KafkaClusterPingSuccessCount Se essa métrica for 0 ou não tiver ponto de dados, verifique as permissões da função de rede e do IAM.

  4. Verifique se o replicador não está apresentando falhas usando a ReplicatorFailure métrica. Se estiver acima de 0, verifique a função do IAM para obter permissões em nível de tópico.

  5. Verifique se a expressão regular na lista de permissões corresponde aos nomes dos tópicos que você deseja replicar e se os tópicos não estão sendo excluídos pela lista de negação.

  6. Pode levar até 30 segundos para que o Replicator detecte e crie novos tópicos. As mensagens produzidas antes da criação do tópico no cluster de destino não serão replicadas se a posição inicial for a mais recente (padrão).

Deslocamentos de mensagens no cluster de destino são diferentes do cluster de origem

O MSK Replicator consome mensagens do cluster de origem e as produz para o cluster de destino, o que pode levar a diferentes deslocamentos. Se você ativou a sincronização de offset de grupos de consumidores, o MSK Replicator traduzirá automaticamente as compensações para que, após o failover, seus consumidores possam retomar o processamento de perto de onde pararam.

O Replicator não está sincronizando compensações de grupos de consumidores

  1. Verifique se a replicação de dados está funcionando conforme o esperado.

  2. Verifique se a expressão regular na lista de permissões corresponde aos grupos de consumidores que você deseja replicar.

  3. Verifique se o Replicador do MSK criou o tópico no cluster de destino. Se seu grupo de consumidores no cluster de origem tiver consumido somente mensagens que não foram replicadas, o grupo de consumidores não será replicado para o cluster de destino. Quando seu grupo de consumidores começar a ler mensagens recém-replicadas, o MSK Replicator replicará automaticamente o grupo de consumidores.

nota

O MSK Replicator otimiza a sincronização de offset de grupos de consumidores para consumidores que leem perto do final da partição do tópico. Se seus grupos de consumidores estiverem atrasados no cluster de origem, você poderá ver um atraso maior no destino. À medida que os consumidores se atualizarem, o Replicador do MSK reduzirá automaticamente o atraso.

A latência de replicação é alta ou continua aumentando

  1. Verifique se você tem o número certo de partições. A tabela a seguir mostra o número mínimo recomendado de partições para a taxa de transferência desejada.

    Throughput e número mínimo recomendado de partições
    Throughput (MB/s) Partições mínimas necessárias
    50167
    100334
    250833
    5001666
    10003333

  2. Verifique se você tem capacidade suficiente de leitura e gravação em seus clusters. O replicador do MSK atua como consumidor do cluster de origem (saída) e como produtor do cluster de destino (entrada). Provisione a capacidade do cluster para suportar o tráfego de replicação, além de outros tráfegos.

  3. A latência de replicação varia de acordo com a distância do par de regiões.

  4. Verifique se o replicador não está sendo controlado usando a métrica. ThrottleTime Se estiver acima de 0, ajuste as cotas do Kafka. Consulte Gerenciando a produtividade com cotas do Kafka.

  5. Consulte o AWS Service Health Dashboard para ver os eventos do serviço MSK em sua região.

Solução de problemas usando a ReplicatorFailure métrica

A ReplicatorFailure métrica ajuda você a monitorar e detectar problemas de replicação. Um valor diferente de zero normalmente indica uma falha de replicação causada por limitações de tamanho da mensagem, violações do intervalo de timestamp ou problemas de tamanho do lote de registros. Se você tiver a entrega de log configurada para seu replicador, poderá usar as mensagens de log entregues para identificar a falha específica. Consulte mais detalhes em Registros do MSK Replicator. Se a entrega de log não estiver configurada, siga as etapas abaixo para consultar o tópico de status do replicador em busca de mensagens de erro.

Se a ReplicatorFailure métrica relatar um valor diferente de zero, siga estas etapas para solucionar o problema:

  1. Configure um cliente que possa se conectar ao cluster MSK de destino e tenha as ferramentas de CLI do Apache Kafka configuradas. Consulte Conectar-se a um cluster do Amazon MSK Provisioned.

  2. Abra o console Amazon MSK em https://console.aws.amazon.com/msk/casa? region=us-east-1#/home/.

    Obtenha o ARNs MSK Replicator e o cluster MSK de destino e obtenha os endpoints do broker do cluster MSK de destino.

  3. Exporte o ARN do MSK Replicator e os endpoints do broker:

    export TARGET_CLUSTER_SERVER_STRING=<BootstrapServerString>
export REPLICATOR_ARN=<ReplicatorARN>
export CONSUMER_CONFIG_FILE=<ConsumerConfigFile>

  4. Em seu <path-to-your-kafka-installation>/bin diretório, salve o script a seguir comoquery-replicator-failure-message.sh.

    #!/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 --replicator-arn <replicator-arn> --bootstrap-server <bootstrap-server> --consumer.config <consumer.config>

print_usage() {
  echo "USAGE: $0 ./query-replicator-failure-message.sh --replicator-arn <replicator-arn> --bootstrap-server <bootstrap-server> --consumer.config <consumer.config>"
  echo "--replicator-arn <String: MSK Replicator ARN>      REQUIRED: The ARN of AWS MSK Replicator."
  echo "--bootstrap-server <String: server to connect to>  REQUIRED: The Kafka server to connect to."
  echo "--consumer.config <String: config file>            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

    Execute este script para consultar as mensagens de falha do MSK Replicator:

    <path-to-your-kafka-installation>/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. 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 e soluções comuns

A seguir, descrevemos as falhas comuns do MSK Replicator e como mitigá-las.

Tamanho da mensagem maior que max.request.size

Causa: O tamanho da mensagem individual excede 10 MB (o máximo padrão).

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 o tamanho das mensagens individuais em seu tópico. Se você não puder, siga as instruções para solicitar um aumento de limite.

Tamanho de mensagem maior que o tamanho de mensagem máximo que o servidor aceitará

Causa: O tamanho da mensagem excede o tamanho máximo da mensagem 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 max.message.bytes configuração no cluster ou tópico de destino. Consulte max.message.bytes.

O carimbo de data/hora está fora do intervalo

Causa: O timestamp da mensagem 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 message.timestamp.before.max.ms configuração do cluster de destino. Consulte message.timestamp.before.max.ms.

Registrar lote muito grande

Causa: O tamanho do lote de registros excede o tamanho do 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: atualize o cluster de destino segment.bytes para ter pelo menos 1048576 (1 MB). Consulte 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.

Solucionar problemas de replicação a partir de clusters Kafka autogerenciados

O MSK Replicator não pode se conectar ao cluster Kafka autogerenciado

Execute as seguintes verificações se o MSK Replicator não conseguir se conectar ao seu cluster Kafka autogerenciado:

  1. Verifique se sua conexão VPN ou Direct Connect está ativa e se as tabelas de rotas estão corretas.

  2. Verifique se os grupos de segurança permitem tráfego de entrada das sub-redes do MSK Replicator na SASL_SSL porta (normalmente 9096).

  3. Verifique a resolução de DNS da VPC para os nomes de host autogerenciados do cluster broker.

  4. Verifique a KafkaClusterPingSuccessCount métrica na Amazon CloudWatch — um valor de 0 indica uma falha de conectividade.

Falhas de autenticação SASL/SCRAM

Se a AuthError métrica for diferente de zero ou os registros do Replicator SASL/SCRAM mostrarem erros:

  1. Verifique se as credenciais armazenadas no AWS Secrets Manager correspondem às credenciais do usuário SCRAM no cluster autogerenciado.

  2. Verifique se o usuário do SCRAM tem as permissões de ACL necessárias (ler, descrever nos tópicos; ler, descrever nos grupos de consumidores; descrever no cluster).

  3. Verifique a AuthError métrica para confirmar os erros de autenticação e identificar se o cluster de origem ou de destino é afetado usando a ClusterAlias dimensão.

Problemas com o certificado SSL

Se o replicador não conseguir estabelecer uma conexão segura com o cluster autogerenciado:

  1. Verifique se o certificate valor no AWS Secrets Manager inclui toda a cadeia de certificados CA no formato PEM.

  2. Verifique se o ouvinte SSL está configurado em todos os agentes de cluster autogerenciados.

  3. Verifique se o certificado não expirou e foi emitido por uma CA confiável.

Falhas de sincronização de compensação de grupos de consumidores para clusters autogerenciados

Se as compensações do grupo de consumidores não estiverem sendo sincronizadas corretamente:

  1. Verifique a ConsumerGroupOffsetSyncFailure métrica — ela deve ser 0.

  2. Verifique se os grupos de consumidores estão consumindo ativamente no cluster de origem (grupos de consumidores inativos podem não estar sincronizados).

  3. Para replicação bidirecional, verifique se synchroniseConsumerGroupOffsets está definido como true em ambos os replicadores.