Spiegelung verwenden
Durch das Spiegeln können Nachrichten in einer Event Streams-Serviceinstanz kontinuierlich in eine zweite Instanz kopiert werden. Die Ausfallsicherheit von Anwendungen kann verbessert werden, indem die Spiegelung so verwendet wird, als wäre die erste Serviceinstanz nicht mehr verfügbar. Anwendungen können die Verbindung zur zweiten Instanz wiederherstellen und ihren normalen Betrieb fortsetzen.
Dieses Feature ist Teil des vollständig verwalteten Service und kann nur zwischen Serviceinstanzen verwendet werden, die den Unternehmensplan Event Streams verwenden.
Funktionen der Spiegelung:
- Spiegeln Sie Themen, Nachrichtendaten und Konsumentengruppen-Offsets zwischen zwei Event Streams-Serviceinstanzen, die in verschiedenen IBM Cloud-Konten bereitgestellt werden können.
- SLA mit einer Verfügbarkeit von 99.99%, konsistent mit dem Service Event Streams.
- Kann mit IBM Cloud® Monitoringüberwacht werden.
Einschränkungen der Spiegelung:
- Unidirektional: Daten können jeweils nur in einer Richtung zwischen zwei Serviceinstanzen gespiegelt werden. Dies bedeutet, dass die Spiegelung einen "aktiv-passiven" Stil der Hochverfügbarkeit bietet, nicht "aktiv-aktiv".
- Asynchron: Nachrichten müssen erfolgreich für die Quelleninstanz erzeugt werden, damit sie auf die Zielinstanz gespiegelt werden können. Das bedeutet, dass bei einem Fehler im Zielcluster aufgrund der Replikationsverzögerung möglicherweise nicht alle Nachrichten bis zum genauen Fehlerpunkt vorliegen und einige Nachrichtendaten verloren gehen können.
- At-least-once-Nachrichtenkonsum: Wenn ein Konsument zwischen Instanzen wechselt, muss er möglicherweise bereits verarbeitete Nachrichten erneut verarbeiten.
Beachten Sie vor dem Starten der Spiegelung die folgenden Punkte:
- Möglicherweise müssen Anwendungen geändert werden, um die Vorteile der Spiegelung optimal zu nutzen.
- Stellen Sie sicher, dass für den Netzverkehr, der zum Spiegeln von Daten zwischen Instanzen verwendet wird, ausreichend Kapazität verfügbar ist.
Informationen zur Aktivierung der Spiegelung finden Sie in der Anleitung zum Einrichten der Spiegelung.
Übersicht über die Spiegelung
Die Spiegelung ausgewählter Topics erfolgt zwischen zwei Clustern und ist unidirektional. Das heißt, dass Daten nur in einer Richtung von einem einzelnen Quellencluster auf einen einzelnen Zielcluster gespiegelt werden. Jeder Cluster hat einen
Spiegelungsalias. In diesem Dokument wird A
als Quellenclusteralias und B
als Zielclusteralias verwendet. Die Aliasnamen sind konfigurierbar, wenn die Spiegelung aktiviert ist. Sie können beispielsweise "us-south"
und "us-east" lauten.
Ein Thema namens mytopic
aus dem Quellcluster (A) erscheint im Zielcluster (B) als mytopic.A
, was darauf hinweist, dass es von A
stammt. Diese Art von Thema wird als Remote-Thema bezeichnet, da
es aus dem Remote-Cluster (Quellcluster) stammt. Im Gegensatz dazu werden alle Themen, die direkt von Benutzern im Zielcluster erstellt werden, als lokale Themen bezeichnet.
Um auszuwählen, welche Themen gespiegelt werden, kann mithilfe von "Mirroring User Controls" ein Muster für reguläre Ausdrücke konfiguriert werden.
Durch die Spiegelung werden Consumer-Offsets automatisch zwischen den Quellen-und Zielinstanzen umgesetzt. In früheren Versionen von Event Streamsmussten Konsumenten ein spezielles Thema namens A.checkpoints.internal
verwenden (dabei
ist A
der Aliasname des Quellenclusters). Dies ist nicht mehr erforderlich, aber das Prüfpunktthema wird weiterhin vom Spiegelungsprozess erstellt und aktualisiert, um die Abwärtskompatibilität mit vorhandenen Anwendungen sicherzustellen.
Anwendungen, die das Prüfpunktthema verwenden möchten, können den Kafka MirrorClient verwenden, um den Zugriff
auf die in diesem Thema gespeicherten Daten zu vereinfachen.
Schließlich aufgrund der Benennung von fernen Themen:
- Verwenden Sie keine Clusteraliasnamen als Teil der Kafka-Ressourcennamen.
- Stellen Sie sicher, dass der Name des fernen Topics (z. B. Quellentopic und Quellenclusteralias) die Längenbegrenzung für Kafka-Topics (249 Zeichen) nicht überschreitet. Wenn der Name eines fernen Themas diesen Grenzwert überschreitet, werden Nachrichten für das Thema nicht gespiegelt.
Kapazitätsplanung
Bei der Planung der Kapazität müssen sowohl die Netzwerknutzung als auch der geografische Standort der Quell- und Zieldienstinstanzen berücksichtigt werden.
Netzbandbreite
Die Netzwerkbandbreite, die für die Spiegelung der ausgewählten Themen benötigt wird, muss bei der Bandbreitenzuweisung sowohl der Quell- als auch der Zieldienstinstanzen berücksichtigt werden. Wenn beispielsweise 10 MB/s des Nachrichtenverkehrs von Anwendungen in der Quelldienstinstanz zu den gespiegelten Themen erzeugt werden, sind zusätzliche 10 MB/s ausgehender Bandbreite erforderlich, um diese Nachrichten in die Zielinstanz zu spiegeln. Dies muss neben der vorhandenen ausgehenden Bandbreite, die bereits von verbrauchenden Anwendungen genutzt wird, berücksichtigt werden. Die Netzauslastung in einer Serviceinstanz lässt sich mithilfe der Überwachungsdashboards ermitteln. Weitere Informationen finden Sie unter Event Streams-Metriken überwachen.
Geografischer Standort
Wie bei jedem Netzbetrieb ist der maximal erreichbare Durchsatz ein Faktor der Distanz, über die Daten übertragen werden (aufgrund der steigenden Latenz und des steigenden Paketverlusts). Dies wirkt sich auf den maximalen Durchsatz aus, der zwischen den Quell- und Zielinstanzen erreicht werden kann. Platzieren Sie die Ziel-Service-Instanzen an einem geografisch möglichst nahen Standort zur Quelle.
Die folgende Tabelle enthält Richtwerte für den erreichbaren Durchsatz beim Spiegeln von einer Quellinstanz mit einer Kapazität von 150 MB/s.
Regionen | Max. Durchsatz pro Partition | Max. Gesamtdurchsatz |
---|---|---|
us-south <-> us-east | 1,5 MB/s | 35 MB/s |
eu-gb <-> eu-de | 2,5 MB/s | 35 MB/s |
au-syd <-> jp-tok | 0,4 MB/s | 12 MB/s |
Innerhalb derselben Region eu-gb <-> eu-gb | 2,5 MB/s | 35 MB/s |
Die Werte geben Folgendes an:
- Max. Gesamtdurchsatz: Die maximale Gesamtrate in MB/s, die für alle ausgewählten Topics gespiegelt werden kann.
- Max. Durchsatz pro Partition: Die maximale Rate in MB/s, die innerhalb einer einzelnen Partition gespiegelt werden kann. Wählen Sie die Anzahl der Partitionen aus, die für die Quellenthemen konfiguriert sind, um sicherzustellen, dass die Auslastung pro Partition innerhalb dieses Grenzwerts bleibt.
Eine Überschreitung der Grenzwerte führt zu einer zunehmenden Verzögerung zwischen den Daten in den Quell- und Zielinstanzen. Eine große Datenverzögerung kann dazu führen, dass eine größere Menge an Nachrichtendaten verloren geht, wenn die Quelleninstanz fehlschlägt. Auch wenn die Verzögerung zwischen Instanzen null ist, sollten Sie, da die Spiegelung asynchron ist, davon ausgehen, dass einige Daten verloren gehen können, wenn die Quelleninstanz fehlschlägt. Zur Ermittlung der Latenz für jedes Topic können die Überwachungsdashboards verwendet werden. Weitere Informationen finden Sie unter Spiegelung überwachen.
Die Anleitung zum erreichbaren Durchsatz wurde mithilfe von 100K Nachrichten generiert, die in 50 Topicpartitionen erzeugt wurden. Wenn Ihre Workload kleinere Nachrichtengrößen (z. B. unter 1K) oder weniger Partitionen verwendet, erreicht die Spiegelung möglicherweise diese Durchsatzstufe nicht.
Redundante Zieltopics löschen
Zur Vermeidung einer versehentlichen Löschung von Daten in der Zielinstanz werden Topics nicht automatisch aus der Zielinstanz gelöscht, wenn sie aus der Quelle gelöscht werden. Der Benutzer ist dafür verantwortlich, die Topics auf der Zielinstanz zu löschen. Wenn gespiegelte Topics häufig gelöscht und erstellt werden, kann mehr Platten-und Partitionskapazität im Zielcluster verbraucht werden. Die Nutzung kann mit dem Überwachungsdashboard im Zielcluster überwacht werden (siehe Event Streams-Metriken überwachen). Sie können Themen, die nicht länger benötigt werden, mithilfe der Befehlszeilenschnittstelle, der Benutzerschnittstelle oder der Verwaltungsschnittstellen löschen.
IAM-Zugriffsrichtlinien für die Spiegelung
Da Anwendungen Zugriff auf die Quell- und Zielcluster benötigen, müssen auf beiden Clustern IAM-Zugriffsrichtlinien eingerichtet werden, die den API-Schlüssel der Service-ID verwenden, an die die Richtlinien angehängt sind. Zur Vereinfachung der Zugriffsrichtlinien, die den Zugriff auf die gespiegelten Ressourcen steuern, können die Platzhalterfunktionen verwendet werden (siehe Zugriff durch Verwendung von Platzhalterrichtlinien zuordnen).
Wenn Sie mit den IAM-Zugriffsrichtlinien noch nicht vertraut sind, finden Sie weitere Details unter Funktionsweise von IBM Cloud IAM und Authentifizierung für Ihre Event Streams-Instanzen verwalten.
Definieren Sie die folgenden IAM-Zugriffsrichtlinien auf beiden Clustern, wobei
A.checkpoints.internal
.
Ressourcentyp | Ressourcen-ID | Rolle |
---|---|---|
cluster | Leseberechtigter | |
Gruppe | < RESSOURCENNAME> .* | Wie für die Anwendung erforderlich |
Thema | < RESSOURCENNAME> .* | Wie für die Anwendung erforderlich |
txnid | < RESSOURCENNAME> .* | Wie für die Anwendung erforderlich |
Thema (spezifisch für das Prüfpunktthema) |
|
Leseberechtigter |
Differenzierte Zugriffsrichtlinien für einzelne Anwendungen erteilen. Erteilen Sie beispielsweise für Anwendungen, die einfach konsumieren, nur Leserzugriff.
Für die Spiegelung von Benutzerkontrollen müssen Sie über die folgenden Berechtigungen auf dem Zielcluster verfügen.
Ressourcentyp | Ressourcen-ID | Rolle |
---|---|---|
cluster | Manager |
Überlegungen, wenn Sie Cluster zwischen mehreren Entitäten teilen
Wenn mehrere Entitäten, wie z. B. verschiedene Geschäftseinheiten, eine Instanz gemeinsam nutzen und voneinander isoliert werden müssen, sollten Sie die Benennungsrichtlinien befolgen, um die Verwaltung und den Betrieb gespiegelter Cluster zu vereinfachen.
Benennen Sie Kafka-Ressourcen mithilfe der folgenden Vorlage: < ENTITY_PREFIX> < SEPARATOR> < NAME>
Dabei gilt:
- < ENTITY_PREFIX > ist das Präfix für die Entität, die dieses Thema verwendet.
-
ist ein optionales Zeichen, das zur einfachen Trennung der Entitäten und Ressourcennamen verwendet wird. -
ist der Name der Ressource Kafka.
Wenn der Geschäftsbereich Buchhaltung beispielsweise ein Thema benötigt, das Rechnungen heißt, können Sie es accounting.invoices
nennen.
Die erforderlichen Zugriffsrichtlinien müssen angepasst werden. Für die Buchhaltungsgeschäftseinheit 'accounting' sind zum Beispiel die folgenden Richtlinien auf Cluster B erforderlich:
Ressourcentyp | Ressourcen-ID | Rolle |
---|---|---|
cluster | Leseberechtigter | |
Gruppe | accounting.* | Wie für die Anwendung erforderlich |
Thema | accounting.* | Wie für die Anwendung erforderlich |
txnid | accounting.* | Wie für die Anwendung erforderlich |
topic (Hinweis: Ist für das Prüfpunkttopic spezifisch.) | A.checkpoints.internal | Leseberechtigter |
Cluster A muss über dieselben Zugriffsrichtlinien verfügen, mit Ausnahme der letzten, die auf B.checkpoints.internal
lauten muss.
Benutzersteuerelemente für Spiegelung
Sie können die Spiegelung über die Befehlszeilenschnittstelle oder die Verwaltungs-REST-API konfigurieren. Alle Benutzersteuereinstellungen für die Spiegelung werden auf dem Zielcluster durchgeführt.
Topicauswahl festlegen
Die Auswahl der Spiegelung erfolgt auf der Grundlage der Themennamen im Quellcluster unter Verwendung von Mustern für reguläre Ausdrücke (regex). Wählen Sie die Namen der Themen in Ihrem Quellencluster sorgfältig aus. Beachten Sie hierzu die Hinweise im Abschnitt Hinweise zur gemeinsamen Nutzung von Clustern durch mehrere Entitäten.
Bei klar strukturierten Themennamen, z. B. dem Hinzufügen eines Präfix zu Themen, die zu derselben Gruppe oder Anwendung gehören, kann die Spiegelung einfach gesteuert werden. Mit einer solchen Namenskonvention werden alle zukünftigen Themen, die dem Muster entsprechen, automatisch gespiegelt, ohne dass weitere Änderungen erforderlich sind.
Die Themenauswahl wird in Form einer Liste mit einem oder mehreren Regex-Mustern angegeben. Ein Thema wird ausgewählt, wenn es einem der Muster in der Liste entspricht.
Einige Beispiele für Muster zur Auswahl von Topics für die Spiegelung:
Beispielmuster | Erläuterung |
---|---|
^topic1$ |
Vollständige Topicnamen. Dies entspricht nur dem einzelnen Thema mit dem Namen topic1 . |
^topic1$,^topic2$ |
Liste der Muster, die mit vollständigen Themennamen übereinstimmen. Dies entspricht den beiden Themen mit den Namen topic1 und topic2 . |
^aaa.* |
Übereinstimmung mit dem Präfix. Dies entspricht jedem Themennamen, der mit aaa beginnt. |
^aaa.*,^bbb.* |
Liste der Muster, die mit dem Präfix übereinstimmen. Dies entspricht jedem Themennamen, der mit aaa oder bbb beginnt. |
^branch_[0-9]{3}_[a-z]*$ |
Etwas komplexeres Regex-Muster zum Abgleich von Topicnamen. Dies entspricht jedem Themennamen, der mit branch_ beginnt, gefolgt von genau drei Ziffern, gefolgt von _ und einer beliebigen Anzahl von Kleinbuchstaben. |
.* |
Spiegelung aller Quellentopics. |
Bei Verwendung der Befehlszeilenschnittstelle werden die Muster in Form einer durch Kommas getrennten Liste angegeben. Der folgende Befehl wählt beispielsweise alle Themen aus, deren Name das Präfix accounting
oder hr
hat.
ibmcloud es mirroring-topic-selection-set --select '^accounting.*,^hr.*'
Der folgende Befehl zeigt, wie dieselbe Auswahl über die REST-Verwaltungs-API getroffen wird. Die Muster haben die Form eines JSON-Arrays mit dem Namen "includes"
.
curl -s -X POST -H "Content-Type: application/json" -H "Authorization: <bearer token>" <admin url>/admin/mirroring/topic-selection -d '{"includes":["^accounting.*", "^hr.*"]}'
Durch die Aktualisierung einer Themenauswahl wird der aktuelle Satz von Mustern ersetzt.
Um die Auswahl zu entfernen, sodass keine Themen gespiegelt werden, verwenden Sie die Option --none
mit der Befehlszeilenschnittstelle oder ein leeres Muster mit der REST-Verwaltungs-API wie folgt:
ibmcloud es mirroring-topic-selection-set --none
curl -s -X POST -H "Content-Type: application/json" -H "Authorization: <bearer token>" <admin url>/admin/mirroring/topic-selection -d '{"includes":[""]}'
Um die Spiegelung selektiv zu deaktivieren, wenden Sie die Themenauswahl erneut an und lassen Sie die Muster weg, die Sie deaktivieren möchten. Wenn beispielsweise topic1, topic2 und topic3 derzeit gespiegelt werden, deaktivieren die folgenden Befehle die Spiegelung für topic2, lassen die beiden anderen jedoch aktiviert.
ibmcloud es mirroring-topic-selection-set --select '^topic1$,^topic3$'
curl -s -X POST -H "Content-Type: application/json" -H "Authorization: <bearer token>" <admin url>/admin/mirroring/topic-selection -d '{"includes":["^topic1$","^topic3$"]}'
Topicauswahl abrufen
Sie können die Spiegelungsauswahl über die folgenden Schnittstellen abrufen:
Befehlszeilenschnittstelle:
ibmcloud es mirroring-topic-selection
REST-API:
curl -s -X GET -H "Authorization: <bearer token>" <admin url>/admin/mirroring/topic-selection
Aktive Topics abrufen
Sie können die Themen, die aktiv gespiegelt werden, über die folgenden Schnittstellen abrufen:
Befehlszeilenschnittstelle:
ibmcloud es mirroring-active-topics
REST-API:
curl -s -X GET -H "Authorization: <bearer token>" <admin url>/admin/mirroring/active-topics
Für Spiegelung geeignete Anwendungen erstellen
Erzeuger
Wir empfehlen, dass Produzenten nur zu lokalen Themen produzieren. Wenn Sie einen Producer zwischen Instanzen wechseln, ist normalerweise eine Konfigurationsänderung erforderlich, sodass der Producer die richtigen Endpunkte und Berechtigungsnachweise für die Verbindung verwendet.
Konsumenten
Consumer sollten sowohl lokale als auch ferne Topics abonnieren und verarbeiten. Dies kann durch ein einzelnes Abonnement unter Verwendung von Platzhalterzeichen umgesetzt werden. Wenn Sie beispielsweise sowohl von accounting.invoice
als auch von accounting.invoice.<ALIAS>
konsumieren möchten, verwenden Sie dieSubskription für accounting.invoice.*
.
Wenn Sie lokale und ferne Topics konsumieren, prüfen Sie, ob die Anwendung eine strikte Reihenfolge erfordert. In einem solchen Fall müssen zunächst die Remote-Themen vollständig aufgebraucht werden, bevor Sie mit dem Aufbrauchen der lokalen Themen beginnen. Auf diese Weise werden Nachrichten in der Reihenfolge verarbeitet, in der sie generiert wurden.
Consumer-Offsets
Wenn Nachrichtendaten zwischen zwei Instanzen gespiegelt werden, gibt es eine Reihe von Gründen, warum die der Nachricht in der Quelleninstanz zugeordneten Offsets nicht mit dem in der Zielinstanz verwendeten Offset übereinstimmen. Beispiel:
- Löschen und erneutes Erstellen eines Themas mit demselben Namen in der Quelleninstanz.
- Themen mit einer kompakten Bereinigungsrichtlinie spiegeln.
- Nachrichten mit Transaktionen erzeugen.
Ein Teil des Nachrichtenspiegelungsprozesses verfolgt, welche Offsets in der Quelleninstanz denen in der Zielinstanz entsprechen. Aus Gründen der Effizienz wird nur eine kleine Anzahl äquivalenter Offsets verfolgt, wobei Positionen nahe dem Kopf des Themas bevorzugt werden. Wenn Offsets für Konsumentengruppen in der Quelleninstanz festgeschrieben werden, werden sie in den nächsten äquivalenten Offset in der Zielinstanz umgesetzt, und ein entsprechender Offset wird für die Gruppe in der Zielinstanz festgeschrieben. Diese Umsetzung soll sicherstellen, dass ein Konsument, der zum Zielcluster wechselt, keine gespiegelten Nachrichten überspringt. Da jedoch nicht jeder äquivalente Offset vom Spiegelungsprozess überwacht wird, werden Daten, die bereits in der Quelleninstanz verarbeitet wurden, wahrscheinlich erneut verarbeitet, wenn ein Konsument zur Zielinstanz wechselt.
Beachten Sie Folgendes, wenn Sie Anwendungen schreiben, die den Fortschritt des Konsumenten durch Festschreiben von Offsets verfolgen:
- Consumer-Offsets werden nur gespiegelt, wenn die entsprechende Consumergruppe nicht aktiv in der Zielinstanz verwendet wird.
- Es wird erwartet, dass einige Nachrichtendaten erneut verarbeitet werden, wenn der Konsument in die Zielinstanz verschoben wird.
- Je weiter hinter dem Kopf des Topics ein Konsument steht, desto mehr Daten müssen möglicherweise erneut verarbeitet werden, wenn er zur Zielinstanz verschoben wird.
- Wenn Sie das wiederkonsumierte Datenvolumen minimieren und das Wechseln von Anwendungen zwischen Instanzen sorgfältig verwalten möchten, werden die folgenden Schritte empfohlen:
- Erstellung von Nachrichten an die Quelleninstanz stoppen.
- Warten Sie, bis der Konsument den Kopf des Themas aufholt.
- Einen Offset an dieser Position festschreiben.
- Wechseln Sie vom Konsumenten zur Zielinstanz.
Spiegelung überwachen
Sie können die Spiegelung über IBM Cloud Monitoring überwachen. Informationen zur Aktivierung der Überwachung finden Sie unter Event Streams-Metriken überwachen. Das Dashboard Monitoring ist auf dem Zielcluster verfügbar.
Das Dashboard Event Streams Mirroring macht die folgenden Metriken zugänglich:
- Spiegelungsdurchsatz: Die Byte pro Sekunde für den Spiegelungsdurchsatz aus der Event Streams-Quelleninstanz. Dies ist nützlich, um zu sehen, ob die Spiegelung aktiv ist, und für die Kapazitätsplanung.
- Spiegelungslatenz: Die Spiegelungslatenz pro Topic in Sekunden aus der Event Streams-Quelleninstanz. Diese Metrik ist nützlich, um zu ermitteln, wie groß die Verzögerung eines Topics auf dem Zielcluster ist.
Daten, die innerhalb des Latenzfensters erzeugt werden, sind möglicherweise noch nicht im Zielcluster vorhanden und können dennoch verloren gehen, wenn auf dem Quellcluster eine Katastrophe eintritt. Wenn die Spiegelung jedoch aktuell ist, kann ein Failover, solange sich beide Cluster in einwandfreiem Zustand befinden, ohne Datenverlust durchgeführt werden.
Informationen zu Wiederherstellungszielen für die Spiegelung
Für einen Datenschutzplan wie zum Beispiel die Spiegelung stellen der tolerierte Datenverlust aufgrund von Ausfällen (RPO - Recovery Point Objective) und die maximale Wiederherstellungszeit nach einem Ausfall (RTO - Recovery Time Objective) die Schlüsselparameter dar. Sie müssen die Entscheidungen verstehen, die mit diesen Zielen verbunden sind.
Sie können das Ziel des Wiederherstellungspunkts mithilfe der Metrik für die Spiegelungslatenz überwachen, die im Spiegelungs-Dashboard bereitgestellt wird. Diese Metrik zeigt die Verzögerung zwischen beiden Clustern an, sodass Sie das Datenverlustvolumen schätzen können, wenn ein Katastrophenfall auftritt. Sie sind dafür verantwortlich, diesen Wert zu überwachen und sicherzustellen, dass er in Ihr RPO passt.
Das RTO-Ziel wird vollständig durch Benutzer gesteuert und besteht aus den folgenden Zeitfenstern:
- Die Zeit, die der Benutzer benötigt, um sich für einen Failover zu entscheiden.
- Die Zeit, die der Benutzer benötigt, um seine Anwendungen zu wechseln.
Testen
Testen Sie die Funktionsübernahme (Failover) und die Funktionsübernahme (Failover), wenn Sie die Spiegelung Ihrer Anwendungen aktiviert haben. Führen Sie die Schritte aus, die im Beispielszenario für die Disaster-Recovery beschrieben sind, und verwenden Sie die Monitoring-Dashboards, um sicherzustellen, dass alle Schritte wie erwartet ausgeführt werden.
Löschen und erneutes Erstellen von Themen mit demselben Namen auf dem Quellcluster
Wenn Topics auf dem Quellencluster gelöscht werden, wird das entsprechende Topic auf dem Zielcluster nicht automatisch gelöscht. Wenn Sie das Thema anschließend im Quellencluster neu erstellen, werden die Daten des neuen Themas im Quellencluster an das Ende des vorhandenen Themas im Zielcluster angehängt.
Hinweise zu Kafka Streams und Kafka Connect
Kafka Streams und Kafka Connect greifen auf interne Topics mit bestimmten Namen zurück, um Status- und Konfigurationsdaten zu speichern. Wenn diese Themen gespiegelt werden, werden sie im Zielcluster umbenannt. Kafka Aus diesem Grund können die Anwendungen "Streams" und "Connect" von Kafka kein Failover und Failback zwischen Clustern durchführen. Berücksichtigen Sie dies, wenn Sie eine Disaster-Recovery für solche Anwendungen planen.