Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Was ist Amazon MSK Replicator?
Amazon MSK Replicator ist eine Amazon MSK-Funktion, mit der Sie Daten zuverlässig zwischen Amazon MSK-Clustern in verschiedenen oder denselben replizieren können. AWS-Region Sowohl der Quell- als auch der Zielcluster müssen sich jedoch im selben Cluster befinden. AWS-Konto Mit MSK-Replikator können Sie auf einfache Weise regional belastbare Streaming-Anwendungen erstellen, um die Verfügbarkeit und Geschäftskontinuität zu erhöhen. MSK-Replikator bietet automatische asynchrone Replikation über MSK-Cluster hinweg, sodass Sie keinen benutzerdefinierten Code schreiben, die Infrastruktur verwalten oder regionsübergreifende Netzwerke einrichten müssen.
MSK-Replikator skaliert automatisch die zugrunde liegenden Ressourcen, sodass Sie Daten bei Bedarf replizieren können, ohne die Kapazität überwachen oder skalieren zu müssen. MSK Replicator repliziert auch die erforderlichen Kafka-Metadaten, einschließlich Themenkonfigurationen, Zugriffskontrolllisten (ACLs) und Nutzergruppen-Offsets. Wenn in einer Region ein unerwartetes Ereignis eintritt, können Sie ein Failover auf die andere AWS Region durchführen und die Verarbeitung problemlos fortsetzen.
MSK-Replikator unterstützt sowohl die regionsübergreifende Replikation (CRR) als auch die regionsinterne Replikation (SRR). Bei der regionsübergreifenden Replikation befinden sich die MSK-Quell- und Zielcluster in unterschiedlichen Regionen. AWS Bei der Replikation in derselben Region befinden sich sowohl der Quell- als auch der Ziel-MSK-Cluster in derselben Region. AWS Sie müssen Quell- und Ziel-MSK-Cluster erstellen, bevor Sie sie mit MSK-Replikator verwenden können.
**Anmerkung**
MSK Replicator unterstützt die folgenden AWS Regionen: USA Ost (us-east-1, Nord-Virginia); USA Ost (us-east-2, Ohio); USA West (us-west-2, Oregon); Europa (eu-west-1, Irland); Europa (eu-central-1, Frankfurt); Asien-Pazifik (ap-southeast-1, Singapur); Asien-Pazifik (ap-southeast-2, Sydney); Europa (eu-north-1, Stockholm); Asien-Pazifik (ap-south-1, Mumbai); Europa (eu-west-3, Paris); Südamerika (sa-east-1, São Paulo); Asien-Pazifik (ap-northeast-2, Seoul); Europa (eu-west-2, London); Asien-Pazifik (ap-northeast-1, Tokio); USA West (us-west-1, Nordkalifornien); Kanada (ca-central-1, Central); China (Peking) (cn-north-1); China (Ningxia) (cn-northwest-1); Asien-Pazifik (Hyderabad) (ap-south-2), Asien-Pazifik (Malaysia) (ap-southeast-5), Asien-Pazifik (Thailand) (ap-southeast-7), Mexiko (zentral) (mx-central-1), Asien-Pazifik (Taipeh) (ap-east-2), Kanada West (Calgary) (ca-west-1), Europa (Spanien) (eu-south-2), Naher Osten (Bahrain) (me-south-1), Asien-Pazifik (Jakarta) (ap-southeast-3), Afrika (Kapstadt) (af-south-1), Naher Osten (UAE) (me-central-1), Asien-Pazifik (Hongkong) (ap-east-1), Asien-Pazifik (Osaka) (ap-northeast-3), Asien Pazifik (Melbourne) (ap-southeast-4), Europa (Mailand) (eu-south-1), Israel (Tel Aviv) (il-central-1), Europa (Zürich) (eu-central-2) und Asien-Pazifik (Neuseeland) (ap-southeast-6)
Im Folgenden finden Sie einige häufig verwendete Anwendungen für Amazon MSK Replicator.
+ Streaming-Anwendungen für mehrere Regionen erstellen: Erstellen Sie hochverfügbare und fehlertolerante Streaming-Anwendungen für mehr Stabilität, ohne benutzerdefinierte Lösungen einrichten zu müssen.
+ Datenzugriff mit niedrigerer Latenz: Bieten Sie Verbrauchern in verschiedenen geografischen Regionen Datenzugriff mit niedrigerer Latenz.
+ Verteilen Sie Daten an Ihre Partner: Kopieren Sie Daten von einem Apache Kafka-Cluster in viele Apache Kafka-Cluster, sodass verschiedene teams/partners über eigene Datenkopien verfügen.
+ Daten für Analysen aggregieren: Kopieren Sie Daten aus mehreren Apache-Kafka-Clustern in einen Cluster, um auf einfache Weise Einblicke in aggregierte Echtzeitdaten zu gewinnen.
+ Lokal schreiben, global auf Ihre Daten zugreifen: Richten Sie eine multiaktive Replikation ein, um in einer AWS Region durchgeführte Schreibvorgänge automatisch auf andere Regionen zu übertragen, um Daten mit geringerer Latenz und geringeren Kosten bereitzustellen.
# Funktionsweise von Amazon MSK Replicator
Um mit MSK Replicator zu beginnen, müssen Sie einen neuen Replicator in der Region Ihres Zielclusters erstellen. AWS *MSK Replicator kopiert automatisch alle Daten aus dem Cluster in der primären AWS Region, die als *Quelle* bezeichnet wird, in den Cluster in der Zielregion, der Zielregion genannt wird.* Quell- und Zielcluster können sich in derselben oder in unterschiedlichen AWS Regionen befinden. Sie müssen den Ziel-Cluster erstellen, wenn er nicht bereits vorhanden ist.
Wenn Sie einen Replikator erstellen, stellt MSK Replicator alle erforderlichen Ressourcen in der AWS Region des Zielclusters bereit, um die Latenz bei der Datenreplikation zu optimieren. Die Replikationslatenz hängt von vielen Faktoren ab, darunter der Netzwerkentfernung zwischen den AWS Regionen Ihrer MSK-Cluster, der Durchsatzkapazität Ihrer Quell- und Zielcluster und der Anzahl der Partitionen auf Ihren Quell- und Zielclustern. MSK-Replikator skaliert automatisch die zugrunde liegenden Ressourcen, sodass Sie Daten bei Bedarf replizieren können, ohne die Kapazität überwachen oder skalieren zu müssen.
## Datenreplikation
Standardmäßig kopiert MSK Replicator alle Daten asynchron vom letzten Offset in den Themenpartitionen des Quellclusters in den Zielcluster. Wenn die Einstellung „Neue Themen erkennen und kopieren“ aktiviert ist, erkennt MSK Replicator automatisch neue Themen oder Themenpartitionen und kopiert sie in den Zielcluster. Es kann jedoch bis zu 30 Sekunden dauern, bis der Replicator die neuen Themen oder Themenpartitionen auf dem Zielcluster erkennt und erstellt. Alle Nachrichten, die an das Quellthema gesendet wurden, bevor das Thema auf dem Zielcluster erstellt wurde, werden nicht repliziert. Alternativ können Sie [Ihren Replicator bei der Erstellung so konfigurieren](msk-replicator-prepare-cluster.md), dass die Replikation ab dem frühesten Offset in den Themenpartitionen des Quellclusters gestartet wird, wenn Sie vorhandene Nachrichten zu Ihren Themen auf den Zielcluster replizieren möchten.
MSK Replicator speichert Ihre Daten nicht. Daten werden aus Ihrem Quellcluster abgerufen, im Arbeitsspeicher gepuffert und in den Zielcluster geschrieben. Der Puffer wird automatisch gelöscht, wenn die Daten entweder erfolgreich geschrieben wurden oder nach erneuten Versuchen fehlschlagen. Die gesamte Kommunikation und die Daten zwischen MSK Replicator und Ihren Clustern werden bei der Übertragung immer verschlüsselt. Alle MSK Replicator API-Aufrufe wie`DescribeClusterV2`,, `CreateTopic` werden in erfasst. `DescribeTopicDynamicConfiguration` AWS CloudTrail Ihre MSK-Broker-Protokolle werden dasselbe widerspiegeln.
MSK Replicator erstellt Themen im Zielcluster mit einem Replicator-Faktor von 3. Bei Bedarf können Sie den Replikationsfaktor direkt auf dem Zielcluster ändern.
## Replikation von Metadaten
MSK Replicator unterstützt auch das Kopieren der Metadaten vom Quellcluster in den Zielcluster. Zu den Metadaten gehören Themenkonfiguration, Zugriffskontrolllisten (ACLs) und Offsets für Nutzergruppen. Wie die Datenreplikation erfolgt auch die Metadatenreplikation asynchron. Um eine bessere Leistung zu erzielen, priorisiert MSK Replicator die Datenreplikation gegenüber der Metadatenreplikation.
Die folgende Tabelle enthält eine Liste der Zugriffskontrolllisten (ACLs), die MSK Replicator kopiert.
| Operation | Forschung | APIs erlaubt |
| --- | --- | --- |
| Ändern | Thema | CreatePartitions |
| AlterConfigs | Thema | AlterConfigs |
| Create | Thema | CreateTopics, Metadaten |
| Delete | Thema | DeleteRecords, DeleteTopics |
| Describe | Thema | ListOffsets, Metadaten OffsetFetch, OffsetForLeaderEpoch |
| DescribeConfigs | Thema | DescribeConfigs |
| Lesen | Thema | Abrufen,, OffsetCommit TxnOffsetCommit |
| Schreiben (nur ablehnen) | Thema | Produzieren, AddPartitionsToTxn |
MSK Replicator kopiert den Mustertyp LITERAL ACLs nur für den Ressourcentyp Topic. Der Mustertyp PREFIXED ACLs und andere Ressourcentypen ACLs werden nicht kopiert. MSK Replicator löscht auch nicht ACLs auf dem Zielcluster. Wenn Sie eine ACL auf dem Quellcluster löschen, sollten Sie gleichzeitig auch auf dem Zielcluster löschen. Weitere Informationen zu ACLs Ressourcen, Mustern und Vorgängen von Kafka finden Sie unter [https://kafka.apache.org/documentation/\$1security\$1authz\$1cli](https://kafka.apache.org/documentation/#security_authz_cli).
MSK Replicator repliziert nur Kafka ACLs, das von der IAM-Zugriffskontrolle nicht verwendet wird. Wenn Ihre Clients die IAM-Zugriffskontrolle für Ihre MSK-Cluster verwenden, müssen Sie die entsprechenden IAM-Richtlinien auch auf Ihrem Zielcluster konfigurieren, um einen reibungslosen Failover zu gewährleisten. read/write Dies gilt sowohl für Replikationskonfigurationen mit Präfix als auch für Konfigurationen mit identischen Themennamen.
Als Teil der Offset-Synchronisierung für Verbrauchergruppen optimiert MSK Replicator die Daten für Ihre Benutzer auf dem Quell-Cluster, die von einer Position aus lesen, die näher an der Spitze des Streams liegt (Ende der Themenpartition). Wenn Ihre Nutzergruppen im Quell-Cluster hinterherhinken, können Sie bei diesen Nutzergruppen auf dem Ziel-Cluster eine höhere Verzögerung feststellen als beim Quell-Cluster. Das bedeutet, dass Ihre Kunden nach einem Failover auf den Zielcluster mehr doppelte Nachrichten erneut verarbeiten werden. Um diese Verzögerung zu verringern, müssten Ihre Verbraucher auf dem Quell-Cluster aufholen und von der Spitze des Streams (Ende der Themenpartition) aus mit dem Konsum beginnen. Wenn Ihre Kunden aufholen, reduziert MSK Replicator die Verzögerung automatisch.
![\[MSK-Replikator-Quell- und Ziel-Cluster\]](http://docs.aws.amazon.com/de_de/msk/latest/developerguide/images/msk-replicator-diagram.png)
## Konfiguration des Themennamens
MSK Replicator hat zwei Modi zur Konfiguration von Themennamen: Replikation mit *Präfix* (Standard) oder Replikation *mit identischem* Themennamen.
**Replikation von Themennamen mit Präfix**
Standardmäßig erstellt MSK Replicator neue Themen im Zielcluster mit einem automatisch generierten Präfix, das dem Themennamen des Quell-Clusters hinzugefügt wird, z. B. `.topic` Dies dient dazu, die replizierten Themen von anderen Themen im Zielcluster zu unterscheiden und eine zirkuläre Replikation von Daten zwischen den Clustern zu vermeiden.
MSK Replicator repliziert beispielsweise Daten in einem Thema mit dem Namen „Topic“ aus dem Quellcluster in ein neues Thema im Zielcluster namens < Alias>.topic. sourceKafkaCluster Das Präfix, das den Themennamen im Zielcluster hinzugefügt wird, finden Sie mithilfe der `DescribeReplicator` API im **sourceKafkaClusterAlias-Feld** oder auf der **Replicator-Detailseite** in der MSK-Konsole. Das Präfix im Zielcluster lautet < sourceKafkaCluster Alias>.
Um sicherzustellen, dass Ihre Verbraucher die Verarbeitung zuverlässig vom Standby-Cluster aus wieder aufnehmen können, müssen Sie Ihre Verbraucher so konfigurieren, dass sie Daten aus den Themen mithilfe eines Platzhalteroperators lesen. `.*` Ihre Verbraucher müssten zum Beispiel konsumieren mit. `*topic1`in beiden AWS Regionen. Dieses Beispiel würde auch ein Thema wie enthalten`footopic1`, also passen Sie den Platzhalteroperator an Ihre Bedürfnisse an.
Sie sollten den MSK Replicator verwenden, der ein Präfix hinzufügt, wenn Sie Replikatordaten in einem separaten Thema im Zielcluster speichern möchten, z. B. für Active-Active-Cluster-Setups.
**Replikation mit identischem Themennamen**
Als Alternative zur Standardeinstellung können Sie mit Amazon MSK Replicator einen Replikator erstellen, bei dem die Themenreplikation auf Replikation mit identischem Themennamen gesetzt ist (**denselben Themennamen in der Konsole beibehalten**). Sie können einen neuen Replikator in der AWS Region erstellen, in der sich Ihr Ziel-MSK-Cluster befindet. Identisch benannte replizierte Themen verhindern, dass Clients neu konfiguriert werden, sodass sie aus replizierten Themen lesen.
Die Replikation identischer Themennamen (**Behalten Sie denselben Themennamen in der** Konsole bei) hat folgende Vorteile:
+ Ermöglicht es Ihnen, identische Themennamen während des Replikationsvorgangs beizubehalten und gleichzeitig automatisch das Risiko endloser Replikationsschleifen zu vermeiden.
+ Vereinfacht die Einrichtung und den Betrieb von Multi-Cluster-Streaming-Architekturen, da Sie vermeiden können, dass Clients neu konfiguriert werden müssen, um aus den replizierten Themen zu lesen.
+ Bei Aktiv-Passiv-Clusterarchitekturen optimiert die Funktion zur Replikation identischer Themennamen auch den Failover-Prozess, sodass Anwendungen nahtlos auf einen Standby-Cluster umschalten können, ohne dass Themennamen geändert oder Clients neu konfiguriert werden müssen.
+ Kann verwendet werden, um Daten aus mehreren MSK-Clustern einfacher in einem einzigen Cluster für Datenaggregation oder zentrale Analysen zu konsolidieren. Dazu müssen Sie separate Replikatoren für jeden Quellcluster und denselben Zielcluster erstellen.
+ Kann die Datenmigration von einem MSK-Cluster zu einem anderen rationalisieren, indem Daten in gleichnamige Themen im Zielcluster repliziert werden.
Amazon MSK Replicator verwendet Kafka-Header, um automatisch zu verhindern, dass Daten zurück zu dem Thema repliziert werden, aus dem sie stammen, wodurch das Risiko unendlicher Zyklen während der Replikation vermieden wird. Ein Header ist ein Schlüssel-Wert-Paar, das zusammen mit dem Schlüssel, dem Wert und dem Zeitstempel in jeder Kafka-Nachricht enthalten sein kann. MSK Replicator bettet Bezeichner für Quellcluster und Thema in den Header jedes Datensatzes ein, der repliziert wird. MSK Replicator verwendet die Header-Informationen, um unendliche Replikationsschleifen zu vermeiden. Sie sollten sicherstellen, dass Ihre Clients replizierte Daten erwartungsgemäß lesen können.
# Tutorial: Quell- und Zielcluster für Amazon MSK Replicator einrichten
Dieses Tutorial zeigt Ihnen, wie Sie einen Quellcluster und einen Zielcluster in derselben AWS Region oder in verschiedenen AWS Regionen einrichten. Anschließend verwenden Sie diese Cluster, um einen Amazon MSK Replicator zu erstellen.
# Bereiten Sie den Amazon MSK-Quellcluster vor
Wenn Sie bereits einen MSK-Quell-Cluster für den MSK-Replikator erstellt haben, stellen Sie sicher, dass er die in diesem Abschnitt beschriebenen Anforderungen erfüllt. Gehen Sie andernfalls wie folgt vor, um einen von MSK bereitgestellten Cluster oder einen Serverless-Quell-Cluster zu erstellen.
Das Verfahren zum Erstellen eines regionsübergreifenden und regionsinternen MSK-Replikator-Quell-Clusters ist ähnlich. Unterschiede werden in den folgenden Verfahren hervorgehoben.
1. Erstellen Sie einen von MSK bereitgestellten Cluster oder einen Serverless-Cluster mit [aktivierter IAM-Zugriffssteuerung](create-iam-access-control-cluster-in-console.md) in der Quellregion. Ihr Quell-Cluster muss über mindestens drei Broker verfügen.
1. Wenn bei einem regionsübergreifenden MSK-Replikator die Quelle ein bereitgestellter Cluster ist, konfigurieren Sie ihn mit aktivierter privater Multi-VPC-Konnektivität für IAM-Zugriffssteuerungs-Schema. Beachten Sie, dass der Authentifizierungstyp „Nicht authentifiziert“ nicht unterstützt wird, wenn Multi-VPC aktiviert ist. Sie müssen die private Multi-VPC-Konnektivität nicht für andere Authentifizierungsschemas (mTLS) oder SASL/SCRAM). You can simultaneously use mTLS or SASL/SCRAM Authentifizierungsschemata für Ihre anderen Clients aktivieren, die eine Verbindung zu Ihrem MSK-Cluster herstellen. Sie können private Multi-VPC-Konnektivität in den Cluster-Details der Konsole unter **Netzwerkeinstellungen** oder mit der `UpdateConnectivity`-API konfigurieren. Siehe [Cluster-Besitzer aktiviert Multi-VPC](mvpc-cluster-owner-action-turn-on.md). Wenn es sich bei Ihrem Quell-Cluster um einen Serverless-MSK-Cluster handelt, müssen Sie die private Multi-VPC-Konnektivität nicht aktivieren.
Für einen regionsinternen MSK-Replikator benötigt der MSK-Quell-Cluster keine private Multi-VPC-Konnektivität, und andere Clients können weiterhin mit dem Authentifizierungstyp „Nicht authentifiziert“ auf den Cluster zugreifen.
1. Für regionsübergreifende MSK-Replikatoren müssen Sie dem Quell-Cluster eine ressourcenbasierte Berechtigungsrichtlinie hinzufügen. Dadurch kann MSK eine Verbindung zu diesem Cluster herstellen, um Daten zu replizieren. Sie können dies mithilfe der folgenden CLI- oder AWS Konsolenverfahren tun. Siehe auch [ressourcenbasierte Amazon-MSK-Richtlinien](security_iam_service-with-iam.md). Dieser Schritt ist für regionsinterne MSK-Replikatoren nicht nötig.
------
#### [ Console: create resource policy ]
Aktualisieren Sie die Quell-Cluster-Richtlinie mit dem folgenden JSON-Code. Ersetzen Sie den Platzhalter durch den ARN Ihres Quell-Clusters.
****
```
{
"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"
}
]
}
```
Verwenden Sie die Option **Cluster-Richtlinie bearbeiten** im Menü **Aktionen** auf der Cluster-Detailseite.
![\[Bearbeiten Sie die Cluster-Richtlinie in der Konsole\]](http://docs.aws.amazon.com/de_de/msk/latest/developerguide/images/edit-cluster-policy.png)
------
#### [ CLI: create resource policy ]
Hinweis: Wenn Sie die AWS Konsole verwenden, um einen Quellcluster zu erstellen, und die Option zum Erstellen einer neuen IAM-Rolle wählen, wird die erforderliche Vertrauensrichtlinie an die Rolle AWS angehängt. Wenn MSK hingegen eine vorhandene IAM-Rolle verwenden soll oder wenn Sie selbst eine Rolle erstellen, fügen Sie dieser Rolle die folgende Vertrauensrichtlinie an, damit MSK-Replikator sie annehmen kann. Weitere Informationen zum Ändern der Vertrauensstellung einer Rolle finden Sie unter [Ändern einer Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage_modify.html).
1. Rufen Sie mit diesem Befehl die aktuelle Version der MSK-Cluster-Richtlinie ab. Ersetzen Sie Platzhalter durch den tatsächlichen Cluster-ARN.
```
aws kafka get-cluster-policy —cluster-arn
{
"CurrentVersion": "K1PA6795UKM GR7",
"Policy": "..."
}
```
1. Erstellen Sie eine ressourcenbasierte Richtlinie, um MSK-Replikator den Zugriff auf den Quell-Cluster zu ermöglichen. Verwenden Sie die folgende Syntax als Vorlage und ersetzen Sie den Platzhalter durch den tatsächlichen Quell-Cluster-ARN.
```
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": ""
}
]
```
------
# Bereiten Sie den Amazon MSK-Zielcluster vor
Erstellen Sie einen MSK-Ziel-Cluster (bereitgestellt oder serverless) mit aktivierter IAM-Zugriffssteuerung. Für den Ziel-Cluster ist es nicht erforderlich, dass private Multi-VPC-Konnektivität aktiviert ist. Der Zielcluster kann sich in derselben AWS Region oder einer anderen Region wie der Quellcluster befinden. Sowohl der Quell- als auch der Zielcluster müssen sich im selben AWS Konto befinden. Der Quell-Cluster muss über mindestens drei Broker verfügen.
# Tutorial: Einen Amazon MSK Replicator erstellen
Nachdem Sie die Quell- und Zielcluster eingerichtet haben, können Sie diese Cluster verwenden, um einen Amazon MSK Replicator zu erstellen. Bevor Sie den Amazon MSK Replicator erstellen, stellen Sie sicher, dass Sie [Für die Erstellung eines MSK-Replikators sind IAM-Berechtigungen erforderlich](msk-replicator-requirements.md#replicator-role-permissions-successful) haben.
**Contents**
+ [Überlegungen zur Erstellung eines Amazon MSK Replicators](msk-replicator-requirements.md)
+ [Für die Erstellung eines MSK-Replikators sind IAM-Berechtigungen erforderlich](msk-replicator-requirements.md#replicator-role-permissions-successful)
+ [Unterstützte Clustertypen und Versionen für MSK Replicator](msk-replicator-supported-clusters-versions.md)
+ [Unterstützte serverlose MSK-Clusterkonfiguration](msk-replicator-serverless-requirements.md)
+ [Änderungen der Cluster-Konfiguration](msk-replicator-serverless-requirements.md#msk-replicator-config-changes)
+ [Erstellen Sie den Replikator mithilfe der AWS Konsole in der Zielclusterregion](msk-replicator-create-console.md)
+ [Wählen Sie den Quell-Cluster](msk-replicator-create-console.md#msk-replicator-create-console-choose-source)
+ [Wählen Sie den Ziel-Cluster](msk-replicator-create-console.md#msk-replicator-create-console-choose-target)
+ [Einstellungen und Berechtigungen des Replikators konfigurieren](msk-replicator-create-console.md#msk-replicator-create-settings)
# Überlegungen zur Erstellung eines Amazon MSK Replicators
Die folgenden Abschnitte geben einen Überblick über die Voraussetzungen, unterstützten Konfigurationen und bewährte Methoden für die Verwendung der MSK Replicator-Funktion. Es behandelt die erforderlichen Berechtigungen, die Cluster-Kompatibilität und die spezifischen Anforderungen für Serverless sowie Anleitungen zur Verwaltung des Replicators nach der Erstellung.
## Für die Erstellung eines MSK-Replikators sind IAM-Berechtigungen erforderlich
Hier ist ein Beispiel für die IAM-Richtlinie, die für die Erstellung eines MSK-Replikators erforderlich ist. Die Aktion `kafka:TagResource` ist nur erforderlich, wenn bei der Erstellung des MSK-Replikators Tags angegeben werden. Die IAM-Richtlinien für Replikatoren sollten der IAM-Rolle zugeordnet werden, die Ihrem Client entspricht. Informationen zum Erstellen von Autorisierungsrichtlinien finden Sie unter Autorisierungsrichtlinien [erstellen](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"
]
}
]
}
```
------
Es folgt ein Beispiel einer IAM-Richtlinie zur Beschreibung des Replikators. Entweder die Aktion `kafka:DescribeReplicator` oder die Aktion `kafka:ListTagsForResource` ist erforderlich, nicht beides.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"kafka:DescribeReplicator",
"kafka:ListTagsForResource"
],
"Resource": "*"
}
]
}
```
------
# Unterstützte Clustertypen und Versionen für MSK Replicator
Dies sind Anforderungen für unterstützte Instance-Typen, Kafka-Versionen und Netzwerkkonfigurationen.
+ MSK-Replikator unterstützt sowohl von MSK bereitgestellte Cluster als auch MSK-Serverless-Cluster in beliebiger Kombination als Quell- und Ziel-Cluster. Andere Arten von Kafka-Clustern werden derzeit von MSK-Replikator nicht unterstützt.
+ Serverless-MSK-Cluster erfordern eine IAM-Zugriffssteuerung, unterstützen keine Apache-Kafka-ACL-Replikation und die themenspezifische Konfigurationsreplikation wird nur eingeschränkt unterstützt. Siehe [Was ist MSK Serverless?](serverless.md).
+ MSK Replicator wird nur auf Clustern unterstützt, auf denen Apache Kafka 2.7.0 oder höher ausgeführt wird, unabhängig davon, ob sich Ihre Quell- und Zielcluster im selben oder in unterschiedlichen Clustern befinden. AWS-Regionen
+ MSK Replicator unterstützt Cluster, die Instance-Typen m5.large oder größer verwenden. t3.small-Cluster werden nicht unterstützt.
+ Wenn Sie MSK-Replikator mit einem von MSK bereitgestellten Cluster verwenden, benötigen Sie mindestens je drei Broker in Quell- und Ziel-Clustern. Sie können Daten clusterübergreifend in zwei Availability Zones replizieren, benötigen jedoch mindestens vier Broker in diesen Clustern.
+ Sowohl Ihr Quell- als auch Ihr Ziel-MSK-Cluster müssen sich im selben Konto befinden. AWS Die Replikation zwischen Clustern in verschiedenen Konten wird nicht unterstützt.
+ Wenn sich die Quell- und Ziel-MSK-Cluster in unterschiedlichen AWS Regionen (regionsübergreifend) befinden, verlangt MSK Replicator, dass für den Quellcluster private Multi-VPC-Konnektivität für seine IAM-Zugriffskontrollmethode aktiviert ist.
Multi-VPC ist für andere Authentifizierungsmethoden auf dem Quellcluster für die MSK-Replikation zwischen diesen nicht erforderlich. AWS-Regionen
Multi-VPC ist auch nicht erforderlich, wenn Sie Daten zwischen Clustern in derselben replizieren. AWS-Region Siehe [Private Multi-VPC-Konnektivität von Amazon MSK in einer einzelnen Region](aws-access-mult-vpc.md).
+ Für die Replikation identischer Themennamen (**denselben Themennamen in der Konsole beibehalten**) ist ein MSK-Cluster erforderlich, auf dem Kafka Version 2.8.1 oder höher ausgeführt wird.
+ Um das Risiko einer zyklischen Replikation zu vermeiden, sollten Sie bei Konfigurationen zur Replikation identischer **Themennamen (denselben Themennamen in der Konsole beibehalten**) keine Änderungen an den Headern vornehmen, die MSK Replicator erstellt (). `__mskmr`
# Unterstützte serverlose MSK-Clusterkonfiguration
+ MSK Serverless unterstützt die Replikation dieser Themenkonfigurationen für MSK-Serverless-Ziel-Cluster während der Themenerstellung: `cleanup.policy`, `compression.type`, `max.message.bytes`, `retention.bytes`, `retention.ms`.
+ MSK Serverless unterstützt während der Synchronisierung der Themenkonfiguration nur diese Themenkonfigurationen: `compression.type`, `max.message.bytes`, `retention.bytes`, `retention.ms`.
+ Replikator verwendet 83 komprimierte Partitionen auf MSK-Serverless-Ziel-Clustern. Stellen Sie sicher, dass die MSK-Serverless-Ziel-Cluster über eine ausreichende Anzahl komprimierter Partitionen verfügen. Siehe [MSK-Serverless-Kontingent](limits.md#serverless-quota).
## Änderungen der Cluster-Konfiguration
+ Es wird empfohlen, den gestaffelten Speicher nicht ein- oder auszuschalten, nachdem der MSK-Replikator erstellt wurde. Wenn Ihr Ziel-Cluster nicht mehrstufig ist, kopiert MSK die gestaffelte Speicherkonfigurationen nicht, unabhängig davon, ob Ihr Quell-Cluster gestaffelt ist oder nicht. Wenn Sie nach der Erstellung des Replikators den gestaffelten Speicher auf dem Ziel-Cluster aktivieren, muss der Replikator neu erstellt werden. Wenn Sie Daten von einem nicht-mehrstufigen Cluster in einen mehrstufigen Cluster kopieren möchten, sollten Sie keine Themenkonfigurationen kopieren. Weitere Informationen finden Sie unter [Aktivieren und Deaktivieren der gestaffelten Speicherung bei einem vorhandenen Thema](https://docs.aws.amazon.com/msk/latest/developerguide/msk-enable-disable-topic-tiered-storage-cli.html).
+ Ändern Sie die Cluster-Konfigurationseinstellungen nach der Erstellung des MSK-Replikators nicht. Die Cluster-Konfigurationseinstellungen werden bei der Erstellung des MSK-Replikators überprüft. Um Probleme mit dem MSK-Replikator zu vermeiden, sollten Sie die folgenden Einstellungen nicht ändern, nachdem der MSK-Replikator erstellt wurde.
+ Den MSK-Cluster in den Instance-Typ t3 ändern.
+ Berechtigungen für die Service-Ausführungsrolle ändern.
+ Die private MSK-Multi-VPC-Konnektivität deaktivieren.
+ Die angefügte ressourcenbasierte Richtlinie für den Cluster ändern.
+ Die Regeln der Cluster-Sicherheitsgruppe ändern.
# Erstellen Sie den Replikator mithilfe der AWS Konsole in der Zielclusterregion
Im folgenden Abschnitt wird der schrittweise Konsolen-Workflow zum Erstellen eines Replikators erläutert.
**Einzelheiten zum Replikator**
1. [Öffnen Sie in der AWS Region, in der sich Ihr Ziel-MSK-Cluster befindet, die Amazon MSK-Konsole zu Hause? https://console.aws.amazon.com/msk/ region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Wählen Sie **Replikatoren**, um die Liste der Replikatoren im Konto anzuzeigen.
1. Wählen Sie **Replikator erstellen**.
1. Geben Sie im **Replikator-Detailbereich** dem neuen Replikator einen eindeutigen Namen.
## Wählen Sie den Quell-Cluster
Der Quell-Cluster enthält die Daten, die Sie in einen MSK-Ziel-Cluster kopieren möchten.
1. Wählen Sie im Bereich **Quell-Cluster** die AWS -Region aus, in der sich der Quell-Cluster befindet.
Sie können die Region eines Clusters nachschlagen, indem Sie zu **MSK-Clusters** gehen und sich die Details des **Cluster**-ARN ansehen. Der Name der Region ist in die ARN-Zeichenfolge eingebettet. Im folgenden Beispiels-ARN ist die Cluster-Region `ap-southeast-2`.
```
arn:aws:kafka:ap-southeast-2:123456789012:cluster/cluster-11/eec93c7f-4e8b-4baf-89fb-95de01ee639c-s1
```
1. Geben Sie den ARN Ihres Quell-Clusters ein oder suchen Sie nach dem Quell-Cluster, um ihn auszuwählen.
1. Wählen Sie Subnetz(e) für den Quell-Cluster aus.
In der Konsole werden die Subnetze angezeigt, die in der Region des Quell-Clusters verfügbar sind, sodass Sie sie auswählen können. Sie müssen mindestens zwei Subnetze auswählen. Für einen regionsinternen MSK-Replikator müssen sich die Subnetze, die Sie für den Zugriff auf den Quell-Cluster auswählen, und die Subnetze für den Zugriff auf den Ziel-Cluster in derselben Availability Zone befinden.
1. Wählen Sie Sicherheitsgruppen aus, damit der MSK Replicator auf Ihren Quellcluster zugreifen kann.
+ Für die regionsübergreifende Replikation (CRR) müssen Sie keine Sicherheitsgruppe (n) für Ihren Quellcluster angeben.
+ Gehen Sie für die Replikation derselben Region (SRR) zur Amazon EC2 EC2-Konsole unter https://console.aws.amazon.com/ec2/ und stellen Sie sicher, dass die Sicherheitsgruppen, die Sie für den Replicator angeben, über Regeln für ausgehenden Datenverkehr zu den Sicherheitsgruppen Ihres Quell-Clusters verfügen. Stellen Sie außerdem sicher, dass die Sicherheitsgruppen Ihres Quell-Clusters über Regeln für eingehenden Datenverkehr verfügen, die den Datenverkehr von den für die Quelle bereitgestellten Replicator-Sicherheitsgruppen zulassen.
**Gehen Sie wie folgt vor, um der Sicherheitsgruppe Ihres Quell-Clusters Regeln für eingehenden Datenverkehr hinzuzufügen:**
1. Gehen Sie in der AWS Konsole zu den Details Ihres Quell-Clusters, indem Sie den **Clusternamen** auswählen.
1. Wählen Sie die Registerkarte **Eigenschaften** und scrollen Sie dann nach unten zum Bereich **Netzwerkeinstellungen**, um den Namen der angewendeten **Sicherheitsgruppe** auszuwählen.
1. Rufen Sie die Regeln für eingehenden Datenverkehr auf und wählen Sie **Regeln für eingehenden Datenverkehr bearbeiten**.
1. Wählen Sie **Regel hinzufügen**.
1. Wählen Sie in der Spalte **Typ** für die neue Regel die Option **Benutzerdefiniertes TCP** aus.
1. Geben Sie in der Spalte **Portbereich** den Text ein`9098`. MSK Replicator verwendet IAM-Zugriffskontrolle, um eine Verbindung zu Ihrem Cluster herzustellen, der Port 9098 verwendet.
1. **Geben Sie in der Spalte **Quelle** den Namen der Sicherheitsgruppe ein, die Sie bei der Replikatorerstellung für den Quellcluster angeben werden (dies kann mit der Sicherheitsgruppe des MSK-Quellclusters identisch sein), und wählen Sie dann Regeln speichern aus.**
**Gehen Sie wie folgt vor, um Regeln für ausgehenden Datenverkehr zur Sicherheitsgruppe von Replicator hinzuzufügen, die für die Quelle bereitgestellt wurde:**
1. Gehen Sie in der AWS Konsole für Amazon EC2 zu der Sicherheitsgruppe, die Sie bei der Replicator-Erstellung für die Quelle angeben werden.
1. Gehen Sie zu den Regeln für ausgehenden Datenverkehr und wählen Sie Regeln für ausgehenden Datenverkehr **bearbeiten** aus.
1. Wählen Sie **Regel hinzufügen**.
1. Wählen Sie in der Spalte **Typ** für die neue Regel die Option **Benutzerdefiniertes** TCP aus.
1. Geben Sie in der Spalte **Portbereich** den Text ein`9098`. MSK Replicator verwendet IAM-Zugriffskontrolle, um eine Verbindung zu Ihrem Cluster herzustellen, der Port 9098 verwendet.
1. **Geben Sie in der Spalte **Quelle** den Namen der Sicherheitsgruppe des MSK-Quellclusters ein, und wählen Sie dann Regeln speichern aus.**
**Anmerkung**
Wenn Sie den Datenverkehr nicht mithilfe Ihrer Sicherheitsgruppen einschränken möchten, können Sie alternativ Regeln für eingehenden und ausgehenden Datenverkehr hinzufügen, die den gesamten Datenverkehr zulassen.
1. Wählen Sie **Regel hinzufügen**.
2. Wählen Sie in der Spalte **Typ** die Option **Gesamter Datenverkehr** aus.
3. Geben Sie in der Quelle-Spalte `0.0.0.0/0` ein und wählen Sie dann **Regeln speichern**.
## Wählen Sie den Ziel-Cluster
Der Ziel-Cluster ist der von MSK bereitgestellte Cluster oder der Serverless-Cluster, in den die Quelldaten kopiert werden.
**Anmerkung**
MSK-Replikator erstellt neue Themen im Ziel-Cluster mit einem automatisch generierten Präfix, das dem Themennamen hinzugefügt wird. MSK-Replikator repliziert beispielsweise Daten in „`topic`“ aus dem Quell-Cluster zu einem neuen Thema im Ziel-Cluster namens `.topic`. Dies dient dazu, Themen, die Daten enthalten, die aus dem Quell-Cluster repliziert wurden, von anderen Themen im Ziel-Cluster zu unterscheiden und zu verhindern, dass Daten zwischen den Clustern wiederkehrend repliziert werden. Das Präfix, das den Themennamen im Zielcluster hinzugefügt wird, finden Sie mithilfe der `DescribeReplicator` API im Feld **sourceKafkaClusterAlias** oder auf der Seite mit den **Replicator-Details** in der MSK-Konsole. Das Präfix im Zielcluster lautet. ``
1. Wählen Sie im Bereich **Zielcluster** die AWS Region aus, in der sich der Zielcluster befindet.
1. Geben Sie den ARN Ihres Ziel-Clusters ein oder suchen Sie nach dem Ziel-Cluster, um ihn auszuwählen.
1. Wählen Sie Subnetze für den Ziel-Cluster aus.
In der Konsole werden die Subnetze angezeigt, die in der Region des Ziel-Clusters verfügbar sind, sodass Sie sie auswählen können. Sie müssen mindestens zwei Subnetze auswählen.
1. Wählen Sie Sicherheitsgruppe (n) für den MSK Replicator für den Zugriff auf Ihren Zielcluster aus.
Es werden die Sicherheitsgruppen angezeigt, die in der Region des Ziel-Clusters verfügbar sind, sodass Sie sie auswählen können. Die gewählte Sicherheitsgruppe ist der jeweiligen Verbindung zugeordnet. Weitere Informationen zur Verwendung von Sicherheitsgruppen finden Sie unter [Steuern des Datenverkehrs zu Ihren AWS Ressourcen mithilfe von Sicherheitsgruppen](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html) im *Amazon VPC-Benutzerhandbuch*.
+ Gehen Sie sowohl für Cross-Region-Replication (CRR) als auch für Same Region Replication (SRR) zur Amazon EC2 EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)und stellen Sie sicher, dass die Sicherheitsgruppen, die Sie dem Replicator zur Verfügung stellen, über Regeln für ausgehenden Datenverkehr zu den Sicherheitsgruppen Ihres Zielclusters verfügen. Stellen Sie außerdem sicher, dass die Sicherheitsgruppen Ihres Ziel-Clusters über Regeln für eingehenden Datenverkehr aus den Replikator-Sicherheitsgruppen verfügen, die für das Ziel bereitgestellt wurden.
**So fügen Sie der Sicherheitsgruppe Ihres Zielclusters Regeln für eingehenden Datenverkehr hinzu:**
1. Gehen Sie in der AWS Konsole zu den Details Ihres Zielclusters, indem Sie den **Clusternamen** auswählen.
1. Wählen Sie die Registerkarte **Eigenschaften** und scrollen Sie dann nach unten zum Bereich Netzwerkeinstellungen, um den Namen der angewendeten **Sicherheitsgruppe** auszuwählen.
1. Rufen Sie die Regeln für eingehenden Datenverkehr auf und wählen Sie **Regeln für eingehenden Datenverkehr bearbeiten**.
1. Wählen Sie **Regel hinzufügen**.
1. Wählen Sie in der Spalte **Typ** für die neue Regel die Option **Benutzerdefiniertes TCP** aus.
1. Geben Sie in der Spalte **Portbereich** den Text ein`9098`. MSK Replicator verwendet IAM-Zugriffskontrolle, um eine Verbindung zu Ihrem Cluster herzustellen, der Port 9098 verwendet.
1. **Geben Sie in der Spalte **Quelle** den Namen der Sicherheitsgruppe ein, die Sie bei der Replikatorerstellung für den Zielcluster angeben werden (dies kann mit der Sicherheitsgruppe des MSK-Zielclusters identisch sein), und wählen Sie dann Regeln speichern aus.**
**Gehen Sie wie folgt vor, um Regeln für ausgehenden Datenverkehr zur Sicherheitsgruppe von Replicator hinzuzufügen, die für das Ziel bereitgestellt wurde:**
1. Gehen Sie in der AWS Konsole zu der Sicherheitsgruppe, die Sie bei der Erstellung des Replikators für das Ziel angeben werden.
1. Wählen Sie die Registerkarte **Eigenschaften** und scrollen Sie dann nach unten zum Bereich Netzwerkeinstellungen, um den Namen der angewendeten **Sicherheitsgruppe** auszuwählen.
1. Gehen Sie zu den Regeln für ausgehenden Datenverkehr und wählen Sie Regeln für **ausgehenden Datenverkehr bearbeiten** aus.
1. Wählen Sie **Regel hinzufügen**.
1. Wählen Sie in der Spalte **Typ** für die neue Regel die Option **Benutzerdefiniertes** TCP aus.
1. Geben Sie in der Spalte **Portbereich** den Text ein`9098`. MSK Replicator verwendet IAM-Zugriffskontrolle, um eine Verbindung zu Ihrem Cluster herzustellen, der Port 9098 verwendet.
1. **Geben Sie in der Spalte **Quelle** den Namen der Sicherheitsgruppe des MSK-Zielclusters ein, und wählen Sie dann Regeln speichern aus.**
**Anmerkung**
Wenn Sie den Datenverkehr nicht mithilfe Ihrer Sicherheitsgruppen einschränken möchten, können Sie alternativ Regeln für eingehenden und ausgehenden Datenverkehr hinzufügen, die den gesamten Datenverkehr zulassen.
1. Wählen Sie **Regel hinzufügen**.
2. Wählen Sie in der Spalte **Typ** die Option **Gesamter Datenverkehr** aus.
3. Geben Sie in der Quelle-Spalte `0.0.0.0/0` ein und wählen Sie dann **Regeln speichern**.
## Einstellungen und Berechtigungen des Replikators konfigurieren
1. Geben Sie im Bereich **Replikator-Einstellungen** die Themen, die Sie replizieren möchten, mithilfe regulärer Ausdrücke in den Zulassungs- und Verweigerungslisten an. Standardmäßig werden alle Themen repliziert.
**Anmerkung**
MSK Replicator repliziert nur bis zu 750 Themen in sortierter Reihenfolge. Wenn Sie mehr Themen replizieren müssen, empfehlen wir Ihnen, einen separaten Replicator zu erstellen. Rufen Sie das AWS Konsolen-Supportcenter auf und [erstellen Sie einen Support-Fall](https://console.aws.amazon.com/support/home#/), wenn Sie Support für mehr als 750 Themen pro Replicator benötigen. Sie können die Anzahl der replizierten Themen mithilfe der Metrik "TopicCount" überwachen. Siehe [Broker-Kontingent für Amazon MSK Standard](limits.md#msk-provisioned-quota).
1. Standardmäßig startet MSK Replicator die Replikation ab dem letzten (*neuesten*) Offset in den ausgewählten Themen. Alternativ können Sie die Replikation am *frühesten* (ältesten) Offset in den ausgewählten Themen starten, wenn Sie vorhandene Daten zu Ihren Themen replizieren möchten. Sobald der Replikator erstellt wurde, können Sie diese Einstellung nicht mehr ändern. Diese Einstellung entspricht dem [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)Feld in der [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)Anfrage und [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)Antwort APIs.
1. Wählen Sie eine Konfiguration für den Themennamen:
+ `PREFIXED`Replikation von Themennamen (**Präfix zum Themennamen in der Konsole hinzufügen**): Die Standardeinstellung. MSK Replicator repliziert „topic1“ aus dem Quellcluster auf ein neues Thema im Zielcluster mit dem Namen. `.topic1`
+ Replikation identischer Themennamen (**Behalten Sie denselben Themennamen** in der Konsole bei): Themen aus dem Quellcluster werden mit identischen Themennamen im Zielcluster repliziert.
Diese Einstellung entspricht dem `TopicNameConfiguration` Feld in der `CreateReplicator` Anfrage und `DescribeReplicator` Antwort APIs. Siehe [Funktionsweise von Amazon MSK Replicator](msk-replicator-how-it-works.md).
**Anmerkung**
Standardmäßig erstellt MSK Replicator neue Themen im Zielcluster mit einem automatisch generierten Präfix, das dem Themennamen hinzugefügt wird. Dies dient dazu, Themen, die Daten enthalten, die aus dem Quell-Cluster repliziert wurden, von anderen Themen im Ziel-Cluster zu unterscheiden und zu verhindern, dass Daten zwischen den Clustern wiederkehrend repliziert werden. Alternativ können Sie einen MSK Replicator mit identischer Themennamenreplikation erstellen (**denselben Themennamen in der Konsole beibehalten**), sodass Themennamen während der Replikation erhalten bleiben. Diese Konfiguration reduziert die Notwendigkeit, Client-Anwendungen während der Installation neu zu konfigurieren, und erleichtert den Betrieb von Streaming-Architekturen mit mehreren Clustern.
1. Standardmäßig kopiert MSK Replicator alle Metadaten, einschließlich Themenkonfigurationen, Zugriffskontrolllisten (ACLs) und Nutzergruppen-Offsets, um einen reibungslosen Failover zu gewährleisten. Wenn Sie den Replikator nicht für Failover erstellen, können Sie optional eine oder mehrere dieser Einstellungen deaktivieren, die im Abschnitt **Zusätzliche Einstellungen** verfügbar sind.
**Anmerkung**
MSK Replicator repliziert keine Schreibvorgänge, ACLs da Ihre Produzenten nicht direkt in das replizierte Thema im Zielcluster schreiben sollten. Ihre Produzenten sollten nach dem Failover in das lokale Thema im Ziel-Cluster schreiben. Details dazu finden Sie unter [Führen Sie ein geplantes Failover zur sekundären Region durch AWS](msk-replicator-perform-planned-failover.md).
1. Geben Sie im Bereich für die **Replikation von Verbrauchergruppen** die Verbrauchergruppen, die Sie replizieren möchten, mithilfe regulärer Ausdrücke in den Zulassungs- und Verweigerungslisten an. Standardmäßig werden alle Verbrauchergruppen repliziert.
1. Im Bereich **Komprimierung** können Sie optional wählen, ob die in den Ziel-Cluster geschriebenen Daten komprimiert werden sollen. Wenn Sie die Komprimierung verwenden möchten, empfehlen wir, dieselbe Komprimierungsmethode zu verwenden, wie für die Daten in Ihrem Quell-Cluster.
1. Führen Sie im Bereich **Zugriffsberechtigungen** einen der folgenden Schritte aus:
1. Wählen Sie **IAM-Rolle mit den erforderlichen Richtlinien erstellen oder aktualisieren** aus. Die MSK-Konsole hängt der Service-Ausführungsrolle, die für Lese- und Schreibvorgänge in den Quell- und Ziel-MSK-Clustern erforderlich ist, automatisch die erforderlichen Berechtigungen und Vertrauensrichtlinien an.
![\[MSK-Konsole zum Erstellen oder Aktualisieren der Replikator-IAM-Rolle\]](http://docs.aws.amazon.com/de_de/msk/latest/developerguide/images/msk-replicator-ezCRC.png)
1. Geben Sie Ihre eigene IAM-Rolle an, indem **Sie Aus IAM-Rollen auswählen, die Amazon MSK** übernehmen kann auswählen. Wir empfehlen, dass Sie die `AWSMSKReplicatorExecutionRole` verwaltete IAM-Richtlinie Ihrer Rolle für die Serviceausführung zuordnen, anstatt Ihre eigene IAM-Richtlinie zu schreiben.
1. Erstellen Sie die IAM-Rolle, die der Replicator zum Lesen und Schreiben in Ihre Quell- und Ziel-MSK-Cluster verwendet. Verwenden Sie dabei das unten stehende JSON als Teil der Vertrauensrichtlinie und das der Rolle angehängte. `AWSMSKReplicatorExecutionRole` Ersetzen Sie in der Vertrauensrichtlinie den Platzhalter mit Ihrer tatsächlichen Konto-ID.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "kafka.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": ""
}
}
}
]
}
```
------
1. Im Bereich **Replikator-Tags** können Sie der MSK-Replikator-Ressource optional Tags zuweisen. Weitere Informationen finden Sie unter [Kennzeichnen Sie einen Amazon MSK-Cluster](msk-tagging.md). Bei einem regionsübergreifenden MSK-Replikator werden Tags automatisch mit der Fernregion synchronisiert, wenn der Replikator erstellt wird. Wenn Sie Tags ändern, nachdem der Replikator erstellt wurde, wird die Änderung nicht automatisch mit der Fernregion synchronisiert, sodass Sie lokale Replikator- und Remote-Replikator-Referenzen manuell synchronisieren müssen.
1. Wählen Sie **Erstellen** aus.
Informationen zum Einschränken von `kafka-cluster:WriteData` Berechtigungen finden Sie im Abschnitt *Autorisierungsrichtlinien erstellen* unter [So funktioniert die IAM-Zugriffskontrolle für Amazon MSK](https://docs.aws.amazon.com/msk/latest/developerguide/iam-access-control.html#how-to-use-iam-access-control). Sie müssen sowohl dem Quell- als auch dem Zielcluster `kafka-cluster:WriteDataIdempotently` Berechtigungen hinzufügen.
Es dauert ungefähr 30 Minuten, bis der MSK-Replikator erfolgreich erstellt und in den Status RUNNING gewechselt ist.
Wenn Sie einen neuen MSK-Replikator erstellen, um einen gelöschten zu ersetzen, startet der neue Replikator die Replikation ab dem letzten Offset.
Wenn der MSK-Replikator in den Status FAILED übergegangen ist, finden Sie weitere Informationen im Abschnitt [Problembehandlung für MSK Replicator.](msk-replicator-troubleshooting.md)
# MSK-Replikator-Einstellungen bearbeiten
Sie können den Quellcluster, den Zielcluster, die Startposition des Replicators oder die Konfiguration der Replikation mit Themennamen nicht mehr ändern, nachdem der MSK Replicator erstellt wurde. Sie müssen einen neuen Replikator erstellen, um die Replikationskonfiguration mit identischen Themennamen verwenden zu können. Sie können jedoch auch andere Replicator-Einstellungen bearbeiten, z. B. Themen und Nutzergruppen, die repliziert werden sollen.
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon MSK-Konsole zu [https://console.aws.amazon.com/msk/Hause? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Wählen Sie im linken Navigationsbereich Replikatoren aus, um die Liste der **Replikatoren** im Konto anzuzeigen, und wählen Sie den MSK-Replikator aus, den Sie bearbeiten möchten.
1. Wählen Sie die Registerkarte **Eigenschaften** aus.
1. Wählen Sie im Bereich **Replikator-Einstellungen** die Option **Replikator bearbeiten**.
1. Sie können die MSK-Replikator-Einstellungen bearbeiten, indem Sie eine dieser Einstellungen ändern.
+ Geben Sie die Themen, die Sie replizieren möchten, mithilfe regulärer Ausdrücke in den Zulassungs- und Verweigerungslisten an. Standardmäßig kopiert MSK Replicator alle Metadaten, einschließlich Themenkonfigurationen, Zugriffskontrolllisten (ACLs) und Nutzergruppen-Offsets, um einen reibungslosen Failover zu gewährleisten. Wenn Sie den Replikator nicht für Failover erstellen, können Sie optional eine oder mehrere dieser Einstellungen deaktivieren, die im Abschnitt **Zusätzliche Einstellungen** verfügbar sind.
**Anmerkung**
MSK Replicator repliziert keine Schreibvorgänge, ACLs da Ihre Produzenten nicht direkt in das replizierte Thema im Zielcluster schreiben sollten. Ihre Produzenten sollten nach dem Failover in das lokale Thema im Ziel-Cluster schreiben. Details dazu finden Sie unter [Führen Sie ein geplantes Failover zur sekundären Region durch AWS](msk-replicator-perform-planned-failover.md).
+ Für die **Replikation von Verbrauchergruppen** können Sie die Verbrauchergruppen, die Sie replizieren möchten, mithilfe regulärer Ausdrücke in den Zulassungs- und Verweigerungslisten angeben. Standardmäßig werden alle Verbrauchergruppen repliziert. Wenn die Zulassungs- und Verweigerungslisten leer sind, ist die Replikation von Verbrauchergruppen deaktiviert.
+ Unter **Ziel-Komprimierungstyp** können Sie wählen, ob die in den Ziel-Cluster geschriebenen Daten komprimiert werden sollen. Wenn Sie die Komprimierung verwenden möchten, empfehlen wir, dieselbe Komprimierungsmethode zu verwenden, wie für die Daten in Ihrem Quell-Cluster.
1. Speichern Sie Ihre Änderungen.
Es dauert ungefähr 30 Minuten, bis der MSK-Replikator erfolgreich erstellt und in den Betriebszustand versetzt wurde. Wenn der MSK-Replikator in den Status FAILED übergegangen ist, finden Sie weitere Informationen im Abschnitt über Problembehandlung [Problembehandlung bei MSK Replicator](msk-replicator-troubleshooting.md).
# Löschen eines MSK-Replikators
Möglicherweise müssen Sie einen MSK-Replikator löschen, wenn er nicht erstellt werden kann (Status FAILED). Die Quell- und Ziel-Cluster, die einem MSK-Replikator zugewiesen sind, können nach der Erstellung des MSK-Replikators nicht mehr geändert werden. Sie können einen vorhandenen MSK-Replikator löschen und einen neuen erstellen. Wenn Sie einen neuen MSK-Replikator erstellen, um einen gelöschten zu ersetzen, startet der neue Replikator die Replikation ab dem letzten Offset.
1. Melden Sie sich in der AWS Region, in der sich Ihr Quell-Cluster befindet, bei der AWS-Managementkonsole Amazon MSK-Konsole an und öffnen Sie die Amazon MSK-Konsole zu [https://console.aws.amazon.com/msk/Hause? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Wählen Sie im Navigationsbereich **Replikatoren**.
1. Wählen Sie aus der Liste der MSK-Replikatoren den Replikator aus, den Sie löschen möchten, und wählen Sie **Löschen**.
# Überwachung einer Replikation
Sie können [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)in der Zielcluster-Region Metriken für `ReplicationLatency``MessageLag`, und `ReplicatorThroughput` auf Themen- und Aggregatebene für jeden Amazon MSK Replicator anzeigen. Metriken sind unter dem Namespace **ReplicatorName**„AWS/Kafka“ sichtbar. Sie können auch `ReplicatorFailure`-, `AuthError`- und `ThrottleTime`-Metriken sehen, um nach Problemen zu suchen.
Die MSK-Konsole zeigt eine Teilmenge von CloudWatch Metriken für jeden MSK-Replikator an. Wählen Sie aus der Liste der **Replikatoren** in der Konsole den Namen eines Replikators aus und wählen Sie die Registerkarte **Überwachung**.
## MSK-Replikatormetriken
Die folgenden Metriken beschreiben Leistungs- oder Verbindungsmetriken für den MSK-Replikator.
AuthError Die Metriken decken keine Authentifizierungsfehler auf Themenebene ab. Um die Authentifizierungsfehler Ihres MSK Replicators auf Themenebene zu überwachen, überwachen Sie die Metriken von Replicator und die ReplicationLatency Metriken des Quellclusters auf Themenebene,. MessagesInPerSec Wenn ein Thema auf 0 ReplicationLatency zurückgesetzt wird, für das Thema aber immer noch Daten erstellt werden, deutet dies darauf hin, dass der Replicator ein Authentifizierungsproblem mit dem Thema hat. Vergewissern Sie sich, dass die IAM-Rolle für die Service-Ausführungsrolle des Replikators über ausreichende Berechtigungen für den Zugriff auf das Thema verfügt.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/msk/latest/developerguide/msk-replicator-monitor.html)
# Verwenden Sie die Replikation, um die Stabilität einer Kafka-Streaming-Anwendung in allen Regionen zu erhöhen
Sie können MSK Replicator verwenden, um Aktiv-Aktiv- oder Aktiv-Passiv-Cluster-Topologien einzurichten, um die Resilienz Ihrer Apache Kafka-Anwendung in allen Regionen zu erhöhen. AWS In einer aktiv-aktiven Einrichtung verarbeiten beide MSK-Cluster aktiv Lese- und Schreibvorgänge. In einer Aktiv-Passiv-Einrichtung stellt jeweils nur ein MSK-Cluster aktiv Streaming-Daten bereit, während sich der andere Cluster im Standby-Modus befindet.
## Überlegungen zur Erstellung von Apache Kafka-Anwendungen für mehrere Regionen
Ihre Verbraucher müssen in der Lage sein, doppelte Nachrichten ohne nachgelagerte Auswirkungen erneut zu verarbeiten. MSK Replicator repliziert Daten at-least-once, was zu Duplikaten im Standby-Cluster führen kann. Wenn Sie zur sekundären AWS Region wechseln, verarbeiten Ihre Kunden dieselben Daten möglicherweise mehrmals. MSK-Replikator räumt dem Kopieren von Daten Vorrang vor Verbraucher-Offsets ein, um eine bessere Leistung zu erzielen. Nach einem Failover kann der Verbraucher beginnen, aus früheren Offsets zu lesen, was zu einer doppelten Verarbeitung führt.
Produzenten und Verbraucher müssen auch den Verlust minimaler Daten hinnehmen. Da MSK Replicator Daten asynchron repliziert, kann nicht garantiert werden, dass alle Daten in die sekundäre AWS Region repliziert werden, wenn in der primären Region Fehler auftreten. Sie können die Replikationslatenz verwenden, um die maximale Anzahl von Daten zu ermitteln, die nicht in die sekundäre Region kopiert wurden.
## Verwendung einer Aktiv-Aktiv-Cluster-Topologie im Vergleich zur Aktiv-Passiv-Cluster-Topologie
Eine Aktiv-Aktiv-Cluster-Topologie bietet eine Wiederherstellungszeit von nahezu Null und ermöglicht den gleichzeitigen Betrieb Ihrer Streaming-Anwendung in mehreren AWS -Regionen. Wenn ein Cluster in einer Region beeinträchtigt ist, verarbeiten Anwendungen, die mit dem Cluster in der anderen Region verbunden sind, weiterhin Daten.
Aktiv-Passiv-Einrichtungen eignen sich für Anwendungen, die jeweils nur in einer AWS -Region ausgeführt werden können, oder wenn Sie mehr Kontrolle über die Reihenfolge der Datenverarbeitung benötigen. Aktiv-Passiv-Einrichtungen benötigen mehr Wiederherstellungszeit als Aktiv-Aktiv-Einrichtungen, da Sie Ihre gesamte Aktiv-Passiv-Einrichtung, einschließlich der Produzenten und Verbraucher, in der sekundären Region starten müssen, um das Streamen von Daten nach einem Failover wieder aufnehmen zu können.
# Erstellen Sie ein aktiv-passives Kafka-Cluster-Setup mit empfohlenen Konfigurationen zur Themenbenennung
Für ein aktiv-passives Setup empfehlen wir Ihnen, ein ähnliches Setup aus Produzenten, MSK-Clustern und Verbrauchern (mit demselben Verbrauchergruppennamen) in zwei verschiedenen Regionen zu betreiben. AWS Es ist wichtig, dass die beiden MSK-Cluster über identische Lese- und Schreibkapazitäten verfügen, um eine zuverlässige Datenreplikation zu gewährleisten. Sie müssen einen MSK-Replikator erstellen, um kontinuierlich Daten vom primären Cluster auf den Standby-Cluster zu kopieren. Sie müssen Ihre Producer auch so konfigurieren, dass sie Daten in Themen eines Clusters in derselben Region schreiben. AWS
Für ein Aktiv-Passiv-Setup erstellen Sie einen neuen Replikator mit identischer Themennamenreplikation (**behalten Sie denselben Themennamen in der** Konsole bei), um mit der Replikation von Daten aus Ihrem MSK-Cluster in der primären Region auf Ihren Cluster in der sekundären Region zu beginnen. Wir empfehlen, dass Sie in den beiden AWS Regionen eine doppelte Gruppe von Produzenten und Verbrauchern betreiben, die jeweils über ihre eigene Bootstrap-Zeichenfolge eine Verbindung zum Cluster in ihrer eigenen Region herstellen. Dies vereinfacht den Failover-Prozess, da keine Änderungen an der Bootstrap-Zeichenfolge erforderlich sind. Um sicherzustellen, dass die Verbraucher dort weiterlesen, wo sie aufgehört haben, sollten die Verbraucher im Quell- und Zielcluster dieselbe Nutzergruppen-ID haben.
Wenn Sie für Ihren MSK Replicator **die Replikation identischer Themennamen verwenden (denselben Themennamen in der Konsole beibehalten**), repliziert er Ihre Themen mit demselben Namen wie die entsprechenden Quellthemen.
Wir empfehlen, dass Sie Einstellungen und Berechtigungen auf Clusterebene für Ihre Clients auf dem Zielcluster konfigurieren. Sie müssen keine Einstellungen auf Themenebene und das wörtliche Lesen konfigurieren, ACLs da MSK Replicator sie automatisch kopiert, wenn Sie die Option zum Kopieren von Zugriffskontrolllisten ausgewählt haben. Siehe [Replikation von Metadaten](msk-replicator-how-it-works.md#msk-replicator-metadata-replication).
# Failover zur sekundären Region AWS
Wir empfehlen Ihnen, die Replikationslatenz in der sekundären AWS Region mithilfe von Amazon zu überwachen CloudWatch. Während eines Serviceereignisses in der primären AWS Region kann die Replikationslatenz plötzlich ansteigen. Wenn die Latenz weiter zunimmt, verwenden Sie das AWS Service Health Dashboard, um nach Serviceereignissen in der primären AWS Region zu suchen. Wenn ein Ereignis eintritt, können Sie ein Failover auf die sekundäre AWS Region durchführen.
# Führen Sie ein geplantes Failover zur sekundären Region durch AWS
Sie können einen geplanten Failover durchführen, um die Widerstandsfähigkeit Ihrer Anwendung gegen ein unerwartetes Ereignis in Ihrer AWS Primärregion zu testen, in der sich Ihr MSK-Quellcluster befindet. Ein geplantes Failover sollte nicht zu Datenverlust führen.
Gehen Sie wie folgt vor, wenn Sie die Konfiguration für die Replikation identischer Themennamen verwenden:
1. Fahren Sie alle Produzenten und Verbraucher herunter, die eine Verbindung zum Quell-Cluster herstellen.
1. Erstellen Sie einen neuen MSK-Replikator, um Daten von Ihrem MSK-Cluster in der sekundären Region auf Ihren MSK-Cluster in der primären Region mit identischem Themennamen zu replizieren (**behalten Sie denselben Themennamen in der Konsole** bei). Dies ist erforderlich, um die Daten, die Sie in die sekundäre Region schreiben werden, zurück in die primäre Region zu kopieren, sodass Sie nach dem Ende des unerwarteten Ereignisses ein Failback zur primären Region durchführen können.
1. Starten Sie Produzenten und Verbraucher, die mit dem Zielcluster in der sekundären Region verbunden sind. AWS
Wenn Sie die Konfiguration eines Themennamens mit Präfix verwenden, gehen Sie für ein Failover wie folgt vor:
1. Fahren Sie alle Produzenten und Verbraucher herunter, die eine Verbindung zum Quell-Cluster herstellen.
1. Erstellen Sie einen neuen MSK-Replikator, um Daten aus Ihrem MSK-Cluster in der sekundären Region auf Ihren MSK-Cluster in der primären Region zu replizieren. Dies ist erforderlich, um die Daten, die Sie in die sekundäre Region schreiben werden, zurück in die primäre Region zu kopieren, sodass Sie nach dem Ende des unerwarteten Ereignisses ein Failback zur primären Region durchführen können.
1. Starten Sie die Produzenten auf dem Zielcluster in der sekundären AWS Region.
1. Befolgen Sie die Schritte auf einer der folgenden Registerkarten, je nachdem, welche Anforderungen Ihre Anwendung für die Nachrichtenreihenfolge hat.
------
#### [ No message ordering ]
Wenn für Ihre Anwendung keine Nachrichtenreihenfolge erforderlich ist, starten Sie Benutzer in der sekundären AWS Region, die sowohl aus dem lokalen (z. B. Thema) als auch aus den replizierten Themen (z. B.`.topic`) lesen, indem Sie einen Platzhalteroperator (z. B.`.*topic`) verwenden.
------
#### [ Message ordering ]
Wenn Ihre Anwendung eine Nachrichtenreihenfolge erfordert, starten Sie Verbraucher nur für die replizierten Themen auf dem Ziel-Cluster (z. B. `.topic`), aber nicht für die lokalen Themen (z. B. `topic`).
------
1. Warten Sie, bis alle Verbraucher replizierter Themen auf dem Ziel-MSK-Cluster die Verarbeitung aller Daten abgeschlossen haben, sodass die Verbraucherverzögerung 0 und die Anzahl der verarbeiteten Datensätze ebenfalls 0 ist. Stoppen Sie dann die Verbraucher für die replizierten Themen auf dem Ziel-Cluster. Zu diesem Zeitpunkt sind alle Datensätze, die vom Quell-MSK-Cluster auf den Ziel-MSK-Cluster repliziert wurden, verbraucht.
1. Starten Sie die Verbraucher für die lokalen Themen (z. B. `topic`) auf dem Ziel-MSK-Cluster.
# Führen Sie einen ungeplanten Failover zur sekundären Region durch AWS
Sie können einen ungeplanten Failover durchführen, wenn in der primären AWS Region, in der sich Ihr Quell-MSK-Cluster befindet, ein Serviceereignis auftritt und Sie Ihren Datenverkehr vorübergehend in die sekundäre Region umleiten möchten, in der sich Ihr Ziel-MSK-Cluster befindet. Ein ungeplanter Failover kann zu Datenverlusten führen, da MSK Replicator Daten asynchron repliziert. Sie können die Nachrichtenverzögerung anhand der Metriken unter verfolgen. [Überwachung einer Replikation](msk-replicator-monitor.md)
Wenn Sie die Konfiguration für die Replikation identischer Themennamen verwenden (**denselben Themennamen in der Konsole beibehalten**), gehen Sie wie folgt vor:
1. Versuchen Sie, alle Produzenten und Verbraucher, die in der primären Region eine Verbindung zum MSK-Quell-Cluster herstellen, herunterzufahren. Dieser Vorgang ist aufgrund von Einschränkungen in dieser Region möglicherweise nicht erfolgreich.
1. Starten Sie Hersteller und Verbraucher, die eine Verbindung zum Ziel-MSK-Cluster in der sekundären AWS Region herstellen, um den Failover abzuschließen. Da MSK Replicator auch Metadaten repliziert, einschließlich Lese ACLs - und Verbrauchergruppen-Offsets, können Ihre Produzenten und Verbraucher die Verarbeitung nahtlos an der Stelle fortsetzen, an der sie vor dem Failover aufgehört haben.
Wenn Sie die Konfiguration von `PREFIX` Themennamen verwenden, gehen Sie für ein Failover wie folgt vor:
1. Versuchen Sie, alle Produzenten und Verbraucher, die in der primären Region eine Verbindung zum MSK-Quell-Cluster herstellen, herunterzufahren. Dieser Vorgang ist aufgrund von Beeinträchtigungen in dieser Region möglicherweise nicht erfolgreich.
1. Starten Sie Hersteller und Verbraucher, die eine Verbindung zum Ziel-MSK-Cluster in der sekundären AWS Region herstellen, um den Failover abzuschließen. Da MSK Replicator auch Metadaten repliziert, einschließlich Lese ACLs - und Verbrauchergruppen-Offsets, können Ihre Produzenten und Verbraucher die Verarbeitung nahtlos an der Stelle fortsetzen, an der sie vor dem Failover aufgehört haben.
1. Befolgen Sie die Schritte auf einer der folgenden Registerkarten, je nachdem, welche Anforderungen Ihre Anwendung für die Nachrichtenreihenfolge hat.
------
#### [ No message ordering ]
Wenn für Ihre Anwendung keine Nachrichtenreihenfolge erforderlich ist, starten Sie Benutzer in der AWS Zielregion, die sowohl aus dem lokalen (z. B.) als auch aus dem replizierten Thema (z. B.`topic`) lesen, indem Sie einen Platzhalteroperator (z. B.`.topic`) verwenden. `.*topic`
------
#### [ Message ordering ]
1. Starten Sie Verbraucher nur für die replizierten Themen auf dem Ziel-Cluster (z. B. `.topic`), aber nicht für die lokalen Themen (z. B. `topic`).
1. Warten Sie, bis alle Verbraucher replizierter Themen auf dem Ziel-MSK-Cluster die Verarbeitung aller Daten abgeschlossen haben, sodass die Offset-Verzögerung 0 und die Anzahl der verarbeiteten Datensätze ebenfalls 0 ist. Stoppen Sie dann die Verbraucher für die replizierten Themen auf dem Ziel-Cluster. Zu diesem Zeitpunkt sind alle Datensätze, die vom Quell-MSK-Cluster auf den Ziel-MSK-Cluster repliziert wurden, verbraucht.
1. Starten Sie die Verbraucher für die lokalen Themen (z. B. `topic`) auf dem Ziel-MSK-Cluster.
------
1. Sobald das Serviceereignis in der primären Region beendet ist, erstellen Sie einen neuen MSK-Replikator, um Daten von Ihrem MSK-Cluster in der sekundären Region auf Ihren MSK-Cluster in der primären Region zu replizieren, wobei die Replicator-Startposition auf „Early“ gesetzt *ist*. Dies ist erforderlich, um die Daten, die Sie in die sekundäre Region schreiben werden, zurück in die primäre Region zu kopieren, sodass Sie nach dem Ende des Service-Ereignisses ein Failback zur primären Region durchführen können. *Wenn Sie die Replicator-Startposition nicht auf „Early“ setzen, werden alle Daten, die Sie während des Serviceereignisses in der primären Region für den Cluster in der sekundären Region erzeugt haben, nicht zurück in den Cluster in der primären Region kopiert.*
# Führen Sie ein Failback zur primären Region durch AWS
Sie können ein Failback zur primären AWS Region durchführen, nachdem das Serviceereignis in dieser Region beendet ist.
Gehen Sie wie folgt vor, wenn Sie die Konfiguration für die Replikation identischer Themennamen verwenden:
1. Erstellen Sie einen neuen MSK Replicator mit Ihrem sekundären Cluster als Quell- und primärem Cluster als Ziel, wobei die Startposition auf die *früheste* und die Replikation identischer Themennamen gesetzt ist (**behalten Sie denselben Themennamen in der** Konsole bei).
Dadurch wird der Vorgang gestartet, bei dem alle Daten, die nach dem Failover in den sekundären Cluster geschrieben wurden, zurück in die primäre Region kopiert werden.
1. Überwachen Sie die `MessageLag` Metrik auf dem neuen Replikator in Amazon, CloudWatch bis sie den Wert erreicht hat`0`, was bedeutet, dass alle Daten vom sekundären zum primären repliziert wurden.
1. Nachdem alle Daten repliziert wurden, beenden Sie alle Produzenten, die eine Verbindung zum sekundären Cluster herstellen, und starten Sie, dass die Produzenten eine Verbindung zum primären Cluster herstellen.
1. Warten Sie, bis die `MaxOffsetLag` Metrik erreicht ist, bis Ihre Verbraucher eine Verbindung zum sekundären Cluster hergestellt haben`0`, um sicherzustellen, dass sie alle Daten verarbeitet haben. Siehe [Überwachen Sie die Verzögerungen bei den Verbrauchern](consumer-lag.md).
1. Sobald alle Daten verarbeitet wurden, beenden Sie die Verbraucher in der sekundären Region und starten Sie die Verbindung der Verbraucher zum primären Cluster, um das Failback abzuschließen.
1. Löschen Sie den Replikator, den Sie im ersten Schritt erstellt haben und der Daten von Ihrem sekundären Cluster auf den primären Cluster repliziert.
1. Vergewissern Sie sich, dass Ihr vorhandener Replicator, der Daten vom primären zum sekundären Cluster kopiert, den Status „LÄUFT“ und in Amazon CloudWatch `0` die `ReplicatorThroughput` Metrik hat.
Beachten Sie, dass, wenn Sie einen neuen Replikator mit der Startposition „*Frühestens* für Failback“ erstellen, dieser damit beginnt, alle Daten in den Themen Ihrer sekundären Cluster zu lesen. Abhängig von Ihren Datenaufbewahrungseinstellungen können Ihre Themen Daten enthalten, die aus Ihrem Quellcluster stammen. MSK Replicator filtert diese Nachrichten zwar automatisch, es fallen jedoch weiterhin Datenverarbeitungs- und Übertragungsgebühren für alle Daten in Ihrem sekundären Cluster an. Sie können die gesamten vom Replicator verarbeiteten Daten mithilfe von verfolgen. `ReplicatorBytesInPerSec` Siehe [MSK-Replikatormetriken](msk-replicator-monitor.md#msk-replicator-metrics).
Wenn Sie die Konfiguration für Themennamen mit Präfix verwenden, gehen Sie wie folgt vor:
Sie sollten Failback-Schritte erst einleiten, wenn die Replikation vom Cluster in der sekundären Region zum Cluster in der primären Region aufgeholt hat und die MessageLag Metrik in Amazon nahe 0 CloudWatch liegt. Ein geplantes Failback sollte nicht zu Datenverlust führen.
1. Fahren Sie alle Produzenten und Verbraucher herunter, die in der sekundären Region eine Verbindung zum MSK-Cluster herstellen.
1. Löschen Sie bei einer Aktiv-Passiv-Topologie den Replikator, der Daten aus dem Cluster in der sekundären Region in die primäre Region repliziert. Sie müssen den Replikator für eine Aktiv-Aktiv-Topologie nicht löschen.
1. Starten Sie Produzenten, die eine Verbindung zum MSK-Cluster in der primären Region herstellen.
1. Befolgen Sie die Schritte auf einer der folgenden Registerkarten, je nachdem, welche Anforderungen Ihre Anwendung für die Nachrichtenreihenfolge hat.
------
#### [ No message ordering ]
Wenn für Ihre Anwendung keine Nachrichtenreihenfolge erforderlich ist, starten Sie Benutzer in der primären AWS Region, die sowohl aus den lokalen (z. B.`topic`) als auch aus den replizierten Themen (z. B.`.topic`) lesen, indem Sie einen Platzhalteroperator (z. B.) verwenden. `.*topic` Die Verbraucher, die sich mit lokalen Themen (z. B. Thema) befassen, beginnen ab dem letzten Offset, das sie vor dem Failover konsumiert haben. Wenn vor dem Failover unverarbeitete Daten vorhanden waren, werden diese jetzt verarbeitet. Im Falle eines geplanten Failovers sollte es keinen solchen Datensatz geben.
------
#### [ Message ordering ]
1. Starten Sie Verbraucher nur für die replizierten Themen in der primären Region (z. B. `.topic`), aber nicht für die lokalen Themen (z. B. `topic`).
1. Warten Sie, bis alle Verbraucher replizierter Themen auf dem Cluster in der primären Region die Verarbeitung aller Daten abgeschlossen haben, sodass die Offset-Verzögerung 0 und die Anzahl der verarbeiteten Datensätze ebenfalls 0 ist. Stoppen Sie dann die Verbraucher für die replizierten Themen auf dem Cluster in der primären Region. Zu diesem Zeitpunkt wurden alle Datensätze, die nach dem Failover in der sekundären Region erstellt wurden, in der primären Region verbraucht.
1. Starten Sie Verbraucher für die lokalen Themen (z. B. `topic`) auf dem Cluster in der primären Region.
------
1. Stellen Sie anhand der Metriken und Latenz sicher, dass sich der bestehende Replikator vom Cluster in der primären Region zum Cluster in der sekundären Region im Status RUNNING befindet und erwartungsgemäß funktioniert. `ReplicatorThroughput`
# Erstellen Sie mit MSK Replicator ein Active-Active-Setup
Wenn Sie ein Active-Active-Setup erstellen möchten, bei dem beide MSK-Cluster aktiv Lese- und Schreibvorgänge durchführen, empfehlen wir Ihnen, einen MSK Replicator mit Themennamenreplikation mit Präfix zu verwenden (Präfix zum Themennamen in der Konsole **hinzufügen**). Dazu müssen Sie jedoch Ihre Benutzer neu konfigurieren, damit sie die replizierten Themen lesen können.
Gehen Sie wie folgt vor, um eine Aktiv-Aktiv-Topologie zwischen dem Quell-MSK-Cluster A und dem Ziel-MSK-Cluster B einzurichten.
1. Erstellen Sie einen MSK-Replikator mit MSK-Cluster A als Quelle und MSK-Cluster B als Ziel.
1. Nachdem der obige MSK-Replikator erfolgreich erstellt wurde, erstellen Sie einen Replikator mit Cluster B als Quelle und Cluster A als Ziel.
1. Erstellen Sie zwei Gruppen von Produzenten, von denen jeder gleichzeitig Daten in das lokale Thema (z. B. „topic“) im Cluster in derselben Region wie der Produzent schreibt.
1. Erstellen Sie zwei Gruppen von Verbrauchern, die jeweils Daten mithilfe eines Wildcard-Abonnements lesen (z. B.“). \$1topic“) aus dem MSK-Cluster in derselben AWS Region wie der Verbraucher. Auf diese Weise lesen Ihre Verbraucher automatisch Daten, die lokal in der Region erzeugt wurden, aus dem lokalen Thema (z. B. `topic`) sowie Daten, die aus einer anderen Region repliziert wurden im Thema mit dem Präfix `.topic`. Diese beiden Gruppen von Verbrauchern sollten unterschiedliche Nutzergruppen haben, IDs damit die Offsets der Verbrauchergruppen nicht überschrieben werden, wenn MSK Replicator sie in den anderen Cluster kopiert.
Wenn Sie eine Neukonfiguration Ihrer Clients vermeiden möchten, können Sie anstelle der Replikation von Themennamen mit Präfix (**Präfix zum Themennamen in der Konsole hinzufügen**) die MSK-Replikatoren mithilfe der Replikation identischer Themennamen erstellen (**denselben Themennamen in der Konsole beibehalten**), um ein Active-Active-Setup zu erstellen. Sie müssen jedoch für jeden Replikator zusätzliche Datenverarbeitungs- und Datenübertragungsgebühren zahlen. Das liegt daran, dass jeder Replikator das Doppelte der üblichen Datenmenge verarbeiten muss, einmal für die Replikation und noch einmal, um Endlosschleifen zu vermeiden. Mithilfe der Metrik können Sie die Gesamtmenge der von jedem Replikator verarbeiteten Daten verfolgen. `ReplicatorBytesInPerSec` Siehe [Überwachung einer Replikation](msk-replicator-monitor.md). Diese Metrik umfasst die auf den Zielcluster replizierten Daten sowie die mit MSK Replicator gefilterten Daten, um zu verhindern, dass die Daten wieder auf dasselbe Thema zurückgeführt werden, aus dem sie stammen.
**Anmerkung**
Wenn Sie die Replikation identischer Themennamen verwenden (**denselben Themennamen in der Konsole beibehalten**), um eine aktiv-aktive Topologie einzurichten, warten Sie nach dem Löschen eines Themas mindestens 30 Sekunden, bevor Sie ein Thema mit demselben Namen erneut erstellen. Durch diese Wartezeit wird verhindert, dass doppelte Nachrichten zurück in den Quellcluster repliziert werden. Ihre Verbraucher müssen in der Lage sein, doppelte Nachrichten ohne nachgelagerte Auswirkungen erneut zu verarbeiten. Siehe [Überlegungen zur Erstellung von Apache Kafka-Anwendungen für mehrere Regionen](msk-replicator-increase-resiliency.md#msk-replication-multi-region-kafka-applications).
# Migrieren Sie mit MSK Replicator von einem Amazon MSK-Cluster zu einem anderen
Sie können die Replikation identischer Themennamen für die Cluster-Migration verwenden, aber Ihre Kunden müssen in der Lage sein, doppelte Nachrichten ohne nachgelagerte Auswirkungen zu verarbeiten. Das liegt daran, dass MSK Replicator at-least-once Replikation ermöglicht, was in seltenen Fällen zu doppelten Nachrichten führen kann. Wenn Ihre Kunden diese Anforderung erfüllen, gehen Sie wie folgt vor.
1. Erstellen Sie einen Replicator, der Daten von Ihrem alten Cluster auf den neuen Cluster repliziert, wobei die Startposition von Replicator auf „*Frühestest*“ gesetzt ist und die Replikation mit identischem Themennamen verwendet wird (**Behalten Sie denselben Themennamen in der** Konsole bei).
1. Konfigurieren Sie Einstellungen und Berechtigungen auf Clusterebene für den neuen Cluster. Sie müssen keine Einstellungen auf Themenebene konfigurieren und nicht „wörtlich“ lesen ACLs, da MSK Replicator sie automatisch kopiert.
1. Überwachen Sie die `MessageLag` Metrik in Amazon, CloudWatch bis sie 0 erreicht, was bedeutet, dass alle Daten repliziert wurden.
1. Nachdem alle Daten repliziert wurden, hindern Sie die Produzenten daran, Daten in den alten Cluster zu schreiben.
1. Konfigurieren Sie diese Producer neu, um eine Verbindung mit dem neuen Cluster herzustellen, und starten Sie sie.
1. Überwachen Sie die `MaxOffsetLag` Metrik für Ihre Kunden, die Daten aus dem alten Cluster lesen, bis es soweit ist`0`, was darauf hinweist, dass alle vorhandenen Daten verarbeitet wurden.
1. Stoppen Sie die Verbraucher, die eine Verbindung zum alten Cluster herstellen.
1. Konfigurieren Sie die Verbraucher neu, um eine Verbindung zum neuen Cluster herzustellen, und starten Sie sie.
# Migrieren Sie von Self-Managed MirrorMaker 2 zu MSK Replicator
Gehen Sie wie folgt vor, um von MirrorMaker (MM2) zu MSK Replicator zu migrieren:
1. Stoppen Sie den Producer, der in Ihren Amazon MSK-Quellcluster schreibt.
1. Erlauben Sie MM2 , alle Nachrichten zu den Themen Ihrer Quell-Cluster zu replizieren. Sie können in Ihrem MSK-Quellcluster die Verzögerung MM2 zwischen Verbrauchern und Verbrauchern überwachen, um festzustellen, wann alle Daten repliziert wurden.
1. Erstellen Sie einen neuen Replikator, wobei die Startposition auf *Aktuell* und die Konfiguration des Themennamens auf `IDENTICAL` (**Replikation unter gleichen Themennamen** in der Konsole) gesetzt ist.
1. Sobald sich Ihr Replicator im Status RUNNING befindet, können Sie die Producer erneut damit beginnen, in den Quell-Cluster zu schreiben.
# Problembehandlung bei MSK Replicator
Die folgenden Informationen können zum Beheben von Problemen mit MSK-Replikator nützlich sein. Informationen [Problembehandlung bei Ihrem Amazon MSK-Cluster](troubleshooting.md) zur Problemlösung zu anderen Amazon MSK-Funktionen finden Sie unter. Sie können Ihr Problem auch im [AWS re:Post](https://repost.aws/) posten.
## Der Status des MSK-Replikators wechselt von CREATING zu FAILED
Im Folgenden sind einige der häufigsten Ursachen für Fehler bei der Erstellung des MSK-Replikators aufgeführt.
1. Stellen Sie sicher, dass die Sicherheitsgruppen, die Sie für den Replikator im Ziel-Cluster-Bereich angeben, über Regeln für ausgehenden Datenverkehr zu den Sicherheitsgruppen Ihres Ziel-Clusters verfügen. Stellen Sie außerdem sicher, dass die Sicherheitsgruppen Ihres Ziel-Clusters über Regeln für eingehenden Datenverkehr aus den Sicherheitsgruppen verfügen, die Sie im Ziel-Cluster-Bereich für die Replikator-Erstellung bereitstellen. Siehe [Wählen Sie den Ziel-Cluster](msk-replicator-create-console.md#msk-replicator-create-console-choose-target).
1. Wenn Sie einen Replikator für die regionsübergreifende Replikation erstellen, stellen Sie sicher, dass in Ihrem Quell-Cluster Multi-VPC-Konnektivität für die IAM-Access-Control-Authentifizierungsmethode aktiviert ist. Siehe [Private Multi-VPC-Konnektivität von Amazon MSK in einer einzelnen Region](aws-access-mult-vpc.md). Stellen Sie außerdem sicher, dass die Cluster-Richtlinie auf dem Quell-Cluster eingerichtet ist, sodass der MSK-Replikator eine Verbindung zum Quell-Cluster herstellen kann. Siehe [Bereiten Sie den Amazon MSK-Quellcluster vor](msk-replicator-prepare-cluster.md).
1. Stellen Sie sicher, dass die IAM-Rolle, die Sie bei der Erstellung des MSK-Replikators angegeben haben, über die erforderlichen Berechtigungen zum Lesen und Schreiben in die Quell- und Ziel-Cluster verfügt. Stellen Sie außerdem sicher, dass die IAM-Rolle über Schreibberechtigungen für Themen verfügt. Siehe [Einstellungen und Berechtigungen des Replikators konfigurieren](msk-replicator-create-console.md#msk-replicator-create-settings)
1. Stellen Sie sicher, dass Ihr Netzwerk ACLs die Verbindung zwischen dem MSK Replicator und Ihren Quell- und Zielclustern nicht blockiert.
1. Es ist möglich, dass Quell- oder Ziel-Cluster nicht vollständig verfügbar waren, als der MSK-Replikator versucht hat, eine Verbindung zu ihnen herzustellen. Dies kann auf eine übermäßige Last, Festplattennutzung oder CPU-Auslastung zurückzuführen sein, wodurch der Replikator keine Verbindung zu den Brokern herstellen kann. Beheben Sie das Problem mit den Brokern und versuchen Sie erneut, den Replikator zu erstellen.
Nachdem Sie die oben genannten Validierungen durchgeführt haben, erstellen Sie den MSK-Replikator erneut.
## Der MSK-Replikator scheint im Status CREATING festzustecken
Gelegentlich dauert die MSK-Replikator-Erstellung bis zu 30 Minuten. Warten Sie 30 Minuten und überprüfen Sie den Status des Replikators erneut.
## Der MSK-Replikator repliziert keine Daten oder repliziert nur Teildaten
Gehen Sie wie folgt vor, um Probleme bei der Datenreplikation zu beheben.
1. Stellen Sie anhand der von MSK Replicator in Amazon bereitgestellten AuthError Metrik sicher, dass bei Ihrem Replicator keine Authentifizierungsfehler auftreten. CloudWatch Wenn diese Metrik über 0 liegt, können Sie überprüfen, ob die Richtlinie der IAM-Rolle für den Replikator gültig ist, und sicherstellen, dass für die Cluster-Berechtigungen keine Verweigerungs-Berechtigungen festgelegt sind. Anhand der clusterAlias-Dimension können Sie feststellen, ob im Quell- oder Ziel-Cluster Authentifizierungsfehler auftreten.
1. Stellen Sie sicher, dass bei Ihren Quell- und Ziel-Clustern keine Probleme auftreten. Es ist möglich, dass der Replikator keine Verbindung zu Ihrem Quell- oder Ziel-Cluster herstellen kann. Dies kann auf zu viele Verbindungen, eine voll ausgelastete Festplatte oder eine hohe CPU-Auslastung zurückzuführen sein.
1. Stellen Sie anhand der KafkaClusterPingSuccessCount Metrik in Amazon sicher, dass Ihre Quell- und Zielcluster von MSK Replicator aus erreichbar sind. CloudWatch Anhand der clusterAlias-Dimension können Sie feststellen, ob im Quell- oder Ziel-Cluster Authentifizierungsfehler auftreten. Wenn diese Metrik 0 ist oder keinen Datenpunkt hat, ist die Verbindung fehlerhaft. Sie sollten die Netzwerk- und IAM-Rollenberechtigungen überprüfen, die MSK-Replikator für die Verbindung mit Ihren Clustern verwendet.
1. Stellen Sie anhand der ReplicatorFailure Metrik in Amazon sicher, dass Ihr Replicator nicht aufgrund fehlender Berechtigungen auf Themenebene ausfällt. CloudWatch Wenn diese Metrik über 0 liegt, überprüfen Sie die von Ihnen angegebene IAM-Rolle für Berechtigungen auf Themenebene.
1. Vergewissern Sie sich, dass der reguläre Ausdruck, den Sie bei der Erstellung des Replikators in der Zulassungsliste angegeben haben, mit den Namen der Themen übereinstimmt, die Sie replizieren möchten. Stellen Sie außerdem sicher, dass die Themen nicht aufgrund eines regulären Ausdrucks in der Verweigerungsliste von der Replikation ausgeschlossen werden.
1. Beachten Sie, dass es bis zu 30 Sekunden dauern kann, bis der Replicator die neuen Themen oder Themenpartitionen auf dem Zielcluster erkennt und erstellt. Alle Nachrichten, die an das Quellthema gesendet wurden, bevor das Thema auf dem Zielcluster erstellt wurde, werden nicht repliziert, wenn der Replikator die neueste Startposition hat (Standard). Sie können die Replikation auch vom frühesten Offset in den Themenpartitionen des Quellclusters starten, wenn Sie vorhandene Nachrichten zu Ihren Themen auf dem Zielcluster replizieren möchten. Siehe [Einstellungen und Berechtigungen des Replikators konfigurieren](msk-replicator-create-console.md#msk-replicator-create-settings).
## Die Nachrichtenoffsets im Zielcluster unterscheiden sich von denen im Quellcluster
Im Rahmen der Datenreplikation verarbeitet MSK Replicator Nachrichten aus dem Quellcluster und sendet sie an den Zielcluster. Dies kann dazu führen, dass Nachrichten auf Ihren Quell- und Zielclustern unterschiedliche Offsets aufweisen. Wenn Sie jedoch bei der Erstellung des Replikators die Synchronisierung von Offsets für Nutzergruppen aktiviert haben, übersetzt MSK Replicator die Offsets beim Kopieren der Metadaten automatisch, sodass Ihre Benutzer nach einem Failover zum Zielcluster die Verarbeitung fast dort fortsetzen können, wo sie im Quellcluster aufgehört haben.
## MSK Replicator synchronisiert keine Nutzungsgruppen, Offsets oder die Nutzungsgruppe ist auf dem Zielcluster nicht vorhanden
Gehen Sie wie folgt vor, um Probleme mit der Metadatenreplikation zu beheben.
1. Stellen Sie sicher, dass Ihre Datenreplikation wie erwartet funktioniert. Falls nicht, siehe [Der MSK-Replikator repliziert keine Daten oder repliziert nur Teildaten](#msk-replicator-troubleshooting-not-replicating).
1. Vergewissern Sie sich, dass der reguläre Ausdruck, den Sie bei der Erstellung des Replikators in der Zulassungsliste angegeben haben, mit den Namen der Nutzergruppen übereinstimmt, die Sie replizieren möchten. Stellen Sie außerdem sicher, dass die Nutzergruppen nicht aufgrund eines regulären Ausdrucks in der Ablehnungsliste von der Replikation ausgeschlossen werden.
1. Stellen Sie sicher, dass MSK Replicator das Thema auf dem Zielcluster erstellt hat. Es kann bis zu 30 Sekunden dauern, bis der Replicator die neuen Themen oder Themenpartitionen auf dem Zielcluster erkannt und erstellt hat. Alle Nachrichten, die an das Quellthema gesendet wurden, bevor das Thema auf dem Zielcluster erstellt wurde, werden nicht repliziert, wenn der Replikator die *neueste* Startposition hat (Standard). Wenn Ihre Nutzergruppe auf dem Quellcluster nur die Nachrichten verwendet hat, die nicht von MSK Replicator repliziert wurden, wird die Nutzungsgruppe nicht auf den Zielcluster repliziert. Nachdem das Thema erfolgreich auf dem Zielcluster erstellt wurde, beginnt MSK Replicator mit der Replikation neu geschriebener Nachrichten auf dem Quellcluster auf das Ziel. Sobald Ihre Nutzergruppe beginnt, diese Nachrichten von der Quelle zu lesen, repliziert MSK Replicator die Nutzergruppe automatisch auf den Zielcluster. Alternativ können Sie die Replikation ab dem frühesten Offset in den Themenpartitionen des Quell-Clusters starten, wenn Sie vorhandene Nachrichten zu Ihren Themen auf dem Zielcluster replizieren möchten. Siehe [Einstellungen und Berechtigungen des Replikators konfigurieren](msk-replicator-create-console.md#msk-replicator-create-settings).
**Anmerkung**
MSK Replicator optimiert die Offset-Synchronisierung von Nutzergruppen für Ihre Benutzer auf dem Quellcluster, die von einer Position aus lesen, die näher am Ende der Themenpartition liegt. Wenn Ihre Nutzergruppen im Quell-Cluster hinterherhinken, können Sie bei diesen Nutzergruppen auf dem Ziel-Cluster eine höhere Verzögerung feststellen als beim Quell-Cluster. Das bedeutet, dass Ihre Kunden nach einem Failover auf den Zielcluster mehr doppelte Nachrichten erneut verarbeiten werden. Um diese Verzögerung zu verringern, müssten Ihre Verbraucher auf dem Quell-Cluster aufholen und von der Spitze des Streams (Ende der Themenpartition) aus mit dem Konsum beginnen. Wenn Ihre Kunden aufholen, reduziert MSK Replicator die Verzögerung automatisch.
## Die Replikationslatenz ist hoch oder nimmt weiter zu
Im Folgenden sind einige der häufigsten Ursachen für eine hohe Replikationslatenz aufgeführt.
1. Stellen Sie sicher, dass Sie die richtige Anzahl von Partitionen auf Ihren Quell- und Ziel-MSK-Clustern haben. Zu wenige oder zu viele Partitionen können sich auf die Leistung auswirken. Hinweise zur Auswahl der Anzahl von Partitionen finden Sie unter [Bewährte Methoden für die Verwendung von MSK-Replikator](msk-replicator-best-practices.md). Die folgende Tabelle zeigt die empfohlene Mindestanzahl von Partitionen, um mit MSK-Replikator den gewünschten Durchsatz zu erzielen.
**Durchsatz und empfohlene Mindestanzahl von Partitionen**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/msk/latest/developerguide/msk-replicator-troubleshooting.html)
1. Stellen Sie sicher, dass Ihre Quell- und Ziel-MSK-Cluster über genügend Lese- und Schreibkapazität verfügen, um den Replikations-Datenverkehr zu unterstützen. MSK-Replikator fungiert als Verbraucher für Ihren Quell-Cluster (Ausgang) und als Produzent für Ihren Ziel-Cluster (Eingang). Daher sollten Sie Cluster-Kapazität bereitstellen, um den Replikations-Datenverkehr zusätzlich zu anderem Datenverkehr auf Ihren Clustern zu unterstützen. Hinweise zur Dimensionierung Ihrer MSK-Cluster finden Sie unter [Bewährte Methoden für die Verwendung von MSK-Replikator](msk-replicator-best-practices.md).
1. Die Replikationslatenz kann für MSK-Cluster in verschiedenen Quell- und AWS Zielregionspaaren variieren, je nachdem, wie weit die Cluster geografisch voneinander entfernt sind. Beispielsweise ist die Replikationslatenz bei der Replikation zwischen Clustern in den Regionen Europa (Irland) und Europa (London) in der Regel niedriger als bei der Replikation zwischen Clustern in den Regionen Europa (Irland) und Asien-Pazifik (Sydney).
1. Stellen Sie sicher, dass Ihr Replikator nicht aufgrund zu aggressiver Kontingente auf Ihren Quell- oder Ziel-Clustern gedrosselt wird. Sie können die von MSK Replicator in Amazon bereitgestellte ThrottleTime Metrik verwenden, CloudWatch um die durchschnittliche Zeit in Millisekunden zu ermitteln, für die eine Anfrage von Brokern in Ihrem Cluster gedrosselt wurde. source/target Wenn diese Metrik über 0 liegt, sollten Sie die Kafka-Kontingente anpassen, um die Drosselung zu reduzieren, damit der Replikator aufholen kann. Informationen zur Verwaltung von Kafka-Kontingenten für den Replikator finden Sie unter [Verwaltung des MSK-Replikator-Durchsatzes mithilfe von Kafka-Kontingenten](msk-replicator-best-practices.md#msk-replicator-manage-throughput-kafka-quotas).
1. ReplicationLatency und MessageLag kann sich erhöhen, wenn eine Region heruntergestuft wird. AWS Verwenden Sie das [AWS Service Health Dashboard](https://health.aws.amazon.com/health/status), um in der Region, in der sich Ihr primärer MSK-Cluster befindet, nach einem MSK-Service-Ereignis zu suchen. Wenn ein Service-Ereignis eintritt, können Sie die Lese- und Schreibvorgänge Ihrer Anwendung vorübergehend an die andere Region weiterleiten.
## Behebung von MSK Replicator-Fehlern mithilfe von Metriken ReplicatorFailure
Die ReplicatorFailure Metrik hilft Ihnen bei der Überwachung und Erkennung von Replikationsproblemen in MSK Replicator. Ein Wert ungleich Null dieser Metrik weist in der Regel auf ein Problem mit einem Replikationsfehler hin, das auf die folgenden Faktoren zurückzuführen sein kann:
+ Beschränkungen der Nachrichtengröße
+ Verstöße gegen den Zeitstempelbereich
+ Probleme mit der Batchgröße aufzeichnen
Wenn die ReplicatorFailure Metrik einen Wert ungleich Null meldet, gehen Sie wie folgt vor, um das Problem zu beheben.
**Anmerkung**
Weitere Informationen zu dieser Metrik finden Sie unter [MSK-Replikatormetriken](msk-replicator-monitor.md#msk-replicator-metrics).
1. Konfigurieren Sie einen Client, der eine Verbindung zum Ziel-MSK-Cluster herstellen kann und für den die Apache Kafka CLI-Tools eingerichtet sind. Informationen zur Einrichtung des Clients und des Kafka-CLI-Tools finden Sie unter[Stellen Sie eine Connect zu einem von Amazon MSK bereitgestellten Cluster her](client-access.md).
1. Die Amazon MSK-Konsole zu [https://console.aws.amazon.com/msk/Hause öffnen? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
Führen Sie dann die folgenden Schritte aus:
1. Besorgen Sie sich den MSK Replicator und den Ziel-MSK-Cluster. ARNs
1. [Besorgen Sie sich die Broker-Endpunkte des Ziel-MSK-Clusters](get-bootstrap-console.md). Sie werden diese Endpunkte in den folgenden Schritten verwenden.
1. Führen Sie die folgenden Befehle aus, um den MSK Replicator-ARN und die Broker-Endpunkte zu exportieren, die Sie im vorherigen Schritt erhalten haben.
Stellen Sie sicher, dass Sie die in den folgenden Beispielen verwendeten Platzhalterwerte für < *ReplicatorARN* *BootstrapServerString* >, < *ConsumerConfigFile* > und < > durch ihre tatsächlichen Werte ersetzen.
```
export TARGET_CLUSTER_SERVER_STRING=
```
```
export REPLICATOR_ARN=
```
```
export CONSUMER_CONFIG_FILE=
```
1. Gehen Sie in Ihrem `/bin` Verzeichnis wie folgt vor:
1. Speichern Sie das folgende Skript und geben Sie ihm einen Namen**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. Führen Sie dieses Skript aus, um die MSK Replicator-Fehlermeldungen abzufragen.
```
/bin/query-replicator-failure-message.sh --replicator-arn $REPLICATOR_ARN --bootstrap-server $TARGET_CLUSTER_SERVER_STRING --consumer.config $CONSUMER_CONFIG_FILE
```
Dieses Skript gibt alle Fehler mit ihren Ausnahmemeldungen und den betroffenen Themenpartitionen aus. Sie können diese Ausnahmeinformationen verwenden, um die Fehler zu beheben, wie unter beschrieben. [Häufige MSK Replicator-Fehler und ihre Lösungen](#msk-replicator-ReplicatorFailure-error-mitigation) Da das Thema alle historischen Fehlermeldungen enthält, sollten Sie die Untersuchung anhand der letzten Meldung beginnen. Im Folgenden finden Sie ein Beispiel für eine Fehlermeldung.
```
ReplicatorException: The request included a message larger than the max message size the server will accept. Topic: test, Partition: 1
```
### Häufige MSK Replicator-Fehler und ihre Lösungen
In der folgenden Liste werden einige der MSK Replicator-Fehler beschrieben, die bei Ihnen auftreten können, und wie Sie diese beheben können.
**Nachrichtengröße größer als max.request.size**
**Ursache**
Dieser Fehler tritt auf, wenn der MSK Replicator Daten nicht repliziert, weil die Größe der einzelnen Nachrichten 10 MB überschreitet. Standardmäßig repliziert MSK Replicator Nachrichten mit einer Größe von bis zu 10 MB.
Im Folgenden finden Sie ein Beispiel für diesen Fehlermeldungstyp.
```
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
```
**Lösung**
Reduzieren Sie die Größe der einzelnen Nachrichten in Ihrem Thema. Wenn Sie dazu nicht in der Lage sind, folgen Sie diesen Anweisungen, [um eine Erhöhung des Limits zu beantragen](limits.md#request-msk-quota-increase).
**Nachrichtengröße, die größer ist als die maximale Nachrichtengröße, die der Server akzeptiert**
**Ursache**
Dieser Fehler tritt auf, wenn die Nachrichtengröße die maximale Nachrichtengröße des Zielclusters überschreitet.
Im Folgenden finden Sie ein Beispiel für diesen Fehlermeldungstyp.
```
ReplicatorException: The request included a message larger than the max message size the server will accept. Topic: test, Partition: 1
```
**Lösung**
Erhöhen Sie die `max.message.bytes` Konfiguration für den Zielcluster oder das entsprechende Zielcluster-Thema. Stellen Sie die `max.message.bytes` Konfiguration des Zielclusters so ein, dass sie Ihrer größten unkomprimierten Nachrichtengröße entspricht. Informationen dazu finden Sie unter [max.message.bytes](https://kafka.apache.org/documentation/#topicconfigs_max.message.bytes).
**Der Zeitstempel liegt außerhalb des zulässigen Bereichs**
**Ursache**
Dieser Fehler tritt auf, weil der Zeitstempel der einzelnen Nachricht außerhalb des zulässigen Bereichs des Zielclusters liegt.
Im Folgenden finden Sie ein Beispiel für diesen Fehlermeldungstyp.
```
ReplicatorException: Timestamp 1730137653724 of message with offset 0 is out of range. The timestamp should be within [1730137892239, 1731347492239] Topic: test, Partition: 1
```
**Lösung**
Aktualisieren Sie die `message.timestamp.before.max.ms` Konfiguration des Zielclusters, um Nachrichten mit älteren Zeitstempeln zuzulassen. Informationen dazu finden Sie unter [message.timestamp.before.max.ms](https://kafka.apache.org/documentation/#topicconfigs_message.timestamp.before.max.ms).
**Der Datensatzstapel ist zu groß**
**Ursache**
Dieser Fehler tritt auf, weil die Batchgröße des Datensatzes die für das Thema auf dem Zielcluster festgelegte Segmentgröße überschreitet. MSK Replicator unterstützt eine maximale Batchgröße von 1 MB.
Im Folgenden finden Sie ein Beispiel für diesen Fehlermeldungstyp.
```
ReplicatorException: The request included message batch larger than the configured segment size on the server. Topic: test, Partition: 1
```
**Lösung**
Die segment.bytes-Konfiguration des Zielclusters muss mindestens so groß wie die Batchgröße (1 MB) sein, damit Replicator fehlerfrei fortfahren kann. Aktualisieren Sie den Wert segment.bytes des Zielclusters auf mindestens 1048576 (1 MB). [Informationen dazu finden Sie unter segment.bytes.](https://kafka.apache.org/documentation/#topicconfigs_segment.bytes)
**Anmerkung**
Wenn die ReplicatorFailure Metrik nach der Anwendung dieser Lösungen weiterhin Werte ungleich Null ausgibt, wiederholen Sie den Fehlerbehebungsprozess, bis die Metrik einen Wert von Null ausgibt.
# Bewährte Methoden für die Verwendung von MSK-Replikator
In diesem Abschnitt werden allgemeine bewährte Methoden und Implementierungsstrategien für die Verwendung von Amazon MSK Replicator behandelt.
**Contents**
+ [Verwaltung des MSK-Replikator-Durchsatzes mithilfe von Kafka-Kontingenten](#msk-replicator-manage-throughput-kafka-quotas)
+ [Festlegen des Cluster-Aufbewahrungszeitraums](#msk-replicator-retention-period)
## Verwaltung des MSK-Replikator-Durchsatzes mithilfe von Kafka-Kontingenten
Da MSK-Replikator als Verbraucher für Ihren Quell-Cluster fungiert, kann die Replikation dazu führen, dass andere Verbraucher im Quell-Cluster gedrosselt werden. Der Umfang der Drosselung hängt von der Lesekapazität Ihres Quell-Clusters und dem Datendurchsatz ab, den Sie replizieren. Wir empfehlen, dass Sie identische Kapazität für Ihre Quell- und Ziel-Cluster bereitstellen und den Replikationsdurchsatz bei der Berechnung der benötigten Kapazität berücksichtigen.
Sie können auch Kafka-Kontingente für den Replikator auf Ihren Quell- und Ziel-Clustern festlegen, um zu kontrollieren, wie viel Kapazität der MSK-Replikator nutzen kann. Ein Netzwerkbandbreiten-Kontingent wird empfohlen. Ein Netzwerkbandbreiten-Kontingent definiert einen Schwellenwert für die Byterate, definiert als Bytes pro Sekunde, für einen oder mehrere Clients, die sich ein Kontingent teilen. Dieses Kontingent wird für jeden Broker individuell festgelegt.
Gehen Sie wie folgt vor, um ein Kontingent anzuwenden.
1. Rufen Sie die Bootstrap-Server-Zeichenfolge für den Quell-Cluster ab. Siehe [Holen Sie sich die Bootstrap-Broker für einen Amazon MSK-Cluster](msk-get-bootstrap-brokers.md).
1. Rufen Sie die vom MSK-Replikator verwendete Service-Ausführungsrolle (SER) ab. Dies ist die SER, die Sie für eine `CreateReplicator`-Anfrage verwendet haben. Sie können den SER auch aus der DescribeReplicator Antwort eines vorhandenen Replicators abrufen.
1. Führen Sie mit den Kafka-CLI-Tools den folgenden Befehl für den Quell-Cluster aus.
```
./kafka-configs.sh --bootstrap-server --alter --add-config 'consumer_byte_
rate=' --entity-type users --entity-name arn:aws:sts:::assumed-role// --command-config
```
1. Stellen Sie nach der Ausführung des obigen Befehls sicher, dass die `ReplicatorThroughput`-Metrik das von Ihnen festgelegte Kontingent nicht überschreitet.
Beachten Sie, dass, wenn Sie eine Service-Ausführungsrolle zwischen mehreren MSK-Replikatoren wiederverwenden, diese alle diesem Kontingent unterliegen. Wenn Sie separate Kontingente pro Replikator beibehalten möchten, verwenden Sie separate Service-Ausführungsrollen.
Weitere Informationen zur Verwendung der MSK-IAM-Authentifizierung mit Kontingenten finden Sie unter [Multi-Tenancy-Apache-Kafka-Cluster in Amazon MSK mit IAM-Zugriffssteuerung und Kafka-Kontingente – Teil 1](https://aws.amazon.com/blogs/big-data/multi-tenancy-apache-kafka-clusters-in-amazon-msk-with-iam-access-control-and-kafka-quotas-part-1/).
**Warnung**
Die Einstellung einer extrem niedrigen consumer\$1byte\$1rate kann dazu führen, dass Ihr MSK-Replikator auf unerwartete Weise reagiert.
## Festlegen des Cluster-Aufbewahrungszeitraums
Sie können den Aufbewahrungszeitraum für Protokolle für von MSK bereitgestellte Cluster und Serverless-Cluster festlegen. Der empfohlene Aufbewahrungszeitraum beträgt 7 Tage. Weitere Informationen unter [Änderungen der Cluster-Konfiguration](msk-replicator-serverless-requirements.md#msk-replicator-config-changes) oder [Unterstützte serverlose MSK-Clusterkonfiguration](msk-replicator-serverless-requirements.md).