View a markdown version of this page

Résoudre les problèmes liés à Amazon MSK Replicator - Amazon Managed Streaming for Apache Kafka
L'état du réplicateur passe de CREATING à FAILEDLe réplicateur semble bloqué dans l'état CREATINGLe réplicateur ne réplique pas les données ou ne réplique que des données partiellesLes décalages de messages dans le cluster cible sont différents de ceux du cluster sourceReplicator ne synchronise pas les offsets des groupes de consommateursLa latence de réplication est élevée ou continue d'augmenterRésolution des problèmes à l'aide de la ReplicatorFailure métriqueRésoudre les problèmes de réplication à partir de clusters Kafka autogérés

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Résoudre les problèmes liés à Amazon MSK Replicator

Les informations suivantes peuvent vous aider à résoudre les problèmes liés à MSK Replicator. Consultez Résoudre les problèmes liés à votre cluster Amazon MSK les autres fonctionnalités d'Amazon MSK. Vous pouvez également publier votre problème sur AWS re:Post.

L'état du réplicateur passe de CREATING à FAILED

Causes courantes d'échec de création de MSK Replicator :

  1. Vérifiez que les groupes de sécurité que vous avez fournis pour le cluster cible disposent de règles sortantes pour autoriser le trafic vers les groupes de sécurité de votre cluster cible, et que les groupes de sécurité de votre cluster cible ont des règles entrantes qui acceptent le trafic provenant des groupes de sécurité du réplicateur.

  2. Pour la réplication entre régions, vérifiez que la connectivité multi-VPC de votre cluster source est activée pour le contrôle d'accès IAM et que la politique de cluster est configurée sur le cluster source.

  3. Vérifiez que le rôle IAM fourni lors de la création possède les autorisations requises pour lire et écrire sur vos clusters source et cible, y compris les autorisations pour écrire sur des sujets.

  4. Vérifiez que votre réseau ACLs ne bloque pas la connexion entre le MSK Replicator et vos clusters.

  5. Il est possible que les clusters source ou cible ne soient pas entièrement disponibles lorsque le MSK Replicator a essayé de se connecter. Cela peut être dû à une charge excessive, à une utilisation du disque ou à une utilisation du processeur. Corrigez le problème avec les agents et réessayez de créer un réplicateur.

Après avoir effectué les validations ci-dessus, créez à nouveau le réplicateur MSK.

Le réplicateur semble bloqué dans l'état CREATING

La création de MSK Replicator peut prendre jusqu'à 30 minutes. Attendez 30 minutes et vérifiez à nouveau l'état du réplicateur.

Le réplicateur ne réplique pas les données ou ne réplique que des données partielles

  1. Vérifiez que votre réplicateur ne rencontre pas d'erreurs d'authentification à l'aide de la AuthError métrique d'Amazon CloudWatch. Si cette métrique est supérieure à 0, vérifiez la politique de rôle IAM et assurez-vous qu'aucune autorisation de refus n'est définie pour les autorisations du cluster.

  2. Vérifiez que vos clusters source et cible ne rencontrent aucun problème (connexions trop nombreuses, disque à pleine capacité ou utilisation élevée du processeur).

  3. Vérifiez que vos clusters sont accessibles à l'aide de la KafkaClusterPingSuccessCount métrique. Si cette métrique est égale à 0 ou ne comporte aucun point de données, vérifiez les autorisations du réseau et des rôles IAM.

  4. Vérifiez que votre réplicateur ne rencontre pas de défaillances à l'aide de la ReplicatorFailure métrique. Si la valeur est supérieure à 0, vérifiez le rôle IAM pour les autorisations au niveau du sujet.

  5. Vérifiez que l'expression régulière de la liste d'autorisation correspond aux noms des sujets que vous souhaitez répliquer et que les sujets ne sont pas exclus par la liste de refus.

  6. Le réplicateur peut mettre jusqu'à 30 secondes pour détecter et créer de nouveaux sujets. Les messages produits avant la création du sujet sur le cluster cible ne seront pas répliqués si la position de départ est la plus récente (par défaut).

Les décalages de messages dans le cluster cible sont différents de ceux du cluster source

MSK Replicator consomme les messages du cluster source et les transmet au cluster cible, ce qui peut entraîner différents décalages. Si vous avez activé la synchronisation des décalages par groupes de consommateurs, MSK Replicator traduira automatiquement les décalages afin qu'après le basculement, vos clients puissent reprendre le traitement presque là où ils s'étaient arrêtés.

Replicator ne synchronise pas les offsets des groupes de consommateurs

  1. Vérifiez que la réplication des données fonctionne comme prévu.

  2. Vérifiez que l'expression régulière de la liste d'autorisation correspond aux groupes de consommateurs que vous souhaitez répliquer.

  3. Vérifiez que MSK Replicator a créé le sujet sur le cluster cible. Si votre groupe de consommateurs du cluster source n'a consommé que des messages qui n'ont pas été répliqués, le groupe de consommateurs ne sera pas répliqué vers le cluster cible. Dès que votre groupe de consommateurs commence à lire les messages nouvellement répliqués, MSK Replicator le réplique automatiquement.

Note

MSK Replicator optimise la synchronisation des décalages entre les groupes de consommateurs pour les consommateurs lisant à la fin de la partition thématique. Si vos groupes de consommateurs sont à la traîne sur le cluster source, vous constaterez peut-être un retard plus important sur le cluster cible. Au fur et à mesure que vos clients rattrapent leur retard, MSK Replicator réduira automatiquement le décalage.

La latence de réplication est élevée ou continue d'augmenter

  1. Vérifiez que vous disposez du bon nombre de partitions. Le tableau suivant indique le nombre minimum de partitions recommandé pour le débit souhaité.

    Débit et nombre minimal de partitions recommandé
    Débit (Mo/s) Nombre minimal de partitions requis
    50167
    100334
    250833
    5001666
    1 0003333

  2. Vérifiez que la capacité de lecture et d'écriture de vos clusters est suffisante. Le réplicateur MSK agit en tant que consommateur pour votre cluster source (sortie) et en tant que producteur pour votre cluster cible (entrée). Fournissez la capacité du cluster pour prendre en charge le trafic de réplication en plus des autres types de trafic.

  3. La latence de réplication varie en fonction de la distance de la paire de régions.

  4. Vérifiez que votre réplicateur n'est pas limité à l'aide de la métrique. ThrottleTime Si la valeur est supérieure à 0, ajustez les quotas de Kafka. Consultez Gestion du débit avec les quotas Kafka.

  5. Consultez le AWS Service Health Dashboard pour connaître les événements liés au service MSK dans votre région.

Résolution des problèmes à l'aide de la ReplicatorFailure métrique

La ReplicatorFailure métrique vous aide à surveiller et à détecter les problèmes de réplication. Une valeur différente de zéro indique généralement un échec de réplication dû à des limites de taille des messages, à des violations de la plage d'horodatage ou à des problèmes de taille des lots d'enregistrements. Si la livraison des journaux est configurée pour votre réplicateur, vous pouvez utiliser les messages de journal envoyés pour identifier la défaillance spécifique. Pour en savoir plus, consultez Journaux de MSK Replicator. Si la livraison des journaux n'est pas configurée, suivez les étapes ci-dessous pour rechercher des messages d'erreur dans la rubrique d'état du réplicateur.

Si la ReplicatorFailure métrique indique une valeur différente de zéro, procédez comme suit pour résoudre le problème :

  1. Configurez un client capable de se connecter au cluster MSK cible et doté des outils de la CLI Apache Kafka. Consultez Connectez-vous à un cluster Amazon MSK Provisioned.

  2. Vous voulez ouvrir la console Amazon MSK à la https://console.aws.amazon.com/msk/maison ? region=us-east-1#/home/.

    Obtenez le ARNs réplicateur MSK et le cluster MSK cible, ainsi que les points de terminaison du broker du cluster MSK cible.

  3. Exportez l'ARN du MSK Replicator et les points de terminaison du broker :

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

  4. Dans votre <path-to-your-kafka-installation>/bin répertoire, enregistrez le script suivant sous le nomquery-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

    Exécutez ce script pour interroger les messages d'échec du 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

    Ce script affiche toutes les erreurs avec leurs messages d'exception et les partitions thématiques concernées. Dans la mesure où la rubrique contient tous les messages d'échec historiques, lancez l'enquête en utilisant le dernier message. Voici un exemple de message d'échec :

    ReplicatorException: The request included a message larger than the max message size the server will accept. Topic: test, Partition: 1
Défaillances courantes et solutions

Ce qui suit décrit les défaillances courantes de MSK Replicator et explique comment les atténuer.

Taille du message supérieure à max.request.size

Cause : La taille de chaque message dépasse 10 Mo (maximum par défaut).

Voici un exemple de ce type de message d'échec.

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

Solution : réduisez la taille des messages individuels dans votre sujet. Si vous ne le pouvez pas, suivez les instructions pour demander une augmentation de limite.

La taille du message est supérieure à la taille maximale des messages que le serveur acceptera

Cause : La taille du message dépasse la taille de message maximale du cluster cible.

Voici un exemple de ce type de message d'échec.

ReplicatorException: The request included a message larger than the max message size the server will accept. Topic: test, Partition: 1

Solution : augmentez la max.message.bytes configuration sur le cluster ou le sujet cible. Voir max.message.bytes.

L'horodatage est hors de portée

Cause : L'horodatage du message se situe en dehors de la plage autorisée du cluster cible.

Voici un exemple de ce type de message d'échec.

ReplicatorException: Timestamp 1730137653724 of message with offset 0 is out of range. The timestamp should be within [1730137892239, 1731347492239] Topic: test, Partition: 1

Solution : mettez à jour la message.timestamp.before.max.ms configuration du cluster cible. Voir message.timestamp.before.max.ms.

Le lot d'enregistrements est trop volumineux

Cause : La taille du lot d'enregistrements dépasse la taille de segment définie pour le sujet sur le cluster cible. MSK Replicator prend en charge une taille de lot maximale de 1 Mo.

Voici un exemple de ce type de message d'échec.

ReplicatorException: The request included message batch larger than the configured segment size on the server. Topic: test, Partition: 1

Solution : mettez à jour le cluster cible segment.bytes pour qu'il soit d'au moins 1048576 (1 Mo). Voir segment.bytes.

Note

Si la ReplicatorFailure métrique continue d'émettre des valeurs différentes de zéro après avoir appliqué ces solutions, répétez le processus de dépannage jusqu'à ce que la métrique émette une valeur nulle.

Résoudre les problèmes de réplication à partir de clusters Kafka autogérés

MSK Replicator ne peut pas se connecter au cluster Kafka autogéré

Effectuez les vérifications suivantes si MSK Replicator ne peut pas se connecter à votre cluster Kafka autogéré :

  1. Vérifiez que votre connexion VPN ou Direct Connect est active et que les tables de routage sont correctes.

  2. Vérifiez que les groupes de sécurité autorisent le trafic entrant depuis les sous-réseaux MSK Replicator sur le SASL_SSL port (généralement le 9096).

  3. Vérifiez la résolution DNS entre le VPC et les noms d'hôte des courtiers de clusters autogérés.

  4. Vérifiez la KafkaClusterPingSuccessCount métrique sur Amazon CloudWatch  : une valeur de 0 indique une défaillance de connectivité.

Défaillances d'authentification SASL/SCRAM

Si la AuthError métrique est différente de zéro ou si les journaux du réplicateur indiquent SASL/SCRAM des erreurs :

  1. Vérifiez que les informations d'identification stockées dans AWS Secrets Manager correspondent aux informations d'identification de l'utilisateur SCRAM sur le cluster autogéré.

  2. Vérifiez que l'utilisateur SCRAM dispose des autorisations ACL requises (lire, décrire sur les sujets ; lire, décrire sur les groupes de consommateurs ; décrire sur le cluster).

  3. Vérifiez la AuthError métrique pour confirmer les erreurs d'authentification et déterminez si le cluster source ou cible est affecté par la ClusterAlias dimension.

Problèmes liés aux certificats SSL

Si le réplicateur ne parvient pas à établir une connexion sécurisée avec le cluster autogéré :

  1. Vérifiez que la certificate valeur dans AWS Secrets Manager inclut la chaîne complète de certificats CA au format PEM.

  2. Vérifiez que l'écouteur SSL est configuré sur tous les courtiers de clusters autogérés.

  3. Vérifiez que le certificat n'a pas expiré et qu'il est émis par une autorité de certification approuvée.

Les groupes de consommateurs compensent les échecs de synchronisation pour les clusters autogérés

Si les décalages des groupes de consommateurs ne sont pas correctement synchronisés :

  1. Vérifiez la ConsumerGroupOffsetSyncFailure métrique : elle doit être égale à 0.

  2. Vérifiez que les groupes de consommateurs consomment activement sur le cluster source (les groupes de consommateurs inactifs peuvent ne pas être synchronisés).

  3. Pour la réplication bidirectionnelle, vérifiez qu'elle synchroniseConsumerGroupOffsets est définie true sur les deux réplicateurs.