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.
# Qu'est-ce que le réplicateur Amazon MSK ?
Amazon MSK Replicator est une fonctionnalité Amazon MSK qui vous permet de répliquer de manière fiable des données entre des clusters Amazon MSK différents ou identiques. Région AWS Toutefois, les clusters source et cible doivent se trouver dans le même environnement Compte AWS. Le réplicateur MSK vous permet de créer facilement des applications de streaming résilientes au niveau régional pour une disponibilité et une continuité des activités accrues. Le réplicateur MSK fournit une réplication asynchrone automatique sur les clusters MSK, éliminant ainsi le besoin d'écrire du code personnalisé, de gérer l'infrastructure ou de configurer un réseau entre régions.
Le réplicateur MSK adapte automatiquement les ressources sous-jacentes afin que vous puissiez répliquer les données à la demande sans avoir à surveiller ou à mettre à l'échelle la capacité. MSK Replicator reproduit également les métadonnées Kafka nécessaires, notamment les configurations de rubriques, les listes de contrôle d'accès (ACLs) et les décalages de groupes de consommateurs. Si un événement inattendu se produit dans une région, vous pouvez basculer vers l'autre AWS région et reprendre le traitement en toute simplicité.
Le réplicateur MSK prend en charge à la fois la réplication entre régions (CRR) et la réplication dans une même région (SRR). Lors de la réplication entre régions, les clusters MSK source et cible se trouvent dans des régions différentes AWS . Dans la réplication dans la même région, les clusters MSK source et cible se trouvent dans la même région. AWS Vous devez créer des clusters MSK source et cible avant de les utiliser avec le réplicateur MSK.
**Note**
MSK Replicator prend en charge les AWS régions suivantes : USA Est (us-east-1, Virginie du Nord) ; USA Est (us-east-2, Ohio) ; USA Ouest (us-west-2, Oregon) ; Europe (eu-west-1, Irlande) ; Europe (eu-central-1, Francfort) ; Asie-Pacifique (ap-southeast-1) ap-southeast-1, Singapour) ; Asie-Pacifique (ap-southeast-2, Sydney) ; Europe (eu-north-1, Stockholm) ; Asie-Pacifique (ap-south-1, Mumbai) ; Europe (eu-west-3, Paris) ; Amérique du Sud (sa-east-1, São Paulo) ; Asie-Pacifique (ap-northeast-2, Séoul) ; Europe (eu-west-2, Londres) ; Asie-Pacifique (ap-northeast-1, Tokyo) ; ouest des États-Unis (us-west-1, Californie du Nord) ; Canada (ca-central-1, centre) ; Chine (Pékin) (cn-north-1) ; Chine (Ningxia) (cn-northwest-1) ; Asie-Pacifique (Hyderabad) (ap-southeast-2), Asie-Pacifique (Malaisie) (ap-southeast-5), Asie-Pacifique (Thaïlande) (ap-southeast-7), Mexique (centre) (mx-central-1), Asie-Pacifique (Taipei) (ap-east-2), Canada Ouest (Calgary) (ca-west-1), Europe (Espagne) (eu-south-2), Moyen-Orient (Bahreïn) (me-south-1), Asie-Pacifique (Jakarta) (ap-southeast-3 ap-southeast-3), Afrique (Le Cap) (af-south-1), Moyen-Orient (Émirats arabes unis) (me-central-1), Asie-Pacifique (Hong Kong) (ap-east-1), Asie-Pacifique (Osaka) (ap-northeast-3), Asie Pacifique (Melbourne) (ap-southeast-4), Europe (Milan) (eu-south-1), Israël (Tel Aviv) (il-central-1), Europe (Zurich) (eu-central-2) et Asie-Pacifique (Nouvelle Zélande) (ap-southeast-6)
Voici quelques utilisations courantes d'Amazon MSK Replicator.
+ Création d'applications de streaming multirégionales : créez des applications de streaming hautement disponibles et tolérantes aux pannes pour une résilience accrue sans avoir à configurer de solutions personnalisées.
+ Accès aux données à faible latence : offrez un accès aux données à faible latence aux consommateurs de différentes régions géographiques.
+ Distribuez les données à vos partenaires : copiez les données d'un cluster Apache Kafka vers plusieurs clusters Apache Kafka, afin que les différents teams/partners aient leurs propres copies des données.
+ Agrégation des données à des fins d'analyse : copiez les données de plusieurs clusters Apache Kafka dans un seul cluster pour générer facilement des informations sur des données agrégées en temps réel.
+ Écrivez localement, accédez à vos données dans le monde entier : configurez la réplication multiactive pour propager automatiquement les écritures effectuées dans une AWS région vers d'autres régions afin de fournir des données à moindre latence et à moindre coût.
# Fonctionnement du réplicateur Amazon MSK
Pour commencer à utiliser MSK Replicator, vous devez créer un nouveau réplicateur dans la région de votre cluster cible. AWS *MSK Replicator copie automatiquement toutes les données du cluster de la AWS région principale appelée *source* vers le cluster de la région de destination appelée cible.* Les clusters source et cible peuvent se trouver dans la même région ou dans des AWS régions différentes. Vous devez créer le cluster cible s'il n'existe pas déjà.
Lorsque vous créez un réplicateur, MSK Replicator déploie toutes les ressources requises dans la AWS région du cluster cible afin d'optimiser la latence de réplication des données. La latence de réplication varie en fonction de nombreux facteurs, notamment la distance réseau entre AWS les régions de vos clusters MSK, la capacité de débit de vos clusters source et cible, et le nombre de partitions sur vos clusters source et cible. Le réplicateur MSK met automatiquement à l'échelle les ressources sous-jacentes afin que vous puissiez répliquer les données à la demande sans avoir à surveiller ou à mettre à l'échelle la capacité.
## Réplication des données
Par défaut, MSK Replicator copie toutes les données de manière asynchrone depuis le dernier décalage des partitions thématiques du cluster source vers le cluster cible. Si le paramètre « Détecter et copier les nouveaux sujets » est activé, MSK Replicator détecte et copie automatiquement les nouveaux sujets ou partitions de sujets dans le cluster cible. Cependant, le réplicateur peut prendre jusqu'à 30 secondes pour détecter et créer les nouveaux sujets ou partitions de sujets sur le cluster cible. Les messages envoyés au sujet source avant sa création sur le cluster cible ne seront pas répliqués. Vous pouvez également [configurer votre réplicateur lors de la création](msk-replicator-prepare-cluster.md) pour démarrer la réplication à partir du premier décalage dans les partitions des rubriques du cluster source si vous souhaitez répliquer les messages existants sur vos sujets vers le cluster cible.
MSK Replicator ne stocke pas vos données. Les données sont consommées à partir de votre cluster source, mises en mémoire tampon et écrites dans le cluster cible. La mémoire tampon est automatiquement effacée lorsque les données sont écrites avec succès ou échouent après de nouvelles tentatives. Toutes les communications et les données entre MSK Replicator et vos clusters sont toujours chiffrées en transit. Tous les appels d'API MSK Replicator tels que`DescribeClusterV2`,`CreateTopic`, `DescribeTopicDynamicConfiguration` sont capturés dans. AWS CloudTrail Les journaux de votre courtier MSK refléteront également la même chose.
MSK Replicator crée des sujets dans le cluster cible avec un facteur de réplication de 3. Si nécessaire, vous pouvez modifier le facteur de réplication directement sur le cluster cible.
## Réplication des métadonnées
MSK Replicator prend également en charge la copie des métadonnées du cluster source vers le cluster cible. Les métadonnées incluent la configuration des rubriques, les listes de contrôle d'accès (ACLs) et les décalages des groupes de consommateurs. Tout comme la réplication des données, la réplication des métadonnées s'effectue également de manière asynchrone. Pour de meilleures performances, MSK Replicator donne la priorité à la réplication des données plutôt qu'à la réplication des métadonnées.
Le tableau suivant répertorie les listes de contrôle d'accès (ACLs) copiées par MSK Replicator.
| Opération | Recherche | APIs autorisé |
| --- | --- | --- |
| Alter | Rubrique | CreatePartitions |
| AlterConfigs | Rubrique | AlterConfigs |
| Créer | Rubrique | CreateTopics, Métadonnées |
| Suppression | Rubrique | DeleteRecords, DeleteTopics |
| Décrire | Rubrique | ListOffsets, Métadonnées OffsetFetch, OffsetForLeaderEpoch |
| DescribeConfigs | Rubrique | DescribeConfigs |
| Lecture | Rubrique | Récupérez, OffsetCommit TxnOffsetCommit |
| Écrire (refuser uniquement) | Rubrique | Produire, AddPartitionsToTxn |
MSK Replicator copie le type de modèle LITERAL ACLs uniquement pour le type de ressource Topic. Le type de modèle PRÉFIXÉ ACLs et les autres types de ressources ne ACLs sont pas copiés. MSK Replicator ne supprime pas non plus ACLs le cluster cible. Si vous supprimez une ACL sur le cluster source, vous devez également la supprimer sur le cluster cible en même temps. Pour plus de détails sur les ACLs ressources, le modèle et les opérations de Kafka, consultez [https://kafka.apache.org/documentation/\$1security\$1authz\$1cli](https://kafka.apache.org/documentation/#security_authz_cli).
MSK Replicator ne réplique que Kafka ACLs, que le contrôle d'accès IAM n'utilise pas. Si vos clients utilisent le contrôle d'accès IAM read/write à vos clusters MSK, vous devez également configurer les politiques IAM pertinentes sur votre cluster cible pour un basculement fluide. Cela est également vrai pour les configurations de réplication avec préfixe et pour les configurations de réplication de noms de rubrique identiques.
Dans le cadre de la synchronisation des offsets des groupes de consommateurs, MSK Replicator est optimisé pour les clients du cluster source qui lisent à une position plus proche de la pointe du flux (fin de la partition thématique). Si vos groupes de consommateurs sont en retard sur le cluster source, vous constaterez peut-être un retard plus important pour ces groupes de consommateurs sur le cluster cible par rapport à la source. Cela signifie qu'après le basculement vers le cluster cible, vos clients retraiteront un plus grand nombre de messages dupliqués. Pour réduire ce décalage, vos clients du cluster source devraient rattraper leur retard et commencer à consommer dès le début du stream (fin de la partition thématique). Au fur et à mesure que vos clients rattrapent leur retard, MSK Replicator réduira automatiquement le décalage.
![\[Clusters source et cible du réplicateur MSK\]](http://docs.aws.amazon.com/fr_fr/msk/latest/developerguide/images/msk-replicator-diagram.png)
## Configuration du nom du sujet
MSK Replicator dispose de deux modes de configuration des noms de rubrique : Réplication *préfixée* (par défaut) ou Réplication de nom de rubrique *identique*.
**Réplication du nom de rubrique préfixé**
Par défaut, MSK Replicator crée de nouvelles rubriques dans le cluster cible avec un préfixe généré automatiquement ajouté au nom des rubriques du cluster source, tel que. `.topic` Cela permet de distinguer les sujets répliqués des autres sujets du cluster cible et d'éviter la réplication circulaire des données entre les clusters.
Par exemple, MSK Replicator réplique les données d'une rubrique nommée « rubrique » depuis le cluster source vers une nouvelle rubrique du cluster cible appelée < Alias>.topic. sourceKafkaCluster Vous trouverez le préfixe qui sera ajouté aux noms des rubriques dans le cluster cible dans le champ **sourceKafkaClusterAlias** à l'aide de l'`DescribeReplicator`API ou dans la page de détails du **réplicateur** sur la console MSK. Le préfixe du cluster cible est < sourceKafkaCluster Alias>.
Pour vous assurer que vos clients peuvent redémarrer le traitement de manière fiable depuis le cluster de secours, vous devez configurer vos clients pour qu'ils lisent les données des rubriques à l'aide d'un opérateur `.*` générique. Par exemple, vos consommateurs devraient consommer en utilisant. `*topic1`dans les deux AWS régions. Cet exemple inclurait également un sujet tel que`footopic1`, alors ajustez l'opérateur joker en fonction de vos besoins.
Vous devez utiliser le réplicateur MSK qui ajoute un préfixe lorsque vous souhaitez conserver les données du réplicateur dans une rubrique distincte du cluster cible, par exemple pour les configurations de clusters actifs-actifs.
**Réplication de noms de rubrique identiques**
Comme alternative au paramètre par défaut, Amazon MSK Replicator vous permet de créer un réplicateur dont la réplication de rubrique est définie sur Réplication du nom de rubrique identique (**conservez le même nom de rubrique dans la console**). Vous pouvez créer un nouveau réplicateur dans la AWS région où se trouve votre cluster MSK cible. Les rubriques répliquées portant le même nom vous permettent d'éviter de reconfigurer les clients pour qu'ils lisent des rubriques répliquées.
La réplication de noms de rubrique identiques (**conserver le même nom** de rubrique dans la console) présente les avantages suivants :
+ Vous permet de conserver des noms de rubrique identiques pendant le processus de réplication, tout en évitant automatiquement le risque de boucles de réplication infinies.
+ Simplifie la configuration et le fonctionnement des architectures de streaming multi-clusters, car vous pouvez éviter de reconfigurer les clients pour qu'ils lisent des extraits des rubriques répliquées.
+ Pour les architectures de clusters actifs-passifs, la fonctionnalité de réplication de noms de rubrique identiques rationalise également le processus de basculement, permettant aux applications de basculer facilement vers un cluster de secours sans qu'il soit nécessaire de modifier le nom des rubriques ou de reconfigurer le client.
+ Peut être utilisé pour consolider plus facilement les données de plusieurs clusters MSK en un seul cluster à des fins d'agrégation de données ou d'analyse centralisée. Cela vous oblige à créer des réplicateurs distincts pour chaque cluster source et le même cluster cible.
+ Peut rationaliser la migration des données d'un cluster MSK à un autre en répliquant les données vers des rubriques portant le même nom dans le cluster cible.
Amazon MSK Replicator utilise les en-têtes Kafka pour éviter automatiquement que les données ne soient répliquées vers le sujet dont elles proviennent, éliminant ainsi le risque de cycles infinis lors de la réplication. Un en-tête est une paire clé-valeur qui peut être incluse avec la clé, la valeur et l'horodatage dans chaque message Kafka. MSK Replicator intègre des identifiants pour le cluster source et le sujet dans l'en-tête de chaque enregistrement répliqué. MSK Replicator utilise les informations d'en-tête pour éviter des boucles de réplication infinies. Vous devez vérifier que vos clients sont capables de lire les données répliquées comme prévu.
# Tutoriel : Configuration des clusters source et cible pour Amazon MSK Replicator
Ce didacticiel explique comment configurer un cluster source et un cluster cible dans la même AWS région ou dans différentes AWS régions. Ensuite, vous utilisez ces clusters pour créer un réplicateur Amazon MSK.
# Préparez le cluster source Amazon MSK
Si vous avez déjà créé un cluster source MSK pour le réplicateur MSK, assurez-vous qu'il répond aux exigences décrites dans cette section. Dans le cas contraire, suivez ces étapes pour créer un cluster source provisionné par MSK ou sans serveur.
Le processus de création d'un cluster source de réplicateur MSK entre régions et mêmes régions est similaire. Les différences sont mises en évidence dans les procédures suivantes.
1. Créez un cluster MSK provisionné ou sans serveur avec le [contrôle d'accès IAM activé](create-iam-access-control-cluster-in-console.md) dans la région source. Votre cluster source doit avoir au moins trois agents.
1. Pour un réplicateur MSK entre régions, si la source est un cluster provisionné, configurez-le avec la connectivité privée multi-VPC activée pour les schémas de contrôle d'accès IAM. Notez que le type d'authentification non authentifié n'est pas pris en charge lorsque la connectivité multi-VPC est activée. Vous n'avez pas besoin d'activer la connectivité privée multi-VPC pour les autres schémas d'authentification (MTL) ou SASL/SCRAM). You can simultaneously use mTLS or SASL/SCRAM les schémas d'authentification pour vos autres clients qui se connectent à votre cluster MSK. Vous pouvez configurer la connectivité privée multi-VPC dans les détails du cluster de consoles, dans les **paramètres réseau** ou avec l'API `UpdateConnectivity`. Voir [Le propriétaire du cluster active le multi-VPC](mvpc-cluster-owner-action-turn-on.md). Si votre cluster source est un cluster MSK sans serveur, vous n'avez pas besoin d'activer la connectivité privée multi-VPC.
Pour un réplicateur MSK de même région, le cluster source MSK ne nécessite pas de connectivité privée multi-VPC et les autres clients peuvent toujours accéder au cluster en utilisant le type d'authentification non authentifié.
1. Pour les réplicateurs MSK entre régions, vous devez attacher une politique d'autorisations basée sur les ressources au cluster source. Cela permet à MSK de se connecter à ce cluster pour répliquer les données. Vous pouvez le faire à l'aide de la CLI ou des procédures de AWS console ci-dessous. Consultez également les [politiques basées sur les ressources d'Amazon MSK](security_iam_service-with-iam.md). Vous n'avez pas besoin d'effectuer cette étape pour les réplicateurs MSK de la même région.
------
#### [ Console: create resource policy ]
Mettez à jour la politique du cluster source avec le code JSON suivant. Remplacez l'espace réservé par l'ARN de votre cluster source.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"kafka.amazonaws.com"
]
},
"Action": [
"kafka:CreateVpcConnection",
"kafka:GetBootstrapBrokers",
"kafka:DescribeClusterV2"
],
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ab-cdef-1234567890ab-1"
}
]
}
```
Utilisez l'option **Modifier la politique du cluster** dans le menu **Actions** de la page des détails du cluster.
![\[Modifier la politique du cluster dans la console\]](http://docs.aws.amazon.com/fr_fr/msk/latest/developerguide/images/edit-cluster-policy.png)
------
#### [ CLI: create resource policy ]
Remarque : Si vous utilisez la AWS console pour créer un cluster source et que vous choisissez l'option permettant de créer un nouveau rôle IAM, vous AWS associez la politique de confiance requise au rôle. Si vous souhaitez que MSK utilise un rôle IAM existant ou si vous créez un rôle par vous-même, attachez les politiques d'approbation suivantes à ce rôle afin que le réplicateur MSK puisse l'assumer. Pour de plus amples informations sur la modification de la relation d'approbation d'un rôle, veuillez consulter [Modification d'un rôle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage_modify.html).
1. Obtenez la version actuelle de la politique de cluster MSK à l'aide de cette commande. Remplacez les espaces réservés par l'ARN du cluster réel.
```
aws kafka get-cluster-policy —cluster-arn
{
"CurrentVersion": "K1PA6795UKM GR7",
"Policy": "..."
}
```
1. Créez une politique basée sur les ressources pour autoriser le réplicateur MSK à accéder à votre cluster source. Utilisez la syntaxe suivante comme modèle, en remplaçant l'espace réservé par l'ARN du cluster source réel.
```
aws kafka put-cluster-policy --cluster-arn "" --policy '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"kafka.amazonaws.com"
]
},
"Action": [
"kafka:CreateVpcConnection",
"kafka:GetBootstrapBrokers",
"kafka:DescribeClusterV2"
],
"Resource": ""
}
]
```
------
# Préparez le cluster cible Amazon MSK
Créez un cluster cible MSK (provisionné ou sans serveur) avec le contrôle d'accès IAM activé. Le cluster cible ne nécessite pas l'activation de la connectivité privée multi-VPC. Le cluster cible peut se trouver dans la même AWS région ou dans une région différente de celle du cluster source. Les clusters source et cible doivent se trouver dans le même AWS compte. Votre cluster cible doit avoir au moins trois agents.
# Tutoriel : Création d'un réplicateur Amazon MSK
Après avoir configuré les clusters source et cible, vous pouvez les utiliser pour créer un Amazon MSK Replicator. Avant de créer le réplicateur Amazon MSK, assurez-vous que vous avez. [Autorisations IAM requises pour créer un réplicateur MSK](msk-replicator-requirements.md#replicator-role-permissions-successful)
**Contents**
+ [Considérations relatives à la création d'un Amazon MSK Replicator](msk-replicator-requirements.md)
+ [Autorisations IAM requises pour créer un réplicateur MSK](msk-replicator-requirements.md#replicator-role-permissions-successful)
+ [Types et versions de clusters pris en charge pour MSK Replicator](msk-replicator-supported-clusters-versions.md)
+ [Configuration de cluster sans serveur MSK prise en charge](msk-replicator-serverless-requirements.md)
+ [Modifications dans la configurations des clusters](msk-replicator-serverless-requirements.md#msk-replicator-config-changes)
+ [Créez un réplicateur à l'aide de la AWS console dans la région du cluster cible](msk-replicator-create-console.md)
+ [Choisissez votre cluster source](msk-replicator-create-console.md#msk-replicator-create-console-choose-source)
+ [Choisissez votre cluster cible](msk-replicator-create-console.md#msk-replicator-create-console-choose-target)
+ [Configurez les paramètres et les autorisations du réplicateur](msk-replicator-create-console.md#msk-replicator-create-settings)
# Considérations relatives à la création d'un Amazon MSK Replicator
Les sections suivantes donnent un aperçu des conditions préalables, des configurations prises en charge et des meilleures pratiques pour utiliser la fonctionnalité MSK Replicator. Il couvre les autorisations nécessaires, la compatibilité des clusters et les exigences spécifiques à Serverless, ainsi que des conseils sur la gestion du réplicateur après sa création.
## Autorisations IAM requises pour créer un réplicateur MSK
Voici un exemple de la politique IAM requise pour créer un réplicateur MSK. L'action `kafka:TagResource` n'est nécessaire que si des balises sont fournies lors de la création du réplicateur MSK. Les politiques IAM du réplicateur doivent être associées au rôle IAM correspondant à votre client. Pour plus d'informations sur la création de politiques d'autorisation, voir [Création de politiques d'autorisation](https://docs.aws.amazon.com/msk/latest/developerguide/iam-access-control.html#create-iam-access-control-policies).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "MSKReplicatorIAMPassRole",
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::123456789012:role/MSKReplicationRole",
"Condition": {
"StringEquals": {
"iam:PassedToService": "kafka.amazonaws.com"
}
}
},
{
"Sid": "MSKReplicatorServiceLinkedRole",
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::123456789012:role/aws-service-role/kafka.amazonaws.com/AWSServiceRoleForKafka*"
},
{
"Sid": "MSKReplicatorEC2Actions",
"Effect": "Allow",
"Action": [
"ec2:DescribeSubnets",
"ec2:DescribeSecurityGroups",
"ec2:DescribeVpcs",
"ec2:CreateNetworkInterface"
],
"Resource": [
"arn:aws:ec2:us-east-1:123456789012:subnet/subnet-0abcd1234ef56789",
"arn:aws:ec2:us-east-1:123456789012:security-group/sg-0123abcd4567ef89",
"arn:aws:ec2:us-east-1:123456789012:network-interface/eni-0a1b2c3d4e5f67890",
"arn:aws:ec2:us-east-1:123456789012:vpc/vpc-0a1b2c3d4e5f67890"
]
},
{
"Sid": "MSKReplicatorActions",
"Effect": "Allow",
"Action": [
"kafka:CreateReplicator",
"kafka:TagResource"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-56ef-78gh-90ij-klmnopqrstuv",
"arn:aws:kafka:us-east-1:123456789012:replicator/myReplicator/wxyz9876-54vu-32ts-10rq-ponmlkjihgfe"
]
}
]
}
```
------
Voici un exemple de politique IAM pour décrire le réplicateur. L'action `kafka:DescribeReplicator` ou l'action `kafka:ListTagsForResource` est nécessaire, pas les deux.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"kafka:DescribeReplicator",
"kafka:ListTagsForResource"
],
"Resource": "*"
}
]
}
```
------
# Types et versions de clusters pris en charge pour MSK Replicator
Il s'agit des exigences relatives aux types d'instances pris en charge, aux versions de Kafka et aux configurations réseau.
+ Le réplicateur MSK prend en charge à la fois les clusters provisionnés MSK et les clusters MSK sans serveur dans n'importe quelle combinaison en tant que clusters source et cible. Les autres types de clusters Kafka ne sont pas pris en charge pour le moment par le réplicateur MSK.
+ Les clusters MSK sans serveur nécessitent un contrôle d'accès IAM, ne prennent pas en charge la réplication ACL d'Apache Kafka et, avec une prise en charge limitée, la réplication de configuration sur site. Consultez [Qu'est-ce que MSK Serverless ?](serverless.md).
+ MSK Replicator n'est pris en charge que sur les clusters exécutant Apache Kafka 2.7.0 ou une version ultérieure, que vos clusters source et cible soient identiques ou différents. Régions AWS
+ MSK Replicator prend en charge les clusters utilisant des types d'instance de type m5.large ou supérieur. Les clusters t3.small ne sont pas pris en charge.
+ Si vous utilisez le réplicateur MSK avec un cluster MSK provisionné, vous avez besoin d'un minimum de trois agents dans les clusters source et cible. Vous pouvez répliquer les données entre des clusters situés dans deux zones de disponibilité, mais vous aurez besoin d'un minimum de quatre agents dans ces clusters.
+ Vos clusters MSK source et cible doivent se trouver dans le même AWS compte. La réplication entre clusters appartenant à différents comptes n'est pas prise en charge.
+ Si les clusters MSK source et cible se trouvent dans des AWS régions différentes (entre régions), MSK Replicator exige que la connectivité privée multi-VPC du cluster source soit activée pour sa méthode de contrôle d'accès IAM.
Le multi-VPC n'est pas requis pour les autres méthodes d'authentification sur le cluster source pour la réplication MSK entre deux. Régions AWS
Le multi-VPC n'est pas non plus requis si vous répliquez des données entre des clusters d'un même cluster. Région AWS Consultez [Connectivité privée à plusieurs VPC Amazon MSK dans une seule région](aws-access-mult-vpc.md).
+ La réplication de noms de **sujets identiques (conserver le même nom** de rubrique dans la console) nécessite un cluster MSK exécutant Kafka version 2.8.1 ou supérieure.
+ Pour les configurations de réplication de noms de rubrique identiques (**conserver le même nom** de rubrique dans la console), afin d'éviter le risque de réplication cyclique, ne modifiez pas les en-têtes créés par MSK Replicator (). `__mskmr`
# Configuration de cluster sans serveur MSK prise en charge
+ MSK sans serveur prend en charge la réplication de ces configurations de rubriques pour les clusters cibles MSK sans serveur lors de la création de rubriques : `cleanup.policy`, `compression.type`, `max.message.bytes`, `retention.bytes`, `retention.ms`.
+ MSK sans serveur prend uniquement en charge les configurations de rubriques suivantes lors de la synchronisation des configurations de rubriques : `compression.type`, `max.message.bytes`, `retention.bytes`, `retention.ms`.
+ Le réplicateur utilise 83 partitions compactées sur les clusters MSK sans serveur cibles. Assurez-vous que les clusters MSK sans serveur cibles disposent d'un nombre suffisant de partitions compactées. Consultez [Quota de MSK sans serveur](limits.md#serverless-quota).
## Modifications dans la configurations des clusters
+ Il est recommandé de ne pas activer ou désactiver le stockage hiérarchisé après la création du réplicateur MSK. Si votre cluster cible n'est pas hiérarchisé, MSK ne copiera pas les configurations de stockage hiérarchisé, que votre cluster source soit hiérarchisé ou non. Si vous activez le stockage hiérarchisé sur le cluster cible après la création du réplicateur, celui-ci doit être recréé. Si vous souhaitez copier des données d'un cluster non hiérarchisé vers un cluster hiérarchisé, vous ne devez pas copier les configurations des rubriques. Consultez la section [Activation et désactivation du stockage hiérarchisé sur une rubrique existante](https://docs.aws.amazon.com/msk/latest/developerguide/msk-enable-disable-topic-tiered-storage-cli.html).
+ Ne modifiez pas les paramètres de configuration du cluster après la création du réplicateur MSK. Les paramètres de configuration du cluster sont validés lors de la création du réplicateur MSK. Pour éviter tout problème avec le réplicateur MSK, ne modifiez pas les paramètres suivants une fois le réplicateur MSK créé.
+ Changez le cluster MSK en type d'instance t3.
+ Modifiez les autorisations de rôle d'exécution de service.
+ Désactivez la connectivité privée MSK multi-VPC.
+ Modifiez la politique basée sur les ressources du cluster attachée.
+ Modifiez les règles de groupe de sécurité du cluster.
# Créez un réplicateur à l'aide de la AWS console dans la région du cluster cible
La section suivante explique le flux de travail de console étape par étape pour créer un réplicateur.
**Détails du réplicateur**
1. [Dans la AWS région où se trouve votre cluster MSK cible, ouvrez-vous la console Amazon MSK chez https://console.aws.amazon.com/msk/ vous ? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Choisissez **Réplicateurs** pour afficher la liste des réplicateurs du compte.
1. Choisissez **Créer un réplicateur**.
1. Dans le volet **Détails du réplicateur**, attribuez un nom unique au nouveau réplicateur.
## Choisissez votre cluster source
Le cluster source contient les données que vous souhaitez copier vers un cluster MSK cible.
1. Dans le volet **Cluster source**, choisissez la région AWS dans laquelle se trouve le cluster source.
Vous pouvez rechercher la région d'un cluster en accédant à **Clusters MSK** et en consultant l'ARN des détails du **cluster**. Le nom de la région est intégré dans la chaîne ARN. Dans l'exemple d'ARN suivant, le cluster se trouve dans la région `ap-southeast-2`.
```
arn:aws:kafka:ap-southeast-2:123456789012:cluster/cluster-11/eec93c7f-4e8b-4baf-89fb-95de01ee639c-s1
```
1. Entrez l'ARN de votre cluster source ou naviguez pour choisir votre cluster source.
1. Choisissez un ou plusieurs sous-réseaux pour votre cluster source.
La console affiche les sous-réseaux disponibles dans la région du cluster source que vous pouvez sélectionner. Vous devez sélectionner au moins deux sous-réseaux. Pour un réplicateur MSK de même région, les sous-réseaux que vous sélectionnez définis pour accéder au cluster source et les sous-réseaux pour accéder au cluster cible doivent se trouver dans la même zone de disponibilité.
1. Choisissez un ou plusieurs groupes de sécurité pour que le MSK Replicator accède à votre cluster source.
+ Pour la réplication entre régions (CRR), il n'est pas nécessaire de fournir un ou plusieurs groupes de sécurité pour votre cluster source.
+ Pour la réplication dans la même région (SRR), accédez à la console Amazon EC2 https://console.aws.amazon.com/ec2/ à l'adresse et assurez-vous que les groupes de sécurité que vous fournirez au réplicateur disposent de règles de sortie autorisant le trafic vers les groupes de sécurité de votre cluster source. Assurez-vous également que les groupes de sécurité de votre cluster source disposent de règles entrantes qui autorisent le trafic provenant des groupes de sécurité Replicator fournis pour la source.
**Pour ajouter des règles de trafic entrant au groupe de sécurité de votre cluster source :**
1. Dans la AWS console, accédez aux détails de votre cluster source en sélectionnant le **nom du cluster**.
1. Sélectionnez l'onglet **Propriétés**, puis faites défiler l'écran jusqu'au volet des **paramètres réseau** pour sélectionner le nom du **groupe de sécurité** appliqué.
1. Accédez aux règles entrantes et sélectionnez **Modifier les règles entrantes**.
1. Sélectionnez **Ajouter une règle**.
1. Dans la colonne **Type** de la nouvelle règle, sélectionnez **TCP personnalisé**.
1. Dans la colonne **Plage de ports**, tapez`9098`. MSK Replicator utilise le contrôle d'accès IAM pour se connecter à votre cluster qui utilise le port 9098.
1. Dans la colonne **Source**, tapez le nom du groupe de sécurité que vous fournirez lors de la création du réplicateur pour le cluster source (il peut être identique au groupe de sécurité du cluster source MSK), puis sélectionnez **Enregistrer** les règles.
**Pour ajouter des règles de sortie au groupe de sécurité de Replicator fourni pour la source :**
1. Dans la AWS console pour Amazon EC2, accédez au groupe de sécurité que vous fournirez lors de la création du réplicateur pour la source.
1. Accédez aux règles sortantes et sélectionnez **Modifier les règles sortantes**.
1. Sélectionnez **Ajouter une règle**.
1. Dans la colonne **Type** de la nouvelle règle, sélectionnez **TCP personnalisé**.
1. Dans la colonne **Plage de ports**, tapez`9098`. MSK Replicator utilise le contrôle d'accès IAM pour se connecter à votre cluster qui utilise le port 9098.
1. Dans la colonne **Source**, tapez le nom du groupe de sécurité du cluster source MSK, puis sélectionnez **Enregistrer les règles**.
**Note**
Si vous ne souhaitez pas restreindre le trafic à l'aide de vos groupes de sécurité, vous pouvez également ajouter des règles entrantes et sortantes autorisant tout le trafic.
1. Sélectionnez **Ajouter une règle**.
2. Dans la colonne **Type**, choisissez **Tout le trafic**.
3. Dans la colonne Source, tapez `0.0.0.0/0`, puis sélectionnez **Enregistrer les règles**.
## Choisissez votre cluster cible
Le cluster cible est le cluster approvisionné par MSK ou le cluster sans serveur vers lequel les données sources sont copiées.
**Note**
Le réplicateur MSK crée de nouvelles rubriques dans le cluster cible avec un préfixe généré automatiquement ajouté au nom de la rubrique. Par exemple, le réplicateur MSK réplique les données dans « `topic` » du cluster source vers une nouvelle rubrique du cluster cible appelée `.topic`. Cela permet de distinguer les rubriques contenant des données répliquées à partir du cluster source des autres rubriques du cluster cible et d'éviter que les données ne soient répliquées de manière circulaire entre les clusters. Vous trouverez le préfixe qui sera ajouté aux noms des rubriques dans le cluster cible dans le champ **sourceKafkaClusterAlias** à l'aide de l'`DescribeReplicator`API ou dans la page de **détails du réplicateur** sur la console MSK. Le préfixe du cluster cible est``.
1. Dans le volet **Cluster cible**, choisissez la AWS région dans laquelle se trouve le cluster cible.
1. Entrez l'ARN de votre cluster cible ou naviguez pour choisir votre cluster cible.
1. Choisissez un ou plusieurs sous-réseaux pour votre cluster cible.
La console affiche les sous-réseaux disponibles dans la région du cluster cible que vous pouvez sélectionner. Sélectionnez au moins deux sous-réseaux.
1. Choisissez un ou plusieurs groupes de sécurité pour que le MSK Replicator accède à votre cluster cible.
Les groupes de sécurité disponibles dans la région du cluster cible sont affichés pour que vous puissiez les sélectionner. Le groupe de sécurité choisi est associé à chaque connexion. Pour plus d'informations sur l'utilisation des groupes de sécurité, consultez la section [Contrôlez le trafic vers vos AWS ressources à l'aide de groupes de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html) dans le *guide de l'utilisateur Amazon VPC*.
+ Pour la réplication entre régions (CRR) et pour la réplication entre régions (SRR), accédez à la console Amazon EC2 à l'adresse et assurez-vous que les groupes de sécurité que vous fournirez [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)au réplicateur disposent de règles de sortie autorisant le trafic vers les groupes de sécurité de votre cluster cible. Veillez également à ce que les groupes de sécurité de votre cluster cible disposent de règles entrantes qui autorisent le trafic vers les groupes de sécurité du réplicateur fournis pour la cible.
**Pour ajouter des règles de trafic entrant au groupe de sécurité de votre cluster cible :**
1. Dans la AWS console, accédez aux détails de votre cluster cible en sélectionnant le **nom du cluster**.
1. Sélectionnez l'onglet **Propriétés**, puis faites défiler l'écran jusqu'au volet des paramètres réseau pour sélectionner le nom du **groupe de sécurité** appliqué.
1. Accédez aux règles entrantes et sélectionnez **Modifier les règles entrantes**.
1. Sélectionnez **Ajouter une règle**.
1. Dans la colonne **Type** de la nouvelle règle, sélectionnez **TCP personnalisé**.
1. Dans la colonne **Plage de ports**, tapez`9098`. MSK Replicator utilise le contrôle d'accès IAM pour se connecter à votre cluster qui utilise le port 9098.
1. Dans la colonne **Source**, tapez le nom du groupe de sécurité que vous fournirez lors de la création du réplicateur pour le cluster cible (il peut être identique au groupe de sécurité du cluster cible MSK), puis sélectionnez **Enregistrer** les règles.
**Pour ajouter des règles de sortie au groupe de sécurité de Replicator fourni à la cible :**
1. Dans la AWS console, accédez au groupe de sécurité que vous allez fournir lors de la création du réplicateur pour la cible.
1. Sélectionnez l'onglet **Propriétés**, puis faites défiler l'écran jusqu'au volet des paramètres réseau pour sélectionner le nom du **groupe de sécurité** appliqué.
1. Accédez aux règles sortantes et sélectionnez **Modifier les règles sortantes**.
1. Sélectionnez **Ajouter une règle**.
1. Dans la colonne **Type** de la nouvelle règle, sélectionnez **TCP personnalisé**.
1. Dans la colonne **Plage de ports**, tapez`9098`. MSK Replicator utilise le contrôle d'accès IAM pour se connecter à votre cluster qui utilise le port 9098.
1. Dans la colonne **Source**, tapez le nom du groupe de sécurité du cluster cible MSK, puis sélectionnez **Enregistrer les règles**.
**Note**
Si vous ne souhaitez pas restreindre le trafic à l'aide de vos groupes de sécurité, vous pouvez également ajouter des règles entrantes et sortantes autorisant tout le trafic.
1. Sélectionnez **Ajouter une règle**.
2. Dans la colonne **Type**, choisissez **Tout le trafic**.
3. Dans la colonne Source, tapez `0.0.0.0/0`, puis sélectionnez **Enregistrer les règles**.
## Configurez les paramètres et les autorisations du réplicateur
1. Dans le volet **Paramètres du réplicateur**, spécifiez les rubriques que vous souhaitez répliquer à l'aide d'expressions régulières dans les listes d'autorisation et de refus. Par défaut, toutes les rubriques sont répliquées.
**Note**
MSK Replicator ne réplique que 750 sujets par ordre trié. Si vous devez répliquer d'autres rubriques, nous vous recommandons de créer un réplicateur distinct. Accédez au centre de support de la AWS console et [créez un dossier de support](https://console.aws.amazon.com/support/home#/) si vous avez besoin d'assistance pour plus de 750 sujets par réplicateur. Vous pouvez contrôler le nombre de sujets répliqués à l'aide de la métrique « TopicCount ». Consultez [Quota de courtiers Amazon MSK Standard](limits.md#msk-provisioned-quota).
1. Par défaut, MSK Replicator démarre la réplication à partir du *dernier* décalage (le plus récent) dans les rubriques sélectionnées. Vous pouvez également démarrer la réplication à partir du décalage le plus *ancien* (le plus ancien) des rubriques sélectionnées si vous souhaitez répliquer les données existantes sur vos rubriques. Une fois le réplicateur créé, vous ne pouvez pas modifier ce paramètre. Ce paramètre correspond au [https://docs.aws.amazon.com/msk/1.0/apireference-replicator/v1-replicators-replicatorarn.html#v1-replicators-replicatorarn-model-replicationstartingposition](https://docs.aws.amazon.com/msk/1.0/apireference-replicator/v1-replicators-replicatorarn.html#v1-replicators-replicatorarn-model-replicationstartingposition)champ de la [https://docs.aws.amazon.com/msk/1.0/apireference-replicator/v1-replicators.html#CreateReplicator](https://docs.aws.amazon.com/msk/1.0/apireference-replicator/v1-replicators.html#CreateReplicator)demande et de la [https://docs.aws.amazon.com/msk/1.0/apireference-replicator/v1-replicators-replicatorarn.html#DescribeReplicator](https://docs.aws.amazon.com/msk/1.0/apireference-replicator/v1-replicators-replicatorarn.html#DescribeReplicator)réponse APIs.
1. Choisissez une configuration de nom de rubrique :
+ `PREFIXED`réplication du nom du sujet (**ajoute un préfixe au nom du sujet** dans la console) : paramètre par défaut. MSK Replicator réplique le « topic1 » du cluster source vers un nouveau sujet du cluster cible portant le nom. `.topic1`
+ Réplication du nom de rubrique identique (**conservez le même nom** de rubrique dans la console) : les rubriques du cluster source sont répliquées avec des noms de rubrique identiques dans le cluster cible.
Ce paramètre correspond au `TopicNameConfiguration` champ de la `CreateReplicator` demande et de la `DescribeReplicator` réponse APIs. Consultez [Fonctionnement du réplicateur Amazon MSK](msk-replicator-how-it-works.md).
**Note**
Par défaut, MSK Replicator crée de nouveaux sujets dans le cluster cible avec un préfixe généré automatiquement ajouté au nom du sujet. Cela permet de distinguer les rubriques contenant des données répliquées à partir du cluster source des autres rubriques du cluster cible et d'éviter que les données ne soient répliquées de manière circulaire entre les clusters. Vous pouvez également créer un réplicateur MSK avec une réplication du nom de rubrique identique (**conserver le même nom de rubrique dans la console) afin que les noms des rubriques** soient préservés pendant la réplication. Cette configuration réduit le besoin de reconfigurer les applications clientes lors de l'installation et simplifie le fonctionnement des architectures de streaming multi-clusters.
1. Par défaut, MSK Replicator copie toutes les métadonnées, y compris les configurations des rubriques, les listes de contrôle d'accès (ACLs) et les décalages des groupes de consommateurs pour un basculement fluide. Si vous ne créez pas le réplicateur pour le basculement, vous pouvez éventuellement choisir de désactiver un ou plusieurs de ces paramètres disponibles dans la section **Paramètres supplémentaires**.
**Note**
MSK Replicator ne reproduit pas l'écriture, ACLs car vos producteurs ne doivent pas écrire directement sur le sujet répliqué dans le cluster cible. Vos producteurs doivent écrire sur la rubrique locale du cluster cible après le basculement. Consultez [Effectuer un basculement planifié vers la région secondaire AWS](msk-replicator-perform-planned-failover.md) pour plus de détails.
1. Dans le volet **Réplication de groupe de consommateurs**, spécifiez les groupes de consommateurs que vous souhaitez répliquer à l'aide d'expressions régulières dans les listes d'autorisation et de refus. Par défaut, tous les groupes de consommateurs sont répliqués.
1. Dans le volet **Compression**, vous pouvez éventuellement choisir de compresser les données écrites sur le cluster cible. Si vous comptez utiliser la compression, nous vous recommandons d'utiliser la même méthode de compression que les données de votre cluster source.
1. Dans le volet **Autorisations d'accès**, effectuez l'une des opérations suivantes :
1. Sélectionnez **Créer ou mettre à jour le rôle IAM avec les politiques requises**. La console MSK attachera automatiquement les autorisations et la politique d'approbation nécessaires au rôle d'exécution du service requis pour lire et écrire sur vos clusters MSK source et cible.
![\[Console MSK pour créer ou mettre à jour le rôle IAM du réplicateur\]](http://docs.aws.amazon.com/fr_fr/msk/latest/developerguide/images/msk-replicator-ezCRC.png)
1. Indiquez votre propre rôle IAM en sélectionnant **Choisir parmi les rôles IAM qu'Amazon MSK** peut assumer. Nous vous recommandons d'associer la stratégie IAM `AWSMSKReplicatorExecutionRole` gérée à votre rôle d'exécution de service, au lieu d'écrire votre propre stratégie IAM.
1. Créez le rôle IAM que le réplicateur utilisera pour lire et écrire sur vos clusters MSK source et cible avec le code JSON ci-dessous dans le cadre de la politique de confiance et le fichier `AWSMSKReplicatorExecutionRole` attaché au rôle. Dans la politique d'approbation, remplacez l'espace réservé par votre ID de compte réel.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "kafka.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": ""
}
}
}
]
}
```
------
1. Dans le volet **Balises du réplicateur**, vous pouvez éventuellement attribuer des balises à la ressource du réplicateur MSK. Pour de plus amples informations, veuillez consulter [Marquer un cluster Amazon MSK](msk-tagging.md). Pour un réplicateur MSK entre régions, les balises sont automatiquement synchronisées avec la région distante lors de la création du réplicateur. Si vous modifiez les balises après la création du réplicateur, la modification n'est pas automatiquement synchronisée avec la région distante. Vous devrez donc synchroniser manuellement les références du réplicateur local et du réplicateur distant.
1. Sélectionnez **Créer**.
Si vous souhaitez restreindre les `kafka-cluster:WriteData` autorisations, reportez-vous à la section *Créer des politiques d'autorisation* de [Comment fonctionne le contrôle d'accès IAM pour Amazon MSK](https://docs.aws.amazon.com/msk/latest/developerguide/iam-access-control.html#how-to-use-iam-access-control). Vous devez ajouter une `kafka-cluster:WriteDataIdempotently` autorisation au cluster source et au cluster cible.
Il faut environ 30 minutes pour que le réplicateur MSK soit créé et qu'il passe au statut RUNNING.
Si vous créez un nouveau réplicateur MSK pour remplacer un réplicateur que vous avez supprimé, le nouveau réplicateur démarre la réplication à partir du dernier décalage.
Si votre réplicateur MSK est passé au statut FAILED, reportez-vous à la section [Dépannage du réplicateur MSK](msk-replicator-troubleshooting.md).
# Modifier les paramètres du réplicateur MSK
Vous ne pouvez pas modifier le cluster source, le cluster cible, la position de départ du réplicateur ou la configuration de réplication du nom du sujet une fois le réplicateur MSK créé. Vous devez créer un nouveau réplicateur pour utiliser une configuration de réplication à nom de sujet identique. Vous pouvez toutefois modifier d'autres paramètres du Replicator, tels que les sujets et les groupes de consommateurs à répliquer.
1. Connectez-vous à la AWS Management Console console Amazon MSK et ouvrez-la [https://console.aws.amazon.com/msk/chez vous ? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Dans le volet de navigation de gauche, choisissez **Réplicateurs** pour afficher la liste des réplicateurs du compte et sélectionnez le réplicateur MSK que vous souhaitez modifier.
1. Choisissez l’onglet **Propriétés**.
1. Dans la section **Paramètres du réplicateur**, choisissez **Modifier le réplicateur**.
1. Vous pouvez modifier les paramètres du réplicateur MSK en modifiant n'importe lequel de ces paramètres.
+ Spécifiez les rubriques que vous souhaitez répliquer à l'aide d'expressions régulières dans les listes d'autorisation et de refus. Par défaut, MSK Replicator copie toutes les métadonnées, y compris les configurations des rubriques, les listes de contrôle d'accès (ACLs) et les décalages des groupes de consommateurs pour un basculement fluide. Si vous ne créez pas le réplicateur pour le basculement, vous pouvez éventuellement choisir de désactiver un ou plusieurs de ces paramètres disponibles dans la section **Paramètres supplémentaires**.
**Note**
MSK Replicator ne reproduit pas l'écriture, ACLs car vos producteurs ne doivent pas écrire directement sur le sujet répliqué dans le cluster cible. Vos producteurs doivent écrire sur la rubrique locale du cluster cible après le basculement. Consultez [Effectuer un basculement planifié vers la région secondaire AWS](msk-replicator-perform-planned-failover.md) pour plus de détails.
+ Pour la **réplication de groupes de consommateurs**, vous pouvez spécifier les groupes de consommateurs que vous souhaitez répliquer à l'aide d'expressions régulières dans les listes d'autorisation et de refus. Par défaut, tous les groupes de consommateurs sont répliqués. Si les listes d'autorisation et de refus sont vides, la réplication des groupes de consommateurs est désactivée.
+ Dans le volet **Type de compression cible**, vous pouvez éventuellement choisir de compresser les données écrites sur le cluster cible. Si vous comptez utiliser la compression, nous vous recommandons d'utiliser la même méthode de compression que les données de votre cluster source.
1. Enregistrez vos modifications.
Il faut environ 30 minutes pour que le réplicateur MSK soit créé et qu'il passe au statut RUNNING. Si votre réplicateur MSK est passé au statut FAILED, reportez-vous à la section [Résoudre les problèmes liés à MSK Replicator](msk-replicator-troubleshooting.md).
# Supprimer un réplicateur MSK
Vous devrez peut-être supprimer un réplicateur MSK s'il ne parvient pas à être créé (statut FAILED). Les clusters source et cible assignés à un réplicateur MSK ne peuvent pas être modifiés une fois le réplicateur MSK créé. Vous pouvez supprimer un réplicateur MSK existant et en créer un nouveau. Si vous créez un nouveau réplicateur MSK pour remplacer celui que vous avez supprimé, le nouveau réplicateur démarre la réplication à partir du dernier décalage.
1. Dans la AWS région où se trouve votre cluster source, connectez-vous à la AWS Management Console console Amazon MSK et ouvrez-la [https://console.aws.amazon.com/msk/chez vous ? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Dans le volet de navigation, sélectionnez **Réplicateurs**.
1. Dans la liste des réplicateurs MSK, sélectionnez celui que vous souhaitez supprimer, puis choisissez **Supprimer**.
# Surveiller la réplication
Vous pouvez l'utiliser [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)dans la région du cluster cible pour afficher les métriques pour `ReplicationLatency``MessageLag`, et `ReplicatorThroughput` au niveau thématique et agrégé pour chaque Amazon MSK Replicator. Les métriques sont visibles ci-dessous **ReplicatorName**dans l'espace de noms « AWS /Kafka ». Vous pouvez également voir les métriques `ReplicatorFailure`, `AuthError` et `ThrottleTime` pour vérifier les problèmes.
La console MSK affiche un sous-ensemble de CloudWatch métriques pour chaque réplicateur MSK. Dans la liste des **réplicateurs** de la console, sélectionnez le nom d'un réplicateur et sélectionnez l'onglet **Surveillance**.
## Métriques du réplicateur MSK
Les métriques suivantes décrivent les mesures de performance ou de connexion du réplicateur MSK.
AuthError les métriques ne couvrent pas les erreurs d'authentification au niveau du sujet. Pour surveiller les erreurs d'authentification au niveau thématique de votre MSK Replicator, surveillez les métriques du Replicator et ReplicationLatency les métriques thématiques du cluster source,. MessagesInPerSec Si un sujet passe ReplicationLatency à 0 mais que des données y sont toujours produites, cela indique que le réplicateur a un problème d'authentification avec le sujet. Vérifiez que le rôle IAM d'exécution du service du réplicateur dispose des autorisations suffisantes pour accéder à la rubrique.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/msk/latest/developerguide/msk-replicator-monitor.html)
# Utilisez la réplication pour augmenter la résilience d'une application de streaming Kafka dans toutes les régions
Vous pouvez utiliser MSK Replicator pour configurer des topologies de cluster actif-actif ou actif-passif afin d'accroître la résilience de votre application Apache Kafka dans toutes les régions. AWS Dans une configuration active-active, les deux clusters MSK effectuent activement des opérations de lecture et d'écriture. Dans une configuration active-passive, un seul cluster MSK à la fois diffuse activement des données, tandis que l'autre cluster est en veille.
## Considérations relatives à la création d'applications Apache Kafka multirégionales
Vos consommateurs doivent être en mesure de retraiter les messages dupliqués sans impact en aval. MSK Replicator réplique les données, at-least-once ce qui peut entraîner des doublons dans le cluster de secours. Lorsque vous passez à la AWS région secondaire, vos consommateurs peuvent traiter les mêmes données plusieurs fois. Le réplicateur MSK donne la priorité à la copie des données plutôt qu'aux décalages destinés aux consommateurs pour de meilleures performances. Après un basculement, le consommateur peut commencer à lire des décalages antérieurs, ce qui entraîne un double traitement.
Les producteurs et les consommateurs doivent également accepter de perdre un minimum de données. Comme MSK Replicator réplique les données de manière asynchrone, lorsque la AWS région principale commence à rencontrer des défaillances, il n'y a aucune garantie que toutes les données soient répliquées dans la région secondaire. Vous pouvez utiliser la latence de réplication pour déterminer le maximum de données qui n'ont pas été copiées dans la région secondaire.
## Utilisation d'une topologie de cluster actif-actif ou actif-passif
Une topologie de cluster actif-actif offre un temps de restauration proche de zéro et permet à votre application de streaming de fonctionner simultanément dans plusieurs régions AWS . Lorsqu'un cluster d'une région est endommagé, les applications connectées au cluster de l'autre région continuent de traiter les données.
Les configurations actives-passives sont adaptées aux applications qui ne peuvent s'exécuter que dans une seule région AWS à la fois, ou lorsque vous avez besoin d'un contrôle accru sur l'ordre de traitement des données. Les configurations actives-passives nécessitent un temps de restauration plus long que les configurations actives-actives, car vous devez démarrer l'ensemble de votre configuration active-passive, y compris vos producteurs et consommateurs, dans la région secondaire pour reprendre le streaming des données après un basculement.
# Créez une configuration de cluster Kafka actif-passif avec des configurations de dénomination de rubriques recommandées
Pour une configuration active-passive, nous vous recommandons d'utiliser une configuration similaire composée de producteurs, de clusters MSK et de consommateurs (portant le même nom de groupe de consommateurs) dans deux régions différentes. AWS Il est important que les deux clusters MSK aient une capacité de lecture et d'écriture identique pour garantir une réplication fiable des données. Vous devez créer un réplicateur MSK pour copier en continu les données du cluster principal vers le cluster de secours. Vous devez également configurer vos producteurs pour qu'ils écrivent des données dans les rubriques d'un cluster de la même AWS région.
Pour une configuration active-passive, créez un nouveau réplicateur avec une réplication de nom de rubrique identique (**conservez le même nom de rubrique** dans la console) pour commencer à répliquer les données de votre cluster MSK de la région principale vers votre cluster de la région secondaire. Nous vous recommandons de gérer un ensemble dupliqué de producteurs et de consommateurs dans les deux AWS régions, chacun se connectant au cluster de sa propre région à l'aide de sa chaîne bootstrap. Cela simplifie le processus de basculement, car il ne nécessite aucune modification de la chaîne de démarrage. Pour garantir que les consommateurs lisent là où ils se sont arrêtés, les consommateurs des clusters source et cible doivent avoir le même identifiant de groupe de consommateurs.
Si vous utilisez la réplication de noms de rubrique identiques (**conservez le même nom** de rubrique dans la console) pour votre MSK Replicator, il répliquera vos rubriques sous le même nom que les rubriques sources correspondantes.
Nous vous recommandons de configurer les paramètres et les autorisations au niveau du cluster pour vos clients sur le cluster cible. Il n'est pas nécessaire de configurer les paramètres au niveau des rubriques et la lecture littérale ACLs car MSK Replicator les copie automatiquement si vous avez sélectionné l'option permettant de copier les listes de contrôle d'accès. Consultez [Réplication des métadonnées](msk-replicator-how-it-works.md#msk-replicator-metadata-replication).
# Basculement vers la région secondaire AWS
Nous vous recommandons de surveiller la latence de réplication dans la AWS région secondaire à l'aide d'Amazon CloudWatch. Lors d'un événement de service dans la AWS région principale, la latence de réplication peut augmenter soudainement. Si la latence ne cesse d'augmenter, utilisez le AWS Service Health Dashboard pour vérifier les événements de service dans la AWS région principale. En cas d'événement, vous pouvez basculer vers la AWS région secondaire.
# Effectuer un basculement planifié vers la région secondaire AWS
Vous pouvez effectuer un basculement planifié pour tester la résilience de votre application face à un événement inattendu dans votre AWS région principale où se trouve votre cluster MSK source. Un basculement planifié ne doit pas entraîner de perte de données.
Si vous utilisez une configuration de réplication de nom de rubrique identique, procédez comme suit :
1. Arrêtez tous les producteurs et consommateurs qui se connectent à votre cluster source.
1. Créez un nouveau réplicateur MSK pour répliquer les données de votre cluster MSK de la région secondaire vers votre cluster MSK de la région principale avec une réplication de nom de rubrique identique (**conservez le même nom de rubrique dans la console).** Cette opération est nécessaire pour copier les données que vous allez écrire dans la région secondaire vers la région principale afin d'effectuer un failback vers la région principale une fois que l'événement inattendu est terminé.
1. Commencez par les producteurs et les consommateurs connectés au cluster cible dans la AWS région secondaire.
Si vous utilisez la configuration d'un nom de rubrique préfixé, procédez comme suit pour effectuer un basculement :
1. Arrêtez tous les producteurs et consommateurs qui se connectent à votre cluster source.
1. Créez un nouveau réplicateur MSK pour répliquer les données de votre cluster MSK de la région secondaire vers votre cluster MSK de la région principale. Cette opération est nécessaire pour copier les données que vous allez écrire dans la région secondaire vers la région principale afin d'effectuer un failback vers la région principale une fois que l'événement inattendu est terminé.
1. Démarrez les producteurs sur le cluster cible de la AWS région secondaire.
1. Selon les exigences d'ordre des messages de votre application, suivez les étapes décrites dans l'un des onglets suivants.
------
#### [ No message ordering ]
Si votre application ne nécessite pas de classement des messages, commencez par utiliser un opérateur générique (par exemple,) pour les clients de la AWS région secondaire qui lisent à la fois les sujets locaux (par exemple, le sujet`.topic`) et les sujets répliqués (par exemple,`.*topic`).
------
#### [ Message ordering ]
Si votre application nécessite un ordre des messages, démarrez les consommateurs uniquement pour les rubriques répliquées sur le cluster cible (par exemple, `.topic`), mais pas pour les rubriques locales (par exemple, `topic`).
------
1. Attendez que tous les consommateurs des rubriques répliquées sur le cluster MSK cible aient fini de traiter toutes les données, de sorte que le décalage des consommateurs soit égal à 0 et que le nombre d'enregistrements traités soit également égal à 0. Arrêtez ensuite les consommateurs pour les rubriques répliquées sur le cluster cible. À ce stade, tous les enregistrements répliqués du cluster MSK source vers le cluster MSK cible ont été consommés.
1. Démarrez les consommateurs pour les rubriques locales (par exemple, `topic`) sur le cluster MSK cible.
# Effectuer un basculement imprévu vers la région secondaire AWS
Vous pouvez effectuer un basculement imprévu lorsqu'un événement de service se produit dans la AWS région principale dans laquelle se trouve votre cluster MSK source et que vous souhaitez rediriger temporairement votre trafic vers la région secondaire dans laquelle se trouve votre cluster MSK cible. Un basculement imprévu peut entraîner des pertes de données car MSK Replicator réplique les données de manière asynchrone. Vous pouvez suivre le décalage des messages à l'aide des métriques contenues dans[Surveiller la réplication](msk-replicator-monitor.md).
Si vous utilisez une configuration de réplication de noms de rubrique identiques (**conservez le même nom** de rubrique dans la console), procédez comme suit :
1. Essayez de fermer tous les producteurs et consommateurs se connectant au cluster MSK source dans la région principale. Cette opération risque d'échouer en raison de déficiences dans cette région.
1. Commencez à connecter les producteurs et les consommateurs au cluster MSK cible dans la AWS région secondaire pour terminer le basculement. MSK Replicator répliquant également les métadonnées, notamment les décalages de lecture ACLs et de groupe de consommateurs, vos producteurs et consommateurs reprendront le traitement en toute fluidité là où ils s'étaient arrêtés avant le basculement.
Si vous utilisez la configuration du nom de `PREFIX` rubrique, procédez comme suit pour effectuer un basculement :
1. Essayez de fermer tous les producteurs et consommateurs se connectant au cluster MSK source dans la région principale. Cette opération risque d'échouer en raison de déficiences dans cette région.
1. Commencez à connecter les producteurs et les consommateurs au cluster MSK cible dans la AWS région secondaire pour terminer le basculement. MSK Replicator répliquant également les métadonnées, notamment les décalages de lecture ACLs et de groupe de consommateurs, vos producteurs et consommateurs reprendront le traitement en toute fluidité là où ils s'étaient arrêtés avant le basculement.
1. Selon les exigences d'ordre des messages de votre application, suivez les étapes décrites dans l'un des onglets suivants.
------
#### [ No message ordering ]
Si votre application ne nécessite pas de classement des messages, commencez par utiliser un opérateur générique (par exemple,`topic`) pour les consommateurs de la AWS région cible qui lisent à la fois des sujets locaux (par exemple`.topic`) et des sujets répliqués (par exemple,`.*topic`).
------
#### [ Message ordering ]
1. Démarrez les consommateurs uniquement pour les rubriques répliquées sur le cluster cible (par exemple, `.topic`), mais pas pour les rubriques locales (par exemple, `topic`).
1. Attendez que tous les consommateurs des rubriques répliquées sur le cluster MSK cible aient fini de traiter toutes les données, de sorte que le décalage soit égal à 0 et que le nombre d'enregistrements traités soit également égal à 0. Arrêtez ensuite les consommateurs pour les rubriques répliquées sur le cluster cible. À ce stade, tous les enregistrements répliqués du cluster MSK source vers le cluster MSK cible ont été consommés.
1. Démarrez les consommateurs pour les rubriques locales (par exemple, `topic`) sur le cluster MSK cible.
------
1. *Une fois l'événement de service terminé dans la région principale, créez un nouveau réplicateur MSK pour répliquer les données de votre cluster MSK de la région secondaire vers votre cluster MSK de la région principale, la position de départ du réplicateur étant définie au plus tôt.* Cette opération est nécessaire pour copier les données que vous allez écrire dans la région secondaire vers la région principale afin d'effectuer un failback vers la région principale une fois que l'événement est terminé. Si vous ne définissez pas la position de départ du réplicateur au *plus tôt*, les données que vous avez produites pour le cluster dans la région secondaire lors de l'événement de service dans la région principale ne seront pas copiées vers le cluster de la région principale.
# Effectuer un retour en arrière vers la région principale AWS
Vous pouvez revenir à la AWS région principale une fois que l'événement de service dans cette région est terminé.
Si vous utilisez une configuration de réplication de nom de rubrique identique, procédez comme suit :
1. Créez un nouveau réplicateur MSK avec votre cluster secondaire comme source et votre cluster principal comme cible, la position de départ étant définie sur la réplication la *plus ancienne* et le nom de rubrique identique (**conservez le même nom** de rubrique dans la console).
Cela lancera le processus de copie de toutes les données écrites sur le cluster secondaire après le basculement vers la région principale.
1. Surveillez la `MessageLag` métrique sur le nouveau réplicateur d'Amazon CloudWatch jusqu'à ce qu'elle soit atteinte`0`, ce qui indique que toutes les données ont été répliquées du secondaire au primaire.
1. Une fois que toutes les données ont été répliquées, arrêtez tous les producteurs de se connecter au cluster secondaire et démarrez les producteurs à se connecter au cluster principal.
1. Attendez que la `MaxOffsetLag` métrique que vos clients se connectent au cluster secondaire devienne `0` pour vous assurer qu'ils ont traité toutes les données. Consultez [Surveillez les retards des consommateurs](consumer-lag.md).
1. Une fois que toutes les données ont été traitées, arrêtez les consommateurs de la région secondaire et commencez à se connecter au cluster principal pour effectuer le retour en arrière.
1. Supprimez le réplicateur que vous avez créé lors de la première étape qui réplique les données de votre cluster secondaire vers le cluster principal.
1. Vérifiez que votre réplicateur existant copiant les données du cluster principal vers le cluster secondaire a le statut « EN COURS D'EXÉCUTION » et qu'il est `ReplicatorThroughput` métrique sur Amazon CloudWatch `0`.
Notez que lorsque vous créez un nouveau réplicateur dont la position de départ est la *plus ancienne* pour le retour en arrière, il commence à lire toutes les données figurant dans les rubriques de vos clusters secondaires. En fonction de vos paramètres de conservation des données, vos sujets peuvent contenir des données provenant de votre cluster source. Bien que MSK Replicator filtre automatiquement ces messages, vous devrez toujours payer des frais de traitement et de transfert pour toutes les données de votre cluster secondaire. Vous pouvez suivre le total des données traitées par le réplicateur à l'aide `ReplicatorBytesInPerSec` de. Consultez [Métriques du réplicateur MSK](msk-replicator-monitor.md#msk-replicator-metrics).
Si vous utilisez la configuration d'un nom de rubrique préfixé, procédez comme suit :
Vous ne devez lancer les étapes de retour en arrière qu'une fois que la réplication du cluster de la région secondaire vers le cluster de la région principale a rattrapé son retard et que la MessageLag métrique dans Amazon CloudWatch est proche de 0. Un failback planifié ne doit pas entraîner de perte de données.
1. Fermez tous les producteurs et consommateurs se connectant au cluster MSK source dans la région secondaire.
1. Pour une topologie active-passive, supprimez le réplicateur qui réplique les données du cluster de la région secondaire vers la région principale. Il n'est pas nécessaire de supprimer le réplicateur pour une topologie active-active.
1. Démarrez les producteurs qui se connectent au cluster MSK cible de la région secondaire.
1. Selon les exigences d'ordre des messages de votre application, suivez les étapes décrites dans l'un des onglets suivants.
------
#### [ No message ordering ]
Si votre application ne nécessite pas de classement des messages, commencez par utiliser un opérateur générique (par exemple,`topic`) pour les clients de la AWS région principale qui lisent à la fois des sujets locaux (par exemple`.topic`) et des sujets répliqués (par exemple,`.*topic`). Les consommateurs sur les rubriques locales (par exemple : topic) reprendront leur activité à partir du dernier décalage qu'ils ont consommé avant le basculement. S'il y avait des données non traitées avant le basculement, elles seront traitées maintenant. Dans le cas d'un basculement planifié, aucun enregistrement de ce type ne devrait exister.
------
#### [ Message ordering ]
1. Démarrez les consommateurs uniquement pour les rubriques répliquées sur la région principale (par exemple, `.topic`), mais pas pour les rubriques locales (par exemple, `topic`).
1. Attendez que tous les consommateurs des rubriques répliquées sur le cluster dans la région principale aient fini de traiter toutes les données, de sorte que le décalage soit égal à 0 et que le nombre d'enregistrements traités soit égal aussi à 0. Arrêtez ensuite les consommateurs pour les rubriques répliquées sur le cluster dans la région principale. À ce stade, tous les enregistrements produits dans la région secondaire après le basculement ont été consommés dans la région principale.
1. Démarrez les consommateurs pour les rubriques locales (par exemple, `topic`) sur le cluster dans la région principale.
------
1. Vérifiez que le réplicateur existant, du cluster de la région principale au cluster de la région secondaire, est en cours d'exécution et fonctionne comme prévu à l'aide des métriques `ReplicatorThroughput` et de latence.
# Création d'une configuration active-active à l'aide de MSK Replicator
Si vous souhaitez créer une configuration active-active dans laquelle les deux clusters MSK effectuent activement des opérations de lecture et d'écriture, nous vous recommandons d'utiliser un réplicateur MSK avec réplication de nom de rubrique préfixé (**ajoutez un préfixe au nom des rubriques dans la console**). Toutefois, cela vous obligera à reconfigurer vos clients pour qu'ils lisent les rubriques répliquées.
Procédez comme suit pour configurer une topologie active-active entre le cluster MSK source A et le cluster MSK cible B.
1. Créez un réplicateur MSK avec le cluster MSK A comme source et le cluster MSK B comme cible.
1. Une fois que le réplicateur MSK ci-dessus a été créé avec succès, créez un réplicateur avec le cluster B comme source et le cluster A comme cible.
1. Créez deux ensembles de producteurs, chacun écrivant des données en même temps dans la rubrique locale (par exemple, « topic ») dans le cluster situé dans la même région que le producteur.
1. Créez deux groupes de consommateurs, chacun lisant des données à l'aide d'un abonnement générique (tel que »). \$1topic ») du cluster MSK de la même AWS région que le consommateur. Ainsi, vos consommateurs liront automatiquement les données produites localement dans la région à partir de la rubrique locale (par exemple, `topic`), ainsi que les données répliquées depuis une autre région (dans la rubrique avec le préfixe `.topic`). Ces deux groupes de consommateurs doivent appartenir à des groupes de consommateurs différents IDs afin que les offsets des groupes de consommateurs ne soient pas remplacés lorsque MSK Replicator les copie sur l'autre cluster.
Si vous souhaitez éviter de reconfigurer vos clients, vous pouvez créer les réplicateurs MSK à l'aide de la réplication des noms de sujets **préfixés (ajoutez un préfixe au nom des sujets** dans la console) à l'aide d'une réplication de nom de sujet identique (**conservez le même nom de sujet dans la** console) pour créer une configuration active-active. Cependant, vous devrez payer des frais supplémentaires de traitement et de transfert de données pour chaque réplicateur. En effet, chaque réplicateur devra traiter deux fois plus de données que d'habitude, une fois pour la réplication et une autre pour éviter les boucles infinies. Vous pouvez suivre la quantité totale de données traitées par chaque réplicateur à l'aide de la `ReplicatorBytesInPerSec` métrique. Consultez [Surveiller la réplication](msk-replicator-monitor.md). Cette métrique inclut les données répliquées sur le cluster cible ainsi que les données filtrées par MSK Replicator afin d'éviter que les données ne soient copiées vers le même sujet d'origine.
**Note**
Si vous utilisez la réplication de noms de rubrique identiques (**conservez le même nom** de rubrique dans la console) pour configurer une topologie active-active, attendez au moins 30 secondes après avoir supprimé une rubrique avant de recréer une rubrique portant le même nom. Cette période d'attente permet d'éviter que les messages dupliqués ne soient répliqués vers le cluster source. Vos consommateurs doivent être en mesure de retraiter les messages dupliqués sans impact en aval. Consultez [Considérations relatives à la création d'applications Apache Kafka multirégionales](msk-replicator-increase-resiliency.md#msk-replication-multi-region-kafka-applications).
# Migrez d'un cluster Amazon MSK à un autre à l'aide de MSK Replicator
Vous pouvez utiliser la réplication de noms de rubrique identiques pour la migration de clusters, mais vos clients doivent être en mesure de gérer les messages dupliqués sans impact en aval. Cela est dû au fait que MSK Replicator assure at-least-once la réplication, ce qui peut entraîner la duplication de messages dans de rares cas. Si vos clients répondent à cette exigence, procédez comme suit.
1. Créez un réplicateur qui réplique les données de votre ancien cluster vers le nouveau cluster en définissant la position de départ du réplicateur sur le *plus tôt* et en utilisant une réplication de nom de rubrique identique (**conservez le même nom de rubrique dans la console**).
1. Configurez les paramètres et les autorisations au niveau du cluster sur le nouveau cluster. Il n'est pas nécessaire de configurer les paramètres thématiques et la lecture « littérale » ACLs, car MSK Replicator les copie automatiquement.
1. Surveillez la `MessageLag` métrique dans Amazon CloudWatch jusqu'à ce qu'elle atteigne 0, ce qui indique que toutes les données ont été répliquées.
1. Une fois que toutes les données ont été répliquées, empêchez les producteurs d'écrire des données dans l'ancien cluster.
1. Reconfigurez ces producteurs pour qu'ils se connectent au nouveau cluster et démarrez-les.
1. Surveillez `MaxOffsetLag` les indicateurs indiquant que vos clients lisent les données de l'ancien cluster jusqu'à ce qu'ils le deviennent`0`, ce qui indique que toutes les données existantes ont été traitées.
1. Arrêtez les consommateurs qui se connectent à l'ancien cluster.
1. Reconfigurez les consommateurs pour qu'ils se connectent au nouveau cluster et démarrez-les.
# Migrer de l'autogéré MirrorMaker 2 vers MSK Replicator
Pour migrer de MirrorMaker (MM2) vers MSK Replicator, procédez comme suit :
1. Arrêtez le producteur qui écrit sur votre cluster Amazon MSK source.
1. Permet MM2 de répliquer tous les messages relatifs aux rubriques de vos clusters sources. Vous pouvez surveiller le décalage entre consommateurs et MM2 consommateurs sur votre cluster MSK source afin de déterminer à quel moment toutes les données ont été répliquées.
1. Créez un nouveau réplicateur dont la position de départ est définie sur *Dernière* et la configuration du nom de sujet définie sur `IDENTICAL` (**Même nom de sujet, réplication** dans la console).
1. Une fois que votre réplicateur est en cours d'exécution, vous pouvez recommencer à écrire aux producteurs sur le cluster source.
# Résoudre les problèmes liés à MSK Replicator
La documentation suivante peut vous aider à résoudre les problèmes que vous pouvez rencontrer avec le réplicateur MSK. Consultez [Résoudre les problèmes liés à votre cluster Amazon MSK](troubleshooting.md) les informations relatives à la résolution des problèmes concernant 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 MSK passe de CREATING à FAILED
Les raisons courantes suivantes expliquent l'échec de création du réplicateur MSK.
1. Vérifiez que les groupes de sécurité que vous avez fourni pour la création du réplicateur dans la section du cluster cible comportent des règles de sortie autorisant le trafic vers les groupes de sécurité de votre cluster cible. Vérifiez également que les groupes de sécurité de votre cluster cible comportent des règles entrantes qui autorisent le trafic des groupes de sécurité que vous avez fournis pour la création du réplicateur dans la section du cluster cible. Consultez [Choisissez votre cluster cible](msk-replicator-create-console.md#msk-replicator-create-console-choose-target).
1. Si vous créez un réplicateur pour la réplication entre régions, vérifiez que la connectivité multi-VPC de votre cluster source est activée pour la méthode d'authentification du contrôle d'accès IAM. Consultez [Connectivité privée à plusieurs VPC Amazon MSK dans une seule région](aws-access-mult-vpc.md). Vérifiez également que la politique de cluster est configurée sur le cluster source afin que le réplicateur MSK puisse se connecter au cluster source. Consultez [Préparez le cluster source Amazon MSK](msk-replicator-prepare-cluster.md).
1. Vérifiez que le rôle IAM que vous avez fourni lors de la création du réplicateur MSK dispose des autorisations requises pour lire et écrire sur vos clusters source et cible. Vérifiez également que le rôle IAM dispose des autorisations nécessaires pour écrire dans les rubriques. Consultez [Configurez les paramètres et les autorisations du réplicateur](msk-replicator-create-console.md#msk-replicator-create-settings)
1. Vérifiez que votre réseau ACLs ne bloque pas la connexion entre le MSK Replicator et vos clusters source et cible.
1. Il est possible que les clusters source ou cible ne soient pas entièrement disponibles lorsque le réplicateur MSK a essayé de s'y connecter. Cela peut être dû à une charge excessive, à une utilisation du disque ou du processeur, ce qui empêche le réplicateur de se connecter aux agents. 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 MSK semble bloqué dans l'état CREATING
Parfois, la création du réplicateur MSK peut prendre jusqu'à 30 minutes. Attendez 30 minutes et vérifiez à nouveau l'état du réplicateur.
## Le réplicateur MSK ne réplique pas les données ou ne réplique que des données partielles
Suivez ces étapes pour résoudre les problèmes de réplication des données.
1. Vérifiez que votre réplicateur ne rencontre aucune erreur d'authentification à l'aide de la AuthError métrique fournie par MSK Replicator sur Amazon. CloudWatch Si cette métrique est supérieure à 0, vérifiez si la politique du rôle IAM fourni pour le réplicateur est valide et qu'aucune autorisation de refus n'est définie pour les autorisations du cluster. Sur la base de la dimension clusterAlias, vous pouvez identifier si le cluster source ou cible rencontre des erreurs d'authentification.
1. Vérifiez que vos clusters source et cible ne rencontrent aucun problème. Il est possible que le réplicateur ne soit pas en mesure de se connecter à votre cluster source ou cible. Cela peut être dû à un trop grand nombre de connexions, à une capacité maximale du disque ou à une utilisation élevée du processeur.
1. Vérifiez que vos clusters source et cible sont accessibles depuis MSK Replicator à l'aide de la KafkaClusterPingSuccessCount métrique d'Amazon. CloudWatch Sur la base de la dimension clusterAlias, vous pouvez identifier si le cluster source ou cible rencontre des erreurs d'authentification. Si la valeur est égale à 0 ou aucun point de données, la connexion n'est pas saine. Vous devez vérifier les autorisations réseau et de rôle IAM utilisées par le réplicateur MSK pour se connecter à vos clusters.
1. Vérifiez que votre réplicateur ne rencontre aucune défaillance en raison de l'absence d'autorisations thématiques à l'aide de la métrique d'Amazon ReplicatorFailure . CloudWatch Si cette métrique est supérieure à 0, vérifiez le rôle IAM que vous avez fourni pour les autorisations au niveau de la rubrique.
1. Vérifiez que l'expression régulière que vous avez fournie dans la liste d'autorisation lors de la création du réplicateur correspond aux noms des rubriques que vous souhaitez répliquer. Vérifiez également que les rubriques ne sont pas exclues de la réplication en raison d'une expression régulière présente dans la liste de refus.
1. Notez que le réplicateur peut prendre jusqu'à 30 secondes pour détecter et créer les nouveaux sujets ou partitions de sujets sur le cluster cible. Les messages envoyés au sujet source avant sa création sur le cluster cible ne seront pas répliqués si la position de départ du réplicateur est la plus récente (par défaut). Vous pouvez également démarrer la réplication à partir du premier décalage dans les partitions des rubriques du cluster source si vous souhaitez répliquer les messages existants relatifs à vos sujets sur le cluster cible. Consultez [Configurez les paramètres et les autorisations du réplicateur](msk-replicator-create-console.md#msk-replicator-create-settings).
## Les décalages de messages dans le cluster cible sont différents de ceux du cluster source
Dans le cadre de la réplication des données, MSK Replicator consomme les messages du cluster source et les transmet au cluster cible. Cela peut entraîner des messages présentant des décalages différents sur vos clusters source et cible. Toutefois, si vous avez activé la synchronisation des offsets des groupes de consommateurs lors de la création du réplicateur, MSK Replicator traduira automatiquement les décalages lors de la copie des métadonnées afin qu'après avoir basculé vers le cluster cible, vos clients puissent reprendre le traitement là où ils s'étaient arrêtés dans le cluster source.
## MSK Replicator ne synchronise pas les groupes de consommateurs, les offsets ou le groupe de consommateurs n'existe pas sur le cluster cible.
Suivez ces étapes pour résoudre les problèmes de réplication des métadonnées.
1. Vérifiez que la réplication de vos données fonctionne comme prévu. Si ce n’est pas le cas, voyez [Le réplicateur MSK ne réplique pas les données ou ne réplique que des données partielles](#msk-replicator-troubleshooting-not-replicating).
1. Vérifiez que l'expression régulière que vous avez fournie dans la liste d'autorisation lors de la création du réplicateur correspond aux noms des groupes de consommateurs que vous souhaitez répliquer. Vérifiez également que les groupes de consommateurs ne sont pas exclus de la réplication en raison d'une expression régulière dans la liste de refus.
1. Vérifiez que MSK Replicator a créé le sujet sur le cluster cible. Le réplicateur peut prendre jusqu'à 30 secondes pour détecter et créer les nouveaux sujets ou partitions de sujets sur le cluster cible. Les messages envoyés au sujet source avant sa création sur le cluster cible ne seront pas répliqués si la position de départ du réplicateur est la *plus récente* (par défaut). Si votre groupe de consommateurs du cluster source n'a consommé que les messages qui n'ont pas été répliqués par MSK Replicator, le groupe de consommateurs ne sera pas répliqué vers le cluster cible. Une fois le sujet créé avec succès sur le cluster cible, MSK Replicator commence à répliquer les messages récemment écrits sur le cluster source vers la cible. Une fois que votre groupe de consommateurs commence à lire ces messages depuis la source, MSK Replicator répliquera automatiquement le groupe de consommateurs vers le cluster cible. Vous pouvez également démarrer la réplication à partir du premier décalage dans les partitions des rubriques du cluster source si vous souhaitez répliquer les messages existants relatifs à vos sujets sur le cluster cible. Consultez [Configurez les paramètres et les autorisations du réplicateur](msk-replicator-create-console.md#msk-replicator-create-settings).
**Note**
MSK Replicator optimise la synchronisation des décalages des groupes de consommateurs pour vos clients du cluster source qui lisent à une position plus proche de la fin de la partition thématique. Si vos groupes de consommateurs sont en retard sur le cluster source, vous constaterez peut-être un retard plus important pour ces groupes de consommateurs sur le cluster cible par rapport à la source. Cela signifie qu'après le basculement vers le cluster cible, vos clients retraiteront un plus grand nombre de messages dupliqués. Pour réduire ce décalage, vos clients du cluster source devraient rattraper leur retard et commencer à consommer dès le début du stream (fin de la partition thématique). 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
Les raisons courantes suivantes expliquent une latence de réplication élevée.
1. Vérifiez que vous disposez du bon nombre de partitions sur vos clusters MSK source et cible. Le fait d'avoir trop peu ou trop de partitions peut avoir un impact sur les performances. Pour obtenir des conseils sur le choix du nombre de partitions, reportez-vous à la section [Bonnes pratiques pour l'utilisation du réplicateur MSK](msk-replicator-best-practices.md). Le tableau suivant indique le nombre minimum de partitions recommandé pour obtenir le débit souhaité avec le réplicateur MSK.
**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 vous disposez d'une capacité de lecture et d'écriture suffisante dans vos clusters MSK source et cible pour prendre en charge le trafic de réplication. 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). Par conséquent, vous devez prévoir une capacité de cluster pour prendre en charge le trafic de réplication en plus du reste du trafic sur vos clusters. Pour obtenir des conseils sur le dimensionnement correct de votre cluster, consultez [Bonnes pratiques pour l'utilisation du réplicateur MSK](msk-replicator-best-practices.md).
1. La latence de réplication peut varier pour les clusters MSK dans différentes paires de AWS régions source et de destination, en fonction de la distance géographique entre les clusters. Par exemple, la latence de réplication est généralement inférieure lors de la réplication entre clusters des régions Europe (Irlande) et Europe (Londres) par rapport à la réplication entre clusters des régions Europe (Irlande) et Asie-Pacifique (Sydney).
1. Vérifiez que votre réplicateur n'est pas limité en raison de quotas trop agressifs définis sur vos clusters source ou cible. Vous pouvez utiliser la ThrottleTime métrique fournie par MSK Replicator sur Amazon CloudWatch pour connaître le temps moyen en millisecondes pendant lequel une demande a été limitée par les courtiers de votre cluster. source/target Si cette métrique est supérieure à 0, vous devez ajuster les quotas de Kafka pour réduire la limitation afin que le réplicateur puisse rattraper son retard. Consultez [Gestion du débit du réplicateur MSK à l'aide des quotas de Kafka](msk-replicator-best-practices.md#msk-replicator-manage-throughput-kafka-quotas) pour plus d'informations sur la gestion des quotas de Kafka pour le réplicateur.
1. ReplicationLatency et MessageLag peut augmenter lorsqu'une AWS région se dégrade. Utilisez le [Tableau de bord de l'état des services AWS](https://health.aws.amazon.com/health/status) pour vérifier la présence d'un événement de service MSK dans la région où se trouve votre cluster MSK principal. En cas d'événement de service, vous pouvez rediriger temporairement les opérations de lecture et d'écriture de votre application dans l'autre région.
## Résolution des défaillances de MSK Replicator à l'aide de métriques ReplicatorFailure
La ReplicatorFailure métrique vous aide à surveiller et à détecter les problèmes de réplication dans MSK Replicator. Une valeur différente de zéro de cette métrique indique généralement un problème d'échec de réplication, qui peut être dû aux facteurs suivants :
+ limites de taille des messages
+ violations de la plage d'horodatage
+ problèmes de taille de lot d'enregistrements
Si la ReplicatorFailure métrique indique une valeur différente de zéro, procédez comme suit pour résoudre le problème.
**Note**
Pour plus d’informations sur cette métrique, consultez [Métriques du réplicateur MSK](msk-replicator-monitor.md#msk-replicator-metrics).
1. Configurez un client capable de se connecter au cluster MSK cible et doté des outils de la CLI Apache Kafka. Pour plus d'informations sur la configuration du client et de l'outil Kafka CLI, consultez[Connectez-vous à un cluster Amazon MSK Provisioned](client-access.md).
1. Vous voulez ouvrir la console Amazon MSK [https://console.aws.amazon.com/msk/chez vous ? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
Ensuite, procédez comme suit :
1. Obtenez le ARNs MSK Replicator et le cluster MSK cible.
1. [Obtenez les points de terminaison du broker](get-bootstrap-console.md) du cluster MSK cible. Vous allez utiliser ces points de terminaison dans les étapes suivantes.
1. Exécutez les commandes suivantes pour exporter l'ARN MSK Replicator et les points de terminaison du broker que vous avez obtenus à l'étape précédente.
Assurez-vous de remplacer les valeurs d'espace réservé pour < *ReplicatorARN* >, < *BootstrapServerString* > et < *ConsumerConfigFile* > utilisées dans les exemples suivants par leurs valeurs réelles.
```
export TARGET_CLUSTER_SERVER_STRING=
```
```
export REPLICATOR_ARN=
```
```
export CONSUMER_CONFIG_FILE=
```
1. Dans votre `/bin` répertoire, procédez comme suit :
1. Enregistrez le script suivant et nommez-le**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 ./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
```
1. 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. Vous pouvez utiliser ces informations d'exception pour atténuer les défaillances, comme décrit dans[Défaillances courantes du réplicateur MSK et leurs solutions](#msk-replicator-ReplicatorFailure-error-mitigation). 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 du réplicateur MSK et leurs solutions
La liste suivante décrit certaines des défaillances de MSK Replicator que vous pourriez rencontrer et comment les atténuer.
**Taille du message supérieure à max.request.size**
**Cause**
Cet échec se produit lorsque le MSK Replicator ne parvient pas à répliquer les données parce que la taille de chaque message dépasse 10 Mo. Par défaut, MSK Replicator réplique les messages d'une taille maximale de 10 Mo.
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 n'êtes pas en mesure de le faire, suivez ces instructions pour [demander une augmentation de limite](limits.md#request-msk-quota-increase).
**Taille du message supérieure à la taille maximale des messages que le serveur acceptera**
**Cause**
Cet échec se produit lorsque 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 cible ou sur la rubrique correspondante du cluster cible. Définissez la `max.message.bytes` configuration du cluster cible pour qu'elle corresponde à la taille de votre message non compressé le plus important. Pour plus d'informations à ce sujet, consultez [max.message.bytes.](https://kafka.apache.org/documentation/#topicconfigs_max.message.bytes)
**L'horodatage est hors de portée**
**Cause**
Cet échec se produit parce que l'horodatage du message individuel 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 pour autoriser les messages avec des horodatages plus anciens. Pour plus d'informations à ce sujet, consultez [message.timestamp.before.max.ms](https://kafka.apache.org/documentation/#topicconfigs_message.timestamp.before.max.ms).
**Le lot d'enregistrements est trop volumineux**
**Cause**
Cet échec se produit parce que 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**
La configuration segment.bytes du cluster cible doit être au moins aussi grande que la taille du lot (1 Mo) pour que Replicator fonctionne sans erreur. Mettez à jour le segment.bytes du cluster cible pour qu'il soit d'au moins 1048576 (1 Mo). Pour plus d'informations à ce sujet, consultez [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.
# Bonnes pratiques pour l'utilisation du réplicateur MSK
Cette section décrit les meilleures pratiques courantes et les stratégies de mise en œuvre relatives à l'utilisation d'Amazon MSK Replicator.
**Contents**
+ [Gestion du débit du réplicateur MSK à l'aide des quotas de Kafka](#msk-replicator-manage-throughput-kafka-quotas)
+ [Définition de la période de conservation des données des clusters](#msk-replicator-retention-period)
## Gestion du débit du réplicateur MSK à l'aide des quotas de Kafka
Comme le réplicateur MSK agit en tant que consommateur pour votre cluster source, la réplication peut entraîner une limitation des autres consommateurs sur votre cluster source. Le niveau de limitation dépend de la capacité de lecture dont dispose votre cluster source et du débit des données que vous répliquez. Nous vous recommandons de fournir une capacité identique pour vos clusters source et cible, et de prendre en compte le débit de réplication lors du calcul de la capacité dont vous avez besoin.
Vous pouvez également définir des quotas Kafka pour le réplicateur sur vos clusters source et cible afin de contrôler la capacité que le réplicateur MSK peut utiliser. Un quota de bande passante du réseau est recommandé. Un quota de bande passante du réseau définit un seuil de débit, défini en octets par seconde, pour un ou plusieurs clients partageant un quota. Ce quota est défini sur une base par agent.
Suivez ces étapes pour appliquer un quota.
1. Récupérez la chaîne du serveur d'amorçage pour le cluster source. Consultez [Obtenez les courtiers bootstrap pour un cluster Amazon MSK](msk-get-bootstrap-brokers.md).
1. Récupérez le rôle d'exécution de service (SER) utilisé par le réplicateur MSK. Il s'agit du SER que vous avez utilisé pour une demande `CreateReplicator`. Vous pouvez également extraire le SER de la DescribeReplicator réponse d'un réplicateur existant.
1. À l'aide des outils de l'interface de ligne de commande Kafka, exécutez la commande suivante sur le cluster source.
```
./kafka-configs.sh --bootstrap-server --alter --add-config 'consumer_byte_
rate=' --entity-type users --entity-name arn:aws:sts:::assumed-role// --command-config
```
1. Après avoir exécuté la commande ci-dessus, vérifiez que la métrique `ReplicatorThroughput` ne dépasse pas le quota que vous avez défini.
Notez que si vous réutilisez un rôle d'exécution de service entre plusieurs réplicateurs MSK, ils seront tous soumis à ce quota. Si vous souhaitez conserver des quotas distincts par réplicateur, utilisez des rôles d'exécution de service distincts.
Pour plus d'informations sur l'utilisation de l'authentification IAM de MSK avec des quotas, consultez [Clusters Apache Kafka multi-locataires dans Amazon MSK avec contrôle d'accès IAM et Quotas de Kafka — 1e partie](https://aws.amazon.com/blogs/big-data/multi-tenancy-apache-kafka-clusters-in-amazon-msk-with-iam-access-control-and-kafka-quotas-part-1/).
**Avertissement**
Si vous définissez un consumer\$1byte\$1rate extrêmement bas, votre réplicateur MSK peut agir de manière inattendue.
## Définition de la période de conservation des données des clusters
Vous pouvez définir la période de conservation des journaux pour les clusters provisionnés par MSK et les clusters sans serveur. La période de conservation par défaut est de 7 jours. Voir [Modifications dans la configurations des clusters](msk-replicator-serverless-requirements.md#msk-replicator-config-changes) ou [Configuration de cluster sans serveur MSK prise en charge](msk-replicator-serverless-requirements.md).