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](troubleshooting.md) les autres fonctionnalités d'Amazon MSK. Vous pouvez également publier votre problème sur [AWS re:Post](https://repost.aws/).
## 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.
1. 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.
1. 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.
1. Vérifiez que votre réseau ACLs ne bloque pas la connexion entre le MSK Replicator et vos clusters.
1. 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.
1. 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).
1. 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.
1. 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.
1. 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.
1. 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.
1. Vérifiez que l'expression régulière de la liste d'autorisation correspond aux groupes de consommateurs que vous souhaitez répliquer.
1. 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é**
[See the AWS documentation website for more details](http://docs.aws.amazon.com/fr_fr/msk/latest/developerguide/msk-replicator-troubleshooting.html)
1. 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.
1. La latence de réplication varie en fonction de la distance de la paire de régions.
1. 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](msk-replicator-bp-quotas.md).
1. Consultez le [AWS Service Health Dashboard](https://health.aws.amazon.com/health/status) 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](msk-replicator-logs.md). 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](client-access.md).
1. Vous voulez ouvrir la console Amazon MSK à la [https://console.aws.amazon.com/msk/maison ? region=us-east-1\#/home/](https://console.aws.amazon.com/msk/home?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](get-bootstrap-console.md) cluster MSK cible.
1. Exportez l'ARN du MSK Replicator et les points de terminaison du broker :
```
export TARGET_CLUSTER_SERVER_STRING=
export REPLICATOR_ARN=
export CONSUMER_CONFIG_FILE=
```
1. Dans votre `/bin` répertoire, enregistrez le script suivant sous le nom**query-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 --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
```
Exécutez ce script pour interroger les messages d'échec du MSK Replicator :
```
/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](limits.md#request-msk-quota-increase).
**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.](https://kafka.apache.org/documentation/#topicconfigs_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](https://kafka.apache.org/documentation/#topicconfigs_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.](https://kafka.apache.org/documentation/#topicconfigs_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.
1. 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).
1. Vérifiez la résolution DNS entre le VPC et les noms d'hôte des courtiers de clusters autogérés.
1. 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é.
1. 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).
1. 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.
1. Vérifiez que l'écouteur SSL est configuré sur tous les courtiers de clusters autogérés.
1. 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.
1. Vérifiez que les groupes de consommateurs consomment activement sur le cluster source (les groupes de consommateurs inactifs peuvent ne pas être synchronisés).
1. Pour la réplication bidirectionnelle, vérifiez qu'elle `synchroniseConsumerGroupOffsets` est définie `true` sur les deux réplicateurs.