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 Amazon-Konfigurationen
Sie können Amazon verwendenMSK, um eine benutzerdefinierte MSK Konfiguration zu erstellen, in der Sie die folgenden Eigenschaften festlegen. Eigenschaften, die Sie nicht explizit festlegen, erhalten die in MSKAmazon-Standardkonfiguration festgelegten Werte. Weitere Informationen zu Konfigurationseigenschaften finden Sie unter Apache Kafka Configuration
Name | Beschreibung |
---|---|
allow.everyone.if.no.acl.found | Wenn Sie diese Eigenschaft auf setzen möchten, stellen Sie zunächst sicherfalse , dass Sie Apache Kafka ACLs für Ihren Cluster definieren. Wenn Sie diese Eigenschaft auf setzen false und Sie nicht zuerst Apache Kafka definierenACLs, 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 Unterschied im Zeitstempel diesen Schwellenwert überschreitet. Diese Konfiguration wird LogAppendTime ignoriert, wenn log.message.timestamp.type=. |
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 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 |
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 keine Abrufanforderungen gesendet oder mindestens diese Anzahl von Millisekunden nicht bis zum Log-End-Offset des Leaders aufgebraucht 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 RCVBUF SO_-Puffer der Socket-Server-Sockets. Der Mindestwert, den Sie für diese Eigenschaft festlegen können, ist -1. Wenn der Wert -1 ist, MSK verwendet Amazon den Betriebssystemstandard. |
socket.request.max.bytes | Die maximale Anzahl von Bytes in einer Socket-Anfrage. |
socket.send.buffer.bytes | Der SNDBUF SO_-Puffer der Socket-Server-Sockets. Der Mindestwert, den Sie für diese Eigenschaft festlegen können, ist -1. Wenn der Wert -1 ist, MSK verwendet Amazon den Betriebssystemstandard. |
transaction.max.timeout.ms | Maximales Timeout für Transaktionen. Wenn die angeforderte Transaktionszeit eines Kunden diesen Wert überschreitet, gibt der Broker einen Fehler in zurück InitProducerIdRequest. 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 Producer-ID, da sie dazu führt, dass die Producer-ID IDs abläuft, wenn diese Zeit nach dem letzten Schreibvorgang mit der angegebenen Producer-ID verstrichen ist. Producer läuft aufgrund der Aufbewahrungseinstellungen für das Thema IDs möglicherweise früher ab, wenn der letzte Schreibvorgang aus der Producer-ID gelöscht wird. Der Mindestwert für diese Eigenschaft ist 1 Millisekunde. |
unclean.leader.election.enable | Gibt an, ob Replikate, die nicht in der ISR Gruppe enthalten sind, als letztes Mittel als führendes Mittel 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 |
Informationen dazu, wie Sie eine benutzerdefinierte MSK Konfiguration erstellen, alle Konfigurationen auflisten oder sie beschreiben können, finden Sie unterMSKAmazon-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 unterAmazonMSK: So funktioniert's.
Wenn Sie Ihren vorhandenen MSK Cluster mit einer benutzerdefinierten MSK Konfiguration aktualisieren, MSK führt Amazon bei Bedarf fortlaufende Neustarts durch und verwendet bewährte Methoden, um Ausfallzeiten für Kunden zu minimieren. Nachdem Amazon beispielsweise jeden Broker MSK neu gestartet hat, MSK versucht Amazon, den Broker Daten catch zu lassen, die der Broker während des Konfigurationsupdates möglicherweise übersehen hat, bevor er zum nächsten Broker übergeht.
Dynamische MSK Amazon-Konfiguration
Zusätzlich zu den von Amazon MSK bereitgestellten Konfigurationseigenschaften können Sie dynamisch Konfigurationseigenschaften auf Cluster- und Brokerebene festlegen, für die kein Broker-Neustart erforderlich ist. Sie können einige Konfigurationseigenschaften dynamisch festlegen. Dies sind die Eigenschaften, die in der Tabelle unter Broker-Konfigurationen
Anmerkung
Sie können die Eigenschaft advertised.listeners
festlegen, die Eigenschaft listeners
hingegen nicht.
Amazon-Konfiguration auf Themenebene MSK
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
MSKAmazon-Konfigurationsstatus
Eine MSK Amazon-Konfiguration kann sich in einem der folgenden Zustände befinden. Um einen Vorgang an einer Konfiguration durchzuführen, muss sich die Konfiguration im Status ACTIVE
oder DELETE_FAILED
befinden:
-
ACTIVE
-
DELETING
-
DELETE_FAILED