Benutzerdefinierte MSK-Konfigurationen - Amazon Managed Streaming für Apache Kafka

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.

Benutzerdefinierte MSK-Konfigurationen

Mit Amazon MSK können Sie eine benutzerdefinierte MSK-Konfiguration erstellen, in der Sie die folgenden Eigenschaften festlegen. Eigenschaften, die Sie nicht explizit festlegen, erhalten die in Die Standardkonfiguration von Amazon MSK festgelegten Werte. Weitere Informationen zu Konfigurationseigenschaften finden Sie unter Apache Kafka Configuration.

Apache-Kafka-Konfigurationseigenschaften
Name Beschreibung
allow.everyone.if.no.acl.found Wenn Sie diese Eigenschaft auf false setzen möchten, stellen Sie zunächst sicher, dass Sie Apache-Kafka-ACLs für Ihren Cluster definieren. Wenn Sie diese Eigenschaft auf false setzen und Sie nicht zuerst Apache-Kafka-ACLs definieren, verlieren Sie den Zugriff auf den Cluster. In diesem Fall können Sie die Konfiguration erneut aktualisieren und diese Eigenschaft auf true setzen, um wieder Zugriff auf den Cluster zu erhalten.
auto.create.topics.enable Aktiviert die automatische Erstellung von Themen auf dem Server.
compression.type Der endgültige Komprimierungstyp für ein bestimmtes Thema. Sie können diese Eigenschaft auf die Standard-Komprimierungscodecs (gzip, snappy, lz4 und zstd) festlegen. Akzeptiert zusätzlich uncompressed. Dieser Wert entspricht keiner Komprimierung. Wenn Sie den Wert auf producer setzen, bedeutet dies, dass der ursprüngliche Komprimierungs-Codec beibehalten wird, den der Produzent festlegt.

connections.max.idle.ms

Timeout bei inaktiven Verbindungen in Millisekunden. Die Threads des Server-Socket-Prozessors schließen die Verbindungen, die länger als den von Ihnen für diese Eigenschaft festgelegten Wert inaktiv sind.
default.replication.factor Der Standardreplikationsfaktor für automatisch erstellte Themen.
delete.topic.enable Aktiviert den Vorgang zum Löschen von Themen. Wenn Sie diese Einstellung deaktivieren, können Sie ein Thema nicht über das Admin-Tool löschen.
group.initial.rebalance.delay.ms Die Zeit, die der Gruppenkoordinator darauf wartet, dass mehr Verbraucher einer neuen Gruppe beitreten, bevor der erste Neuausgleich durchgeführt wird. Eine längere Verzögerung bedeutet potenziell wenigere Neuausgleiche, erhöht aber die Zeit bis zum Beginn der Verarbeitung.
group.max.session.timeout.ms Maximales Sitzungs-Timeout für registrierte Konsumenten. Längere Timeouts verschaffen Verbrauchern mehr Zeit für die Verarbeitung von Nachrichten zwischen Heartbeats, sie führen aber auch zu einer längeren Fehlererkennungszeit.
group.min.session.timeout.ms Minimale Sitzungs-Timeout für registrierte Konsumenten. Kürzere Timeouts führen zu einer schnelleren Fehlererkennung und häufigeren Verbraucher-Heartbeats, was Broker-Ressourcen überfordern kann. Dies kann die Broker-Ressourcen überfordern.
leader.imbalance.per.broker.percentage Das Verhältnis des zulässigen Führungsungleichgewichts pro Broker. Der Controller löst einen Führungsausgleich aus, wenn er diesen Wert pro Broker übersteigt. Dieser Wert wird in Prozent angegeben.
log.cleaner.delete.retention.ms Zeitraum, in dem Apache Kafka gelöschte Datensätze beibehalten soll. Der Mindestwert ist 0.
log.cleaner.min.cleanable.ratio

Diese Konfigurationseigenschaft kann Werte zwischen 0 und 1 haben. Dieser Wert bestimmt, wie oft der Protokollkomprimierer versucht, das Protokoll zu bereinigen (wenn die Protokollkomprimierung aktiviert ist). Standardmäßig vermeidet Apache Kafka die Bereinigung eines Protokolls, wenn mehr als 50 % des Protokolls komprimiert wurden. Dieses Verhältnis begrenzt den maximalen Speicherplatz, den das Protokoll mit Duplikaten verschwendet (bei 50 % bedeutet dies, dass höchstens 50 % des Protokolls Duplikate sein könnten). Bei einem größeren Verhältnis sind Bereinigungen häufiger und effizienter, aber es wird auch mehr Speicherplatz im Protokoll benötigt.

log.cleanup.policy Die Standard-Bereinigungsrichtlinie für Segmente außerhalb des Aufbewahrungsfensters. Eine durch Kommata getrennte Liste gültiger Richtlinien. Gültige Richtlinien sind delete und compact. Für Cluster mit aktivierter gestaffelter Speicherung gilt nur die Richtlinie delete.
log.flush.interval.messages Anzahl der Nachrichten, die auf einer Protokollpartition gesammelt werden, bevor Nachrichten auf den Datenträger geschrieben werden.
log.flush.interval.ms Maximale Zeit in Millisekunden, in der eine Nachricht in einem beliebigen Thema im Speicher aufbewahrt wird, bevor sie auf die Festplatte geschrieben wird. Wenn Sie diesen Wert nicht festlegen, wird der Wert in log.flush.scheduler.interval.ms verwendet. Der Mindestwert ist 0.
log.message.timestamp.difference.max.ms Der maximale Zeitunterschied zwischen dem Zeitstempel beim Empfang einer Nachricht durch den Broker und dem in der Nachricht angegebenen Zeitstempel. Bei log.message.timestamp.type= wird eine Nachricht zurückgewiesenCreateTime, wenn der Zeitstempelunterschied diesen Schwellenwert überschreitet. Diese Konfiguration wird LogAppend ignoriert, wenn log.message.timestamp.type= Zeit.
log.message.timestamp.type Gibt an, wenn der Zeitstempel in der Nachricht die Erstellungszeit der Nachricht oder die Anfügezeit des Protokolls widerspiegelt. Die zulässigen Werte sind CreateTime und LogAppendTime.
log.retention.bytes Maximale Größe des Protokolls vor dem Löschen.
log.retention.hours Anzahl der Stunden, die eine Protokolldatei vor dem Löschen aufbewahrt werden muss, tertiär zur Eigenschaft log.retention.ms.
log.retention.minutes Anzahl der Minuten, in denen eine Protokolldatei vor dem Löschen aufbewahrt wird, sekundär zur Eigenschaft log.retention.ms. Wenn Sie diesen Wert nicht festlegen, wird der Wert in log.retention.hours verwendet.
log.retention.ms Anzahl der Millisekunden, die eine Protokolldatei vor dem Löschen aufbewahrt wird (in Millisekunden). Wenn der Wert nicht festgelegt ist, wird der Wert in log.retention.minutes verwendet.
log.roll.ms Maximale Zeit, bis ein neues Protokollsegment bereitgestellt wird (in Millisekunden). Wenn Sie diesen Wert nicht festlegen, wird der Wert in log.roll.hours verwendet. Der Mindestwert für diese Eigenschaft ist 1.
log.segment.bytes Maximale Größe einer einzelnen Protokolldatei.
max.incremental.fetch.session.cache.slots Maximale Anzahl inkrementeller Abrufsitzungen, die beibehalten werden.
message.max.bytes

Die größte von Kafka unterstützte Protokoll-Batch-Größe. Wenn Sie diesen Wert erhöhen und Verbraucher älter als 0.10.2 vorhanden sind, müssen Sie auch die Abrufgröße der Verbraucher erhöhen, damit sie diese großen Datensatz-Batch abrufen können.

In der neuesten Nachrichtenformat-Version werden Datensätze aus gründen der Effizienz immer in Batches gruppiert. In früheren Nachrichtenformat-Versionen werden nicht komprimierte Datensätze nicht in Batches gruppiert und diese Beschränkung gilt in diesem Fall nur für einen einzelnen Datensatz.

Sie können dies pro Thema mit der Konfiguration auf Themenebene max.message.bytes festlegen.

min.insync.replicas

Wenn ein Produzent acks auf "all" (oder "-1") setzt, gibt min.insync.replicas die Mindestanzahl von Replikaten an, die einen Schreibvorgang bestätigen müssen, damit der Schreibvorgang als erfolgreich angesehen wird. Wenn dieses Minimum nicht erreicht werden kann, löst der Hersteller eine Ausnahme aus (entweder oder). NotEnoughReplicas NotEnoughReplicasAfterAppend

Sie können die Werte in min.insync.replicas und acks zusammen verwenden, um langfristigere Beständigkeitsgarantien durchzusetzen. Zum Beispiel könnten Sie ein Thema mit dem Replikationsfaktor 3 erstellen, min.insync.replicas auf 2 einstellen und mit acks von "all" produzieren. Dadurch wird sichergestellt, dass der Produzent eine Ausnahme auslöst, wenn die Mehrheit der Replikate keinen Schreibvorgang erhält.

num.io.threads Die Anzahl der Threads, die der Server für die Verarbeitung von Anforderungen verwendet, einschließlich Datenträger-E/A.
num.network.threads Die Anzahl der Threads, die der Server zum Empfangen von Anfragen aus dem Netzwerk und zum Senden von Antworten verwendet.
num.partitions Standardanzahl der Protokollpartitionen pro Thema.
num.recovery.threads.per.data.dir Die Anzahl der Threads pro Datenverzeichnis, die für die Protokollwiederherstellung beim Startup und zum Bereinigen beim Herunterfahren verwendet werden sollen.
num.replica.fetchers Die Anzahl der Abfrage-Threads, die zum Replizieren von Nachrichten von einem Quell-Broker verwendet werden. Wenn Sie diesen Wert erhöhen, können Sie den Grad der I/O-Parallelität im Follower-Broker erhöhen.
offsets.retention.minutes Nachdem eine Konsumentengruppe alle Konsumenten verliert (d. h. sie ist dann leer), werden die Offsets für diesen Aufbewahrungszeitraum aufbewahrt, bevor sie verworfen werden. Bei eigenständigen Verbrauchern (d. h. diejenige, die manueller Zuweisung verwenden) sind Offsets nach dem Zeitpunkt des letzten Commits zusätzlich dieser Aufbewahrungsfrist abgelaufen.
offsets.topic.replication.factor Der Replikationsfaktor für das Offsets-Thema. Setzen Sie diesen Wert höher, um die Verfügbarkeit sicherzustellen. Die interne Themenerstellung schlägt fehl, bis die Cluster-Größe diese Anforderung des Replikationsfaktors erfüllt.
replica.fetch.max.bytes Anzahl der Bytes von Nachrichten, die für jede Partition abgerufen werden sollen. Es handelt sich nicht um ein absolutes Maximum. Wenn der erste Datensatz-Batch in der ersten nicht leeren Partition des Abrufs größer ist als dieser Wert, wird der Datensatz-Batch zurückgegeben, damit Fortschritte gemacht werden können. Die Eigenschaften message.max.bytes (Broker-Konfiguration) oder max.message.bytes (Themenkonfiguration) geben die maximale vom Broker akzeptierte Datensatz-Batch-Größe an.
replica.fetch.response.max.bytes Die maximale Anzahl von Bytes, die für die gesamte Abrufantwort erwartet wird. Datensätze werden in Batches abgerufen und wenn der erste Datensatz-Batch in der ersten nicht leeren Partition des Abrufs größer ist als dieser Wert, wird der Datensatz-Batch weiterhin zurückgegeben, damit Fortschritte gemacht werden können. Es handelt sich nicht um ein absolutes Maximum. Die Eigenschaften message.max.bytes (Broker-Konfiguration) oder max.message.bytes (Themenkonfiguration) geben die maximale vom Broker akzeptierte Datensatzstapelgröße an.
replica.lag.time.max.ms Wenn ein Follower für mindestens diese Anzahl von Millisekunden keine Abrufanforderungen gesendet hat oder nicht bis zum Protokollendversatz des Leaders konsumiert hat, entfernt der Leader den Follower aus dem ISR.

MinValue: 10000

MaxValue = 30000

replica.selector.class Der vollqualifizierte Klassenname, der implementiert wird. ReplicaSelector Der Broker verwendet diesen Wert, um das bevorzugte Lesereplikat zu finden. Wenn Sie Apache Kafka Version 2.4.1 oder höher verwenden und es Verbrauchern erlauben möchten, vom nächstgelegenen Replikat abzurufen, setzen Sie diese Eigenschaft auf org.apache.kafka.common.replica.RackAwareReplicaSelector. Weitere Informationen finden Sie unter Apache Kafka Version 2.4.1 (verwenden Sie stattdessen 2.4.1.1).
replica.socket.receive.buffer.bytes Der Socket-Empfangspuffer für Netzwerkanforderungen.
socket.receive.buffer.bytes Der SO_RCVBUF-Puffer der Socket-Server-Sockets. Der Mindestwert, den Sie für diese Eigenschaft festlegen können, ist -1. Wenn der Wert -1 ist, verwendet Amazon MSK den Betriebssystemstandard.
socket.request.max.bytes Die maximale Anzahl von Bytes in einer Socket-Anfrage.
socket.send.buffer.bytes Der SO_SNDBUF-Puffer der Socket-Server-Sockets. Der Mindestwert, den Sie für diese Eigenschaft festlegen können, ist -1. Wenn der Wert -1 ist, verwendet Amazon MSK den Betriebssystemstandard.
transaction.max.timeout.ms Maximales Timeout für Transaktionen. Wenn die angeforderte Transaktionszeit eines Clients diesen Wert überschreitet, gibt der Broker einen Fehler in InitProducerIdRequest zurück. So wird ein zu großer Timeout auf Client-Seite verhindert, der Verbraucher am Lesen aus Themen, die in der Transaktion vorhanden sind, hindern könnte.
transaction.state.log.min.isr Überschriebene min.insync.replicas-Konfiguration für das Transaktionsthema.
transaction.state.log.replication.factor Der Replikationsfaktor für das Transaktionsthema. Setzen Sie diese Eigenschaft auf einen höheren Wert, um die Verfügbarkeit zu erhöhen. Die interne Themenerstellung schlägt fehl, bis die Cluster-Größe diese Anforderung des Replikationsfaktors erfüllt.
transactional.id.expiration.ms Die Zeit in Millisekunden, in der der Transaktionskoordinator auf Aktualisierungen des Transaktionsstatus für die aktuelle Transaktion wartet, bevor der Koordinator seine Transaktions-ID ablaufen lässt. Diese Einstellung beeinflusst auch den Ablauf der Produzenten-ID, da sie bewirkt, dass die Produzenten-IDs ablaufen, wenn diese Zeit nach dem letzten Schreibvorgang mit der angegebenen Produzenten-ID verstrichen ist. Produzenten-IDs laufen aufgrund der Aufbewahrungseinstellungen für das Thema möglicherweise früher ab, wenn der letzte Schreibvorgang aus der Produzenten-ID gelöscht wird. Der Mindestwert für diese Eigenschaft ist 1 Millisekunde.
unclean.leader.election.enable Gibt an, ob Replikate, die nicht im ISR-Satz enthalten sind, als letztes Mittel als Führer dienen sollen, auch wenn dies zu Datenverlust führen kann.
zookeeper.connection.timeout.ms

ZooKeeper Modus-Cluster. Maximale Zeit, bis zu der der Client wartet, um eine Verbindung herzustellen. ZooKeeper Wenn Sie diesen Wert nicht festlegen, wird der Wert in zookeeper.session.timeout.ms verwendet.

MinValue = 6000

MaxValue (einschließlich) = 18000

zookeeper.session.timeout.ms

ZooKeeper mehr Cluster. Das Zeitlimit für die ZooKeeper Apache-Sitzung in Millisekunden.

MinValue = 6000

MaxValue (einschließlich) = 18000

Weitere Informationen dazu, wie Sie eine benutzerdefinierte MSK-Konfiguration erstellen, alle Konfigurationen auflisten oder diese beschreiben können, finden Sie unter Amazon-MSK-Konfigurationsvorgänge. Informationen zum Erstellen eines MSK-Clusters mit einer benutzerdefinierten MSK-Konfiguration oder zum Aktualisieren eines Clusters mit einer neuen benutzerdefinierten Konfiguration finden Sie unter Amazon MSK: Funktionsweise.

Wenn Sie den vorhandenen MSK-Cluster mit einer benutzerdefinierten MSK-Konfiguration aktualisieren, führt Amazon MSK bei Bedarf unter Verwendung bewährter Methoden fortlaufende Neustarts durch, um Ausfallzeiten für Kunden zu minimieren. Nachdem Amazon MSK jeden Broker neu gestartet hat, warten Amazon MSK, bis der Broker Daten verarbeitet hat, die während des Konfigurations-Updates möglicherweise verpasst wurden, bevor zum nächsten Broker übergegangen wird.

Dynamische Konfiguration

Zusätzlich zu den Konfigurationseigenschaften, die Amazon MSK bereitstellt, können Sie Konfigurationseigenschaften, für die kein Broker-Neustart erforderlich ist, auf Cluster- und Broker-Ebene dynamisch festlegen. Sie können einige Konfigurationseigenschaften dynamisch festlegen. Dies sind die Eigenschaften, die in der Tabelle unter Broker-Konfigurationen in der Apache-Kafka-Dokumentation nicht als schreibgeschützt markiert sind. Informationen zur dynamischen Konfiguration und zu Beispielbefehlen finden Sie unter Aktualisieren der Broker-Konfigurationen in der Apache-Kafka-Dokumentation.

Anmerkung

Sie können die Eigenschaft advertised.listeners festlegen, die Eigenschaft listeners hingegen nicht.

Konfiguration auf Themenebene

Sie können Apache Kafka-Befehle verwenden, um Konfigurationseigenschaften auf Themenebene für neue und vorhandene Themen festzulegen oder zu ändern. Weitere Informationen zu Konfigurationseigenschaften auf Themenebene und Beispiele zum Festlegen dieser Eigenschaften finden Sie unter Konfigurationen auf Themenebene in der Apache-Kafka-Dokumentation.

Status der Konfiguration

Eine Amazon-MSK-Konfiguration kann sich in einem der folgenden Status befinden. Um einen Vorgang an einer Konfiguration durchzuführen, muss sich die Konfiguration im Status ACTIVE oder DELETE_FAILED befinden:

  • ACTIVE

  • DELETING

  • DELETE_FAILED