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 sourceLe réplicateur 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 de l'échec de création de MSK Replicator :

  1. Vérifiez que les groupes de sécurité que vous avez fournis pour le cluster cible ont des 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 dispose des autorisations requises pour lire et écrire dans vos clusters source et cible, y compris les autorisations d'écriture dans les rubriques.

  4. Vérifiez que les ACL de votre réseau ne bloquent 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 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 (trop de connexions, 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 vaut 0 ou ne comporte aucun point de données, vérifiez les autorisations de rôle réseau et IAM.

  4. Vérifiez que votre réplicateur n'est pas en panne à l'aide de cette ReplicatorFailure métrique. Si la valeur est supérieure à 0, vérifiez le rôle IAM pour les autorisations au niveau de la rubrique.

  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 prendre 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 des décalages différents. Si vous avez activé la synchronisation des décalages des groupes de consommateurs, MSK Replicator traduira automatiquement les décalages afin qu'après le basculement, vos consommateurs puissent reprendre le traitement là où ils s'étaient arrêtés.

Le réplicateur 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 figurant dans la liste des autorisations correspond aux groupes de consommateurs que vous souhaitez répliquer.

  3. Vérifiez que MSK Replicator a créé la rubrique sur le cluster cible. Si votre groupe de consommateurs sur le 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é sur le cluster cible. Une fois que votre groupe de consommateurs commence à lire les nouveaux messages répliqués, MSK Replicator le répliquera automatiquement.

Note

MSK Replicator optimise la synchronisation des offset des groupes de consommateurs pour les consommateurs lisant depuis la fin de la partition thématique. Si vos groupes de consommateurs sont à la traîne par rapport au cluster source, il est possible que vous constatiez un décalage plus important sur le cluster cible. Au fur et à mesure que vos clients rattrapent leur retard, MSK Replicator réduit 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 (MB/s) Partitions minimales requises
    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). Provisionnez la capacité du cluster pour prendre en charge le trafic de réplication en plus des autres trafics.

  3. La latence de réplication varie en fonction de la distance entre les paires 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 tableau de bord de l'état des AWS services 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

Cette ReplicatorFailure métrique vous permet de surveiller et de 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û à une limitation de la taille des messages, à des violations de la plage d'horodatage ou à des problèmes de taille des lots d'enregistrements. Si la remise des journaux est configurée pour votre réplicateur, vous pouvez utiliser les messages de journal délivrés pour identifier la panne spécifique. Pour en savoir plus, consultez Journaux de MSK Replicator. Si la remise du journal 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 les problèmes :

  1. Configurez un client qui peut se connecter au cluster MSK cible et qui dispose des outils d'interface de ligne de commande Apache Kafka. Consultez Connectez-vous à un cluster Amazon MSK Provisioned.

  2. Ouvrez la console Amazon MSK à https://console.aws.amazon.com/msk/home l'adresse ? region=us-east-1#/accueil/.

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

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

    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 sousquery-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. Étant donné que la rubrique contient tous les messages d'échec historiques, lancez l'investigation 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 est supérieure à 10 Mo (valeur maximale 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 ce n'est pas possible, suivez les instructions pour demander une augmentation de limite.

Taille de message supérieure à la taille de message maximale acceptée par le serveur

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 du cluster ou du sujet cible. Voir max.message.bytes.

L'horodatage est hors limites

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 https://kafka.apache.org/documentation/#topicconfigs_message.timestamp.before.max.ms message.timestamp.before.max.ms.

Lot d'enregistrements 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 au moins 1048576 (1 Mo). Voir segment.bytes.

Note

Si la ReplicatorFailure métrique continue d'émettre des valeurs non nulles 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 provenant des sous-réseaux MSK Replicator sur le port SASL_SSL (généralement 9096).

  3. Vérifiez la résolution DNS entre le VPC et les noms d'hôte du broker de cluster autogéré.

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

SASL/SCRAM ou échecs d'authentification mTLS

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

  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é (pour SASL/SCRAM) ou que le certificat client et la clé privée sont corrects (pour les mTL).

  2. Vérifiez que l'utilisateur SCRAM ou le principal de certificat possède les autorisations ACL requises (Lire, décrire sur des sujets ; Lire, décrire sur des groupes de consommateurs ; Décrire sur un cluster).

  3. Vérifiez la AuthError métrique pour confirmer les erreurs d'authentification et déterminer si le cluster source ou cible est affecté à l'aide de la ClusterAlias dimension.

SASL/OAUTHBEARER Échecs d'authentification (OAuth)

Si la AuthError métrique n'est pas nulle ou si les journaux du réplicateur indiquent la récupération du jeton d'accès ou des erreurs : SASL/OAUTHBEARER

  1. Vérifiez que tokenEndpointUrl c'est correct, qu'il utilise le schéma HTTPS et qu'il est accessible depuis les sous-réseaux VPC que vous avez fournis pour le réplicateur. Un KafkaClusterPingSuccessCount de 0 combiné à des erreurs de jeton indique souvent que le point de terminaison du jeton n'est pas accessible.

  2. Pour le mécanisme d'identification du client, vérifiez que les client_id et client_secret dans AWS Secrets Manager sont corrects et que le mécanisme d'acquisition de jetons correspond aux attentes de votre IDP.

  3. Vérifiez qu'il tokenEndpointAuthenticationMethod est valide pour votre mécanisme d'acquisition de jetons. Le mécanisme d'assertion des informations d'identification du client nécessite POST ouBASIC, et le mécanisme d'assertion des informations d'identification du client l'exigeNONE.

  4. En ce qui concerne les mécanismes d'assertion des informations d'identification du porteur JWT et du client IAM, vérifiez que le rôle d'exécution du service dispose des sts:GetWebIdentityToken autorisations nécessaires et qu'il signingAlgorithm correspond à ce que votre IDP attend lorsqu'il valide le audience jeton.

  5. Si votre IDP utilise une autorité de certification privée, vérifiez que le certificat d'autorité de certification référencé par tokenEndpointTlsCertificateArn est complet et valide.

  6. Vérifiez que le principal Kafka auquel votre IDP mappe le jeton d'accès possède les autorisations ACL requises par MSK Replicator sur le cluster source.

  7. Consultez les journaux du réplicateur pour connaître l'état HTTP et le error code OAuth renvoyés par le point de terminaison du jeton. MSK Replicator enregistre ces champs mais n'enregistre jamais le corps de la réponse du point de terminaison du jeton.

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 de AWS Secrets Manager inclut la chaîne de certificats CA complète 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 fiable.

Défaillances de synchronisation des décalages des groupes de consommateurs pour les clusters autogérés

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

  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 que ce paramètre synchroniseConsumerGroupOffsets est défini true sur les deux réplicateurs.