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.
# Bereitgestellte Amazon MSK-Konfiguration
Amazon MSK bietet Standardkonfigurationen für Broker, Themen und Metadatenknoten. Ebenso können Sie benutzerdefinierte Konfigurationen erstellen und sie verwenden, um neue MSK-Cluster zu erstellen oder vorhandene Cluster zu aktualisieren. Eine MSK-Konfiguration besteht aus einer Reihe von Eigenschaften und den entsprechenden Werten. Je nach Brokertyp, den Sie in Ihrem Cluster verwenden, gibt es unterschiedliche Standardkonfigurationen und verschiedene Konfigurationen, die Sie ändern können. In den folgenden Abschnitten finden Sie weitere Informationen zur Konfiguration Ihrer Standard- und Express-Broker.
**Topics**
+ [Standard-Broker-Konfigurationen](msk-configuration-standard.md)
+ [Express-Broker-Konfigurationen](msk-configuration-express.md)
+ [Operationen zur Broker-Konfiguration](msk-configuration-operations.md)
# Standard-Broker-Konfigurationen
In diesem Abschnitt werden die Konfigurationseigenschaften für Standard-Broker beschrieben.
**Topics**
+ [Benutzerdefinierte Amazon MSK-Konfigurationen](msk-configuration-properties.md)
+ [Standardkonfiguration von Amazon MSK](msk-default-configuration.md)
+ [Richtlinien für die Konfiguration von Amazon MSK Tiered Storage auf Themenebene](msk-guidelines-tiered-storage-topic-level-config.md)
# Benutzerdefinierte Amazon MSK-Konfigurationen
Sie können Amazon MSK verwenden, um eine benutzerdefinierte MSK-Konfiguration zu erstellen, in der Sie die folgenden Apache Kafka-Konfigurationseigenschaften festlegen. Eigenschaften, die Sie nicht explizit festlegen, erhalten die in [Standardkonfiguration von Amazon MSK](msk-default-configuration.md) festgelegten Werte. Weitere Informationen zu Konfigurationseigenschaften finden Sie unter [Apache Kafka Configuration](https://kafka.apache.org/documentation/#configuration).
| Name | Description |
| --- | --- |
| 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 definieren ACLs, 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 | Diese Konfiguration ist in Kafka 3.6.0 veraltet. Zwei Konfigurationen, log.message.timestamp.before.max.ms undlog.message.timestamp.after.max.ms, wurden hinzugefügt. 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 `"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: 10000MaxValue = 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)](supported-kafka-versions.md#2.4.1). |
| replica.socket.receive.buffer.bytes | Der Socket-Empfangspuffer für Netzwerkanforderungen. |
| socket.receive.buffer.bytes | Der SO\$1RCVBUF-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\$1SNDBUF-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 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 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 Wir empfehlen, diesen Wert auf T3.small auf 10.000 festzulegen, um Cluster-Ausfallzeiten zu vermeiden. |
| zookeeper.session.timeout.ms | ZooKeeper Modus-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 [Operationen zur Broker-Konfiguration](msk-configuration-operations.md). Informationen zum Erstellen eines MSK-Clusters mit einer benutzerdefinierten MSK-Konfiguration oder zum Aktualisieren eines Clusters mit einer neuen benutzerdefinierten Konfiguration finden Sie unter [Die wichtigsten Funktionen und Konzepte von Amazon MSK](operations.md).
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 Amazon MSK-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](https://kafka.apache.org/documentation/#brokerconfigs) 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](https://kafka.apache.org/documentation/#dynamicbrokerconfigs) in der Apache-Kafka-Dokumentation.
**Anmerkung**
Sie können die Eigenschaft `advertised.listeners` festlegen, die Eigenschaft `listeners` hingegen nicht.
## Amazon MSK-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](https://kafka.apache.org/documentation/#topicconfigs) in der Apache-Kafka-Dokumentation.
# Standardkonfiguration von Amazon MSK
Wenn Sie einen MSK-Cluster erstellen, ohne eine benutzerdefinierte MSK-Konfiguration anzugeben, erstellt und verwendet Amazon MSK eine Standardkonfiguration mit den in der folgenden Tabelle angegebenen Werten. Bei Eigenschaften, die nicht in dieser Tabelle enthalten sind, verwendet Amazon MSK die Standardwerte, die Ihrer Version von Apache Kafka zugeordnet sind. Eine Liste dieser Standardwerte finden Sie unter [Apache Kafka Configuration](https://kafka.apache.org/documentation/#configuration).
| Name | Description | Standardwert für Cluster mit nicht-gestaffeltem Speicher | Standardwert für Cluster mit aktivierter gestaffelter Speicherung |
| --- | --- | --- | --- |
| allow.everyone.if.no.acl.found | Wenn keine Ressourcenmuster mit einer bestimmten Ressource übereinstimmen, ist der Ressource nichts zugeordnet ACLs. Wenn diese Eigenschaft auf true gesetzt ist, kann jeder auf die Ressource zugreifen, nicht nur die Superuser. | true | true |
| auto.create.topics.enable | Aktiviert die automatische Erstellung eines Themas auf dem Server. | false | false |
| auto.leader.rebalance.enable | Aktiviert den automatischen Führungsausgleich. Ein Hintergrund-Thread prüft den Führungsausgleich und löst, wenn erforderlich, diesen in regelmäßigen Abständen aus. | true | true |
| default.replication.factor | Standardreplikationsfaktoren für automatisch erstellte Themen. | 3 für Cluster in 3 Availability Zones und 2 für Cluster in 2 Availability Zones. | 3 für Cluster in 3 Availability Zones und 2 für Cluster in 2 Availability Zones. |
| local.retention.bytes | Die maximale Größe der lokalen Protokollsegmente für eine Partition, bevor die alten Segmente gelöscht werden. Wenn Sie diesen Wert nicht festlegen, wird der Wert in log.retention.bytes verwendet. Der effektive Wert sollte immer kleiner oder gleich dem Wert log.retention.bytes sein. Ein Standardwert von -2 bedeutet, dass kein Grenzwert für die lokale Aufbewahrung vorhanden ist. Dies entspricht der retention.ms/bytes-Einstellung von -1. Die Eigenschaften local.retention.ms und local.retention.bytes ähneln log.retention, da sie verwendet werden, um zu bestimmen, wie lange die Protokollsegmente im lokalen Speicher verbleiben sollen. Bestehende log.retention.\$1-Konfigurationen sind Aufbewahrungskonfigurationen für die Themenpartition. Dies umfasst sowohl lokalen als auch Remote-Speicher. Gültige Werte: Ganzzahlen in [-2; \$1Inf] | -2 für unbegrenzt | -2 für unbegrenzt |
| local.retention.ms | Die Anzahl der Millisekunden, die das lokale Protokollsegment vor dem Löschen beibehalten werden soll. Wenn Sie diesen Wert nicht festlegen, verwendet Amazon MSK den Wert in log.retention.ms. Der effektive Wert sollte immer kleiner oder gleich dem Wert log.retention.bytes sein. Ein Standardwert von -2 bedeutet, dass kein Grenzwert für die lokale Aufbewahrung vorhanden ist. Dies entspricht der retention.ms/bytes-Einstellung von -1.Die Werte local.retention.ms und local.retention.bytes ähneln log.retention. MSK verwendet diese Konfiguration, um zu bestimmen, wie lange die Protokollsegmente im lokalen Speicher verbleiben sollen. Bestehende log.retention.\$1-Konfigurationen sind Aufbewahrungskonfigurationen für die Themenpartition. Dies umfasst sowohl lokalen als auch Remote-Speicher. Gültige Werte sind Ganzzahlen größer als 0. | -2 für unbegrenzt | -2 für unbegrenzt |
| log.message.timestamp.difference.max.ms | Diese Konfiguration ist in Kafka 3.6.0 veraltet. Zwei Konfigurationen, log.message.timestamp.before.max.ms undlog.message.timestamp.after.max.ms, wurden hinzugefügt. Die maximal zulässige Diskrepanz 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=. Der maximal zulässige Zeitstempelunterschied sollte nicht größer als log.retention.ms sein, um unnötig häufiges Protokoll-Rolling zu vermeiden. | 9223372036854775807 | 86400000 für Kafka 2.8.2. Tiered und Kafka 3.7.x Tiered. |
| log.segment.bytes | Die maximale Größe einer einzelnen Protokolldatei. | 1073741824 | 134217728 |
| min.insync.replicas | Wenn ein Produzent den Wert von acks (Bestätigung, die der Produzent vom Kafka-Brocker erhält) auf `"all"` (oder `"-1"`) setzt, gibt der Wert in min.insync.replicas die Mindestanzahl von Replikaten an, die einen Schreibvorgang bestätigen müssen, damit der Schreibvorgang als erfolgreich angesehen wird. Wenn dieser Wert dieses Minimum nicht erreicht, löst der Producer eine Ausnahme aus (entweder oder). NotEnoughReplicas NotEnoughReplicasAfterAppend Wenn Sie die Werte in min.insync.replicas und acks zusammen verwenden, können Sie langfristigere Beständigkeitsgarantien durchsetzen. 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. | 2 für Cluster in 3 Availability Zones und 1 für Cluster in 2 Availability Zones. | 2 für Cluster in 3 Availability Zones und 1 für Cluster in 2 Availability Zones. |
| num.io.threads | Anzahl der Threads, die der Server für die Erzeugung von Anfragen verwendet, eventuell einschließlich Datenträger-I/O. | 8 | max (8, vCPUs) wobei v CPUs von der Instanzgröße des Brokers abhängt |
| num.network.threads | Anzahl der Threads, die der Server verwendet, um Anfragen vom Netzwerk zu empfangen und Antworten an das Netzwerk zu senden. | 5 | max (5, vCPUs /2) wobei v CPUs von der Instanzgröße des Brokers abhängt |
| num.partitions | Standardanzahl der Protokollpartitionen pro Thema. | 1 | 1 |
| num.replica.fetchers | Anzahl der Fetcher-Threads, die verwendet werden, um Nachrichten von einem Quell-Broker zu replizieren. Wenn Sie diesen Wert erhöhen, können Sie den Grad der I/O Parallelität im Follower-Broker erhöhen. | 2 | max (2, vCPUs /4), wobei v CPUs von der Instanzgröße des Brokers abhängt |
| remote.log.msk.disable.policy | Wird zusammen mit remote.storage.enable verwendet, um die gestaffelte Speicherung zu deaktivieren. Setzen Sie diese Richtlinie auf Löschen, um anzugeben, dass Daten im gestaffelten Speicher gelöscht werden, wenn Sie remote.storage.enable auf Falsch setzen. | – | Keine |
| remote.log.reader.threads | Größe des Threadpools für den Remote-Protokollleser, der bei der Planung von Aufgaben zum Abrufen von Daten aus dem Remote-Speicher verwendet wird. | – | max (10, v CPUs \$1 0.67) wobei v CPUs von der Instanzgröße des Brokers abhängt |
| remote.storage.enable | Aktiviert gestaffelte (Remote-)Speicherung für ein Thema, wenn dieser Wert auf Wahr gesetzt ist. Deaktiviert die gestaffelte Speicherung auf Themenebene, wenn der Wert auf Falsch gesetzt ist und remote.log.msk.disable.policy auf Löschen gesetzt ist. Wenn Sie die gestaffelte Speicherung deaktivieren, löschen Sie Daten aus dem Remote-Speicher. Wenn Sie die gestaffelte Speicherung für ein Thema deaktiviert haben, können Sie sie nicht erneut aktivieren. | false | false |
| 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. | 30000 | 30000 |
| retention.ms | Plichtfeld. Die Mindestzeit beträgt 3 Tage. Es gibt keine Standardeinstellung, da die Einstellung ein Pflichtfeld ist. Amazon MSK verwendet den Wert retention.ms zusammen mit local.retention.ms, um zu bestimmen, wann Daten vom lokalen zum gestaffelten Speicher verschoben werden. Der Wert local.retention.ms gibt an, wann Daten vom lokalen in den gestaffelten Speicher verschoben werden sollen. Der Wert retention.ms gibt an, wann Daten aus dem Tiered Storage (d. h. aus dem Cluster) entfernt werden sollen. Gültige Werte: Ganzzahlen in [-1; \$1Inf] | Mindestens 259 200 000 Millisekunden (3 Tage). -1 für unendliche Aufbewahrung. | Mindestens 259 200 000 Millisekunden (3 Tage). -1 für unendliche Aufbewahrung. |
| socket.receive.buffer.bytes | Der SO\$1RCVBUF-Puffer der Socket-Server-Sockets. Wenn der Wert -1 ist, wird der Standardwert des Betriebssystems verwendet. | 102400 | 102400 |
| socket.request.max.bytes | Maximale Anzahl von Bytes in einer Socket-Anforderung. | 104857600 | 104857600 |
| socket.send.buffer.bytes | Der SO\$1SNDBUF-Puffer der Socket-Server-Sockets. Wenn der Wert -1 ist, wird der Standardwert des Betriebssystems verwendet. | 102400 | 102400 |
| unclean.leader.election.enable | Gibt an, ob Replikate, die nicht in der ISR-Gruppe enthalten sind, als letztes Mittel als Führer dienen sollen, auch wenn dies zu Datenverlust führen kann. | true | false |
| zookeeper.session.timeout.ms | Das Zeitlimit für die Apache-Sitzung in Millisekunden ZooKeeper . | 18000 | 18000 |
| zookeeper.set.acl | Der eingestellte Client, der sicher verwendet werden soll. ACLs | false | false |
Hinweise zum Angeben von benutzerdefinierten Konfigurationswerten finden Sie unter[Benutzerdefinierte Amazon MSK-Konfigurationen](msk-configuration-properties.md).
# Richtlinien für die Konfiguration von Amazon MSK Tiered Storage auf Themenebene
Im Folgenden finden Sie Standardeinstellungen und Einschränkungen bei der Konfiguration der gestaffelten Speicherung auf Themenebene.
+ Amazon MSK unterstützt keine kleineren Protokollsegmentgrößen für Themen, für die gestaffelte Speicherung aktiviert ist. Wenn Sie ein Segment erstellen möchten, gibt es eine Mindestgröße für das Protokoll-Segment von 48 MiB oder eine Mindest-Segment-Rollzeit von 10 Minuten. Diese Werte sind den Eigenschaften segment.bytes und segment.ms zugeordnet.
+ Der Wert von local.retention. ms/bytes can't equal or exceed the retention.ms/bytes. Dies ist die Aufbewahrungseinstellung der gestaffelten Speicherung.
+ Der Standardwert für für local.retention. ms/bytes is -2. This means that the retention.ms value is used for local.retention.ms/bytes. In diesem Fall verbleiben die Daten sowohl im lokalen als auch im gestaffelten Speicher (jeweils eine Kopie), und sie laufen zusammen ab. Bei dieser Option wird eine Kopie der lokalen Daten dauerhaft im Remote-Speicher gespeichert. In diesem Fall stammen die aus dem Verbraucherdatenverkehr gelesenen Daten aus dem lokalen Speicher.
+ Der Standardwert für retention.ms ist 7 Tage. Es gibt keine Standard-Größenbeschränkung für retention.bytes.
+ Der Mindestwert für retention.ms/bytes ist -1. Dies bedeutet unendliche Aufbewahrung.
+ Der Mindestwert für local.retention. ms/bytes is -2. This means infinite retention for local storage. It matches with the retention.ms/bytesEinstellung auf -1.
+ Die Konfiguration retention.ms auf Themenebene ist für Themen mit aktiviertem Tiered Storage obligatorisch. Der Mindestwert für retention.ms ist 3 Tage.
Weitere Hinweise zu Einschränkungen bei der mehrstufigen Speicherung finden Sie unter. [Mehrstufige Speicherbeschränkungen und Einschränkungen für Amazon MSK-Cluster](msk-tiered-storage.md#msk-tiered-storage-constraints)
# Express-Broker-Konfigurationen
Apache Kafka verfügt über Hunderte von Broker-Konfigurationen, mit denen Sie die Leistung Ihres von MSK bereitgestellten Clusters optimieren können. Das Einstellen fehlerhafter oder suboptimaler Werte kann sich auf die Zuverlässigkeit und Leistung des Clusters auswirken. Express-Broker verbessern die Verfügbarkeit und Haltbarkeit Ihrer von MSK bereitgestellten Cluster, indem sie optimale Werte für kritische Konfigurationen festlegen und diese vor häufigen Fehlkonfigurationen schützen. Es gibt drei Kategorien von Konfigurationen, die auf Lese- und Schreibzugriff basieren: Konfigurationen mit [Lese-/Schreibzugriff (bearbeitbar)](msk-configuration-express-read-write.md), Nur-Lese-Konfigurationen und Konfigurationen ohne [Lese-/Schreibzugriff](msk-configuration-express-read-only.md). Einige Konfigurationen verwenden immer noch den Standardwert von Apache Kafka für die Apache Kafka-Version, die auf dem Cluster ausgeführt wird. Wir kennzeichnen diese als Apache Kafka Default.
**Topics**
+ [Benutzerdefinierte MSK Express-Broker-Konfigurationen (Lese-/Schreibzugriff)](msk-configuration-express-read-write.md)
+ [Express vermittelt Konfigurationen, die nur lesbar sind](msk-configuration-express-read-only.md)
# Benutzerdefinierte MSK Express-Broker-Konfigurationen (Lese-/Schreibzugriff)
Sie können read/write Broker-Konfigurationen entweder mithilfe der [Konfigurationsaktualisierungsfunktion von Amazon MSK oder mithilfe der API von Apache Kafka aktualisieren](msk-update-cluster-config.md). AlterConfig Die Apache Kafka-Broker-Konfigurationen sind entweder statisch oder dynamisch. Statische Konfigurationen erfordern einen Broker-Neustart, damit die Konfiguration angewendet werden kann, während dynamische Konfigurationen keinen Broker-Neustart erfordern. Weitere Informationen zu Konfigurationseigenschaften und Aktualisierungsmodi finden Sie unter [Broker-Konfigurationen aktualisieren](https://kafka.apache.org/documentation/#dynamicbrokerconfigs).
**Topics**
+ [Statische Konfigurationen auf MSK Express-Brokern](#msk-configuration-express-static-configuration)
+ [Dynamische Konfigurationen auf Express Brokers](#msk-configuration-express-dynamic-configuration)
+ [Konfigurationen auf Themenebene auf Express Brokers](#msk-configuration-express-topic-configuration)
## Statische Konfigurationen auf MSK Express-Brokern
Sie können Amazon MSK verwenden, um eine benutzerdefinierte MSK-Konfigurationsdatei zu erstellen, um die folgenden statischen Eigenschaften festzulegen. Amazon MSK legt alle anderen Eigenschaften fest und verwaltet sie, die Sie nicht festlegen. Sie können statische Konfigurationsdateien über die MSK-Konsole oder mithilfe des Befehls [configurations](msk-configuration-operations-create.md) erstellen und aktualisieren.
| Property (Eigenschaft) | Description (Beschreibung) | Standardwert |
| --- | --- | --- |
| 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 Apache Kafka nicht zuerst definieren ACLs, 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. | true |
| auto.create.topics.enable | Aktiviert die automatische Erstellung eines Themas auf dem Server. | false |
| compression.type | Geben Sie den endgültigen Komprimierungstyp für ein bestimmtes Thema an. Diese Konfiguration akzeptiert die Standard-Komprimierungscodecs: gzip, snappy, lz4, zstd. Diese Konfiguration akzeptiert zusätzlich`uncompressed`, was gleichbedeutend mit keiner Komprimierung ist. Das bedeutet`producer`, dass der ursprüngliche vom Hersteller festgelegte Komprimierungscodec beibehalten wird. | Apache Kafka (Standard) |
| 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. | Apache Kafka Standard |
| 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. | Apache Kafka Standard |
| 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. | Apache Kafka Standard |
| 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. | Apache Kafka Standard |
| 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. | Apache Kafka Standard |
| 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 aktiviertem Tiered Storage gilt nur eine gültige Richtlinie. delete | Apache Kafka Standard |
| log.message.timestamp.after.max.ms | Die zulässige Zeitstempeldifferenz zwischen dem Nachrichtenzeitstempel und dem Zeitstempel des Brokers. Der Nachrichtenzeitstempel kann später als oder gleich dem Zeitstempel des Brokers sein, wobei die maximal zulässige Differenz durch den in dieser Konfiguration festgelegten Wert bestimmt wird. Falls`log.message.timestamp.type=CreateTime`, wird die Nachricht zurückgewiesen, wenn der Unterschied zwischen den Zeitstempeln diesen angegebenen Schwellenwert überschreitet. Diese Konfiguration wird ignoriert, wenn`log.message.timestamp.type=LogAppendTime`. | 86400000 (24\$1 60\$1 60\$1 1000 ms, also 1 Tag) |
| log.message.timestamp.before.max.ms | Die zulässige Zeitstempeldifferenz zwischen dem Zeitstempel des Brokers und dem Nachrichtenzeitstempel. Der Nachrichtenzeitstempel kann vor dem Zeitstempel des Brokers liegen oder diesem entsprechen, wobei die maximal zulässige Differenz durch den in dieser Konfiguration festgelegten Wert bestimmt wird. Falls`log.message.timestamp.type=CreateTime`, wird die Nachricht zurückgewiesen, wenn der Unterschied in den Zeitstempeln diesen angegebenen Schwellenwert überschreitet. Diese Konfiguration wird ignoriert, wenn`log.message.timestamp.type=LogAppendTime`. | 86400000 (24\$1 60\$1 60\$1 1000 ms, also 1 Tag) |
| 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. | Apache Kafka Standard |
| log.retention.bytes | Maximale Größe des Protokolls vor dem Löschen. | Apache Kafka Standard |
| log.retention.ms | Anzahl der Millisekunden, für die eine Protokolldatei aufbewahrt werden muss, bevor sie gelöscht wird. | Apache Kafka Standard |
| max.connections.per.ip | Die maximale Anzahl von Verbindungen, die von jeder IP-Adresse aus zulässig sind. Dies kann auf eingestellt werden, 0 wenn mithilfe der max.connections.per.ip.overrides Eigenschaft Überschreibungen konfiguriert wurden. Neue Verbindungen von der IP-Adresse werden gelöscht, wenn das Limit erreicht wird. | Apache Kafka Standard |
| max.incremental.fetch.session.cache.slots | Maximale Anzahl inkrementeller Abrufsitzungen, die beibehalten werden. | Apache Kafka Standard |
| 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 diesen Wert pro Thema mit der `max.message.bytes` Konfiguration auf Themenebene festlegen. | Apache Kafka Standard |
| num.partitions | Standardanzahl von Partitionen pro Thema. | 1 |
| 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. Für eigenständige Benutzer (d. h. Benutzer, die die manuelle Zuweisung verwenden) laufen Offsets nach dem Zeitpunkt der letzten Übertragung zuzüglich dieser Aufbewahrungsfrist ab. | Apache Kafka (Standard) |
| 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. | Apache Kafka Standard |
| replica.selector.class | Der vollqualifizierte Klassenname, der implementiert wird. ReplicaSelector Der Broker verwendet diesen Wert, um das bevorzugte Lesereplikat zu finden. Wenn Sie es Verbrauchern ermöglichen möchten, Daten vom nächstgelegenen Replikat abzurufen, setzen Sie diese Eigenschaft auf. `org.apache.kafka.common.replica.RackAwareReplicaSelector` | Apache Kafka Standard |
| socket.receive.buffer.bytes | Der SO\$1RCVBUF-Puffer der Socket-Server-Sockets. Wenn der Wert -1 ist, wird der Standardwert des Betriebssystems verwendet. | 102400 |
| socket.request.max.bytes | Maximale Anzahl von Bytes in einer Socket-Anforderung. | 104857600 |
| socket.send.buffer.bytes | Der SO\$1SNDBUF-Puffer der Socket-Server-Sockets. Wenn der Wert -1 ist, wird der Standardwert des Betriebssystems verwendet. | 102400 |
| transaction.max.timeout.ms | Maximales Timeout für Transaktionen. Wenn die angeforderte Transaktionszeit eines Kunden 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. | Apache Kafka (Standard) |
| 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 IDs , dass der Producer 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. | Apache Kafka (Standard) |
## Dynamische Konfigurationen auf Express Brokers
Sie können die Apache AlterConfig Kafka-API oder das Tool Kafka-configs.sh verwenden, um die folgenden dynamischen Konfigurationen zu bearbeiten. Amazon MSK legt alle anderen Eigenschaften fest und verwaltet sie, die Sie nicht festlegen. Sie können dynamisch Konfigurationseigenschaften auf Cluster- und Broker-Ebene festlegen, für die kein Neustart des Brokers erforderlich ist.
| Property (Eigenschaft) | Description (Beschreibung) | Standardwert |
| --- | --- | --- |
| advertised.listeners | Listener, die veröffentlicht werden sollen, damit Clients sie verwenden können, sofern sie sich von der Eigenschaft config unterscheiden. `listeners` In IaaS-Umgebungen muss sich dies möglicherweise von der Schnittstelle unterscheiden, an die der Broker bindet. Wenn dies nicht festgelegt ist, wird der Wert für Listener verwendet. Im Gegensatz zu Listenern ist es nicht zulässig, die 0.0.0.0-Metaadresse bekannt zu geben. Im Gegensatz dazu kann diese Eigenschaft doppelte Ports enthalten`listeners`, sodass ein Listener so konfiguriert werden kann, dass er die Adresse eines anderen Listeners bekannt gibt. Dies kann in einigen Fällen nützlich sein, in denen externe Load Balancer verwendet werden. Diese Eigenschaft wird auf Broker-Ebene festgelegt. | Null |
| 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. | Apache Kafka (Standard) |
| log.cleaner.delete.retention.ms | Der Zeitraum, in dem gelöschte Tombstone-Markierungen für im Protokoll komprimierte Themen aufbewahrt werden sollen. Diese Einstellung gibt auch eine Grenze für die Zeit, in der ein Benutzer einen Lesevorgang abschließen muss, wenn er bei Offset 0 beginnt, um sicherzustellen, dass er einen gültigen Snapshot der letzten Phase erhält. Andernfalls könnten gelöschte Tombstones gesammelt werden, bevor der Scan abgeschlossen ist. | 86400000 (24 \$1 60 \$1 60 \$1 1000 ms, also 1 Tag), Apache Kafka-Standardeinstellung |
| log.cleaner.min.compaction.lag.ms | Die Mindestdauer, für die eine Nachricht unkomprimiert im Protokoll verbleibt. Diese Einstellung gilt nur für Protokolle, die gerade komprimiert werden. | 0, Apache Kafka-Standard |
| log.cleaner.max.compaction.lag.ms | Die maximale Zeit, für die eine Nachricht im Protokoll nicht komprimiert werden kann. Diese Einstellung gilt nur für Protokolle, die gerade komprimiert werden. Diese Konfiguration wäre auf den Bereich [7 Tage, Long.Max] begrenzt. | 9223372036854775807, Apache Kafka Standard |
| 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 aktiviertem Tiered Storage gilt nur eine gültige Richtlinie. `delete` | Apache Kafka Standard |
| log.message.timestamp.after.max.ms | Die zulässige Zeitstempeldifferenz zwischen dem Nachrichtenzeitstempel und dem Zeitstempel des Brokers. Der Nachrichtenzeitstempel kann später als oder gleich dem Zeitstempel des Brokers sein, wobei die maximal zulässige Differenz durch den in dieser Konfiguration festgelegten Wert bestimmt wird. Falls`log.message.timestamp.type=CreateTime`, wird die Nachricht zurückgewiesen, wenn der Unterschied zwischen den Zeitstempeln diesen angegebenen Schwellenwert überschreitet. Diese Konfiguration wird ignoriert, wenn`log.message.timestamp.type=LogAppendTime`. | 86400000 (24\$1 60\$1 60\$1 1000 ms, also 1 Tag) |
| log.message.timestamp.before.max.ms | Die zulässige Zeitstempeldifferenz zwischen dem Zeitstempel des Brokers und dem Nachrichtenzeitstempel. Der Nachrichtenzeitstempel kann vor dem Zeitstempel des Brokers liegen oder diesem entsprechen, wobei die maximal zulässige Differenz durch den in dieser Konfiguration festgelegten Wert bestimmt wird. Falls`log.message.timestamp.type=CreateTime`, wird die Nachricht zurückgewiesen, wenn der Unterschied in den Zeitstempeln diesen angegebenen Schwellenwert überschreitet. Diese Konfiguration wird ignoriert, wenn`log.message.timestamp.type=LogAppendTime`. | 86400000 (24\$1 60\$1 60\$1 1000 ms, also 1 Tag) |
| 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`. | Apache Kafka Standard |
| log.retention.bytes | Maximale Größe des Protokolls vor dem Löschen. | Apache Kafka Standard |
| log.retention.ms | Anzahl der Millisekunden, für die eine Protokolldatei aufbewahrt werden muss, bevor sie gelöscht wird. | Apache Kafka Standard |
| max.connection.creation.rate | Die maximale Verbindungsaufbaurate, die im Broker zu einem beliebigen Zeitpunkt zulässig ist. | Apache Kafka Standard |
| maximale Anzahl an Verbindungen | Die maximale Anzahl von Verbindungen, die im Broker zu einem beliebigen Zeitpunkt zulässig sind. Dieses Limit wird zusätzlich zu allen IP-Limits angewendet, die mit `max.connections.per.ip` konfiguriert wurden. | Apache Kafka Standard |
| max.connections.per.ip | Die maximale Anzahl von Verbindungen, die von jeder IP-Adresse aus zulässig sind. Dies kann auf eingestellt werden, `0` wenn mit der Eigenschaft max.connections.per.ip.overrides Überschreibungen konfiguriert wurden. Neue Verbindungen von der IP-Adresse werden unterbrochen, wenn das Limit erreicht wird. | Apache Kafka Standard |
| max.connections.per.ip.overrides | Eine durch Kommas getrennte Liste von IP-Adressen oder Hostnamen setzt die standardmäßige maximale Anzahl von Verbindungen außer Kraft. Ein Beispielwert ist `hostName:100,127.0.0.1:200` | Apache Kafka Standard |
| 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 diesen Wert pro Thema mit der `max.message.bytes` Konfiguration auf Themenebene festlegen. | Apache Kafka Standard |
| producer.id.expiration.ms | Die Zeit in ms, die ein Topic-Partitionsleiter abwartet, bevor der Producer abläuft. IDs Der Producer IDs läuft nicht ab, solange eine mit ihm verknüpfte Transaktion noch läuft. Beachten Sie, dass Producer IDs möglicherweise früher abläuft, wenn der letzte Schreibvorgang aus der Producer-ID aufgrund der Aufbewahrungseinstellungen des Themas gelöscht wird. Wenn Sie diesen Wert auf den gleichen Wert oder einen höheren Wert setzen, `delivery.timeout.ms` können Sie das Ablaufen bei Wiederholungsversuchen verhindern und die Duplizierung von Nachrichten verhindern. Die Standardeinstellung sollte jedoch für die meisten Anwendungsfälle angemessen sein. | Apache Kafka (Standard) |
## Konfigurationen auf Themenebene auf Express Brokers
Sie können Apache Kafka-Befehle verwenden, um Konfigurationseigenschaften auf Themenebene für neue und vorhandene Themen festzulegen oder zu ändern. Wenn Sie keine Konfiguration auf Themenebene angeben können, verwendet Amazon MSK den Broker-Standard. Wie bei Konfigurationen auf Brokerebene schützt Amazon MSK einige der Konfigurationseigenschaften auf Themenebene vor Änderungen. Beispiele hierfür sind der Replikationsfaktor und. `min.insync.replicas` `unclean.leader.election.enable` Wenn Sie versuchen, ein Thema mit einem anderen Replikationsfaktorwert als zu erstellen`3`, erstellt Amazon MSK das Thema standardmäßig mit einem Replikationsfaktor `3` von. Weitere Informationen zu Konfigurationseigenschaften auf Themenebene und Beispiele zum Festlegen dieser Eigenschaften finden Sie unter [Konfigurationen auf Themenebene](https://kafka.apache.org/documentation/#topicconfigs) in der Apache-Kafka-Dokumentation.
| Property (Eigenschaft) | Description (Beschreibung) |
| --- | --- |
| cleanup.policy | Diese Konfiguration legt die Aufbewahrungsrichtlinie fest, die für Protokollsegmente verwendet werden soll. Die Richtlinie „Löschen“ (die Standardeinstellung) verwirft alte Segmente, wenn ihre Aufbewahrungszeit oder Größenbeschränkung erreicht ist. Die Richtlinie „Compact“ ermöglicht die Protokollkomprimierung, bei der der aktuelle Wert für jeden Schlüssel beibehalten wird. Es ist auch möglich, beide Richtlinien in einer durch Kommas getrennten Liste anzugeben (z. B. „Löschen, Komprimieren“). In diesem Fall werden alte Segmente gemäß der Konfiguration für Aufbewahrungszeit und Größe verworfen, während die beibehaltenen Segmente komprimiert werden. Die Komprimierung auf Express-Brokern wird ausgelöst, wenn die Daten in einer Partition 256 MB erreicht haben. |
| compression.type | Geben Sie den endgültigen Komprimierungstyp für ein bestimmtes Thema an. Diese Konfiguration akzeptiert die Standard-Komprimierungscodecs (`gzip`,, `snappy``lz4`,`zstd`). Sie akzeptiert außerdem`uncompressed`, was einer Nichtkomprimierung entspricht, und `producer` das bedeutet, dass der vom Hersteller festgelegte ursprüngliche Komprimierungscodec beibehalten wird. |
| .retention.ms löschen | Der Zeitraum, in dem gelöschte Tombstone-Markierungen für im Protokoll komprimierte Themen aufbewahrt werden sollen. Diese Einstellung gibt auch eine Grenze für die Zeit, in der ein Benutzer einen Lesevorgang abschließen muss, wenn er bei Offset 0 beginnt, um sicherzustellen, dass er einen gültigen Snapshot der letzten Phase erhält. Andernfalls könnten gelöschte Tombstones gesammelt werden, bevor der Scan abgeschlossen ist. Der Standardwert für diese Einstellung ist 86400000 (24 \$1 60 \$1 60 \$1 1000 ms, also 1 Tag), Apache Kafka Default |
| max.message.bytes | Die größte von Kafka zulässige Batchgröße für Datensätze (nach der Komprimierung, sofern die Komprimierung aktiviert ist). Wenn dieser Wert erhöht wird und es Verbraucher gibt, die älter sind als`0.10.2`, muss auch die Abrufgröße der Verbraucher erhöht werden, damit sie so große Datensatzstapel abrufen können. In der neuesten Nachrichtenformatversion werden Datensätze aus gründen der Effizienz immer in Stapeln gruppiert. In früheren Nachrichtenformatversionen werden nicht komprimierte Datensätze nicht in Stapeln gruppiert und diese Beschränkung gilt in diesem Fall nur für einen einzelnen Datensatz. Dies kann pro Thema mit der Themenebene festgelegt werden. `max.message.bytes config` |
| message.timestamp.after.max.ms | Diese Konfiguration legt die zulässige Zeitstempeldifferenz zwischen dem Nachrichtenzeitstempel und dem Zeitstempel des Brokers fest. Der Nachrichtenzeitstempel kann später als oder gleich dem Zeitstempel des Brokers sein, wobei die maximal zulässige Differenz durch den in dieser Konfiguration festgelegten Wert bestimmt wird. Falls`message.timestamp.type=CreateTime`, wird die Nachricht zurückgewiesen, wenn der Unterschied zwischen den Zeitstempeln diesen angegebenen Schwellenwert überschreitet. Diese Konfiguration wird ignoriert, wenn`message.timestamp.type=LogAppendTime`. |
| message.timestamp.before.max.ms | Diese Konfiguration legt die zulässige Zeitstempeldifferenz zwischen dem Zeitstempel des Brokers und dem Nachrichtenzeitstempel fest. Der Nachrichtenzeitstempel kann vor dem Zeitstempel des Brokers liegen oder diesem entsprechen, wobei die maximal zulässige Differenz durch den in dieser Konfiguration festgelegten Wert bestimmt wird. Falls`message.timestamp.type=CreateTime`, wird die Nachricht zurückgewiesen, wenn der Unterschied in den Zeitstempeln diesen angegebenen Schwellenwert überschreitet. Diese Konfiguration wird ignoriert, wenn`message.timestamp.type=LogAppendTime`. |
| message.timestamp.type | Definieren Sie, ob der Zeitstempel in der Nachricht die Erstellungszeit der Nachricht oder die Zeit für das Anhängen des Protokolls ist. Der Wert sollte entweder oder sein `CreateTime` `LogAppendTime` |
| min.compaction.lag.ms | Die Mindestdauer, für die eine Nachricht unkomprimiert im Protokoll verbleibt. Diese Einstellung gilt nur für Protokolle, die gerade komprimiert werden. Der Standardwert für diese Einstellung ist 0, Apache Kafka Default |
| max.compaction.lag.ms | Die maximale Zeit, für die eine Nachricht im Protokoll nicht komprimiert werden kann. Diese Einstellung gilt nur für Protokolle, die gerade komprimiert werden. Diese Konfiguration wäre auf den Bereich [7 Tage, Long.Max] begrenzt. Der Standardwert für diese Einstellung ist 9223372036854775807, Apache Kafka Default. |
| retention.bytes | Diese Konfiguration steuert die maximale Größe, auf die eine Partition (die aus Protokollsegmenten besteht) anwachsen kann, bevor wir alte Protokollsegmente verwerfen, um Speicherplatz freizugeben, wenn wir die Aufbewahrungsrichtlinie „Löschen“ verwenden. Standardmäßig gibt es keine Größenbeschränkung, nur eine Zeitbegrenzung. Da dieses Limit auf Partitionsebene durchgesetzt wird, multiplizieren Sie es mit der Anzahl der Partitionen, um die Beibehaltung des Themas in Byte zu berechnen. Darüber hinaus `retention.bytes configuration` funktioniert es unabhängig von `segment.ms` den `segment.bytes` Konfigurationen. Darüber hinaus löst es das Rollen eines neuen Segments aus, wenn das auf Null konfiguriert `retention.bytes` ist. |
| retention.ms | Diese Konfiguration legt fest, wie lange wir ein Protokoll maximal aufbewahren, bevor wir alte Protokollsegmente verwerfen, um Speicherplatz freizugeben, wenn wir die Aufbewahrungsrichtlinie „Löschen“ verwenden. Dies stellt eine SLA dar, die festlegt, wie schnell Verbraucher ihre Daten lesen müssen. Wenn auf gesetzt`-1`, wird kein Zeitlimit angewendet. Darüber hinaus funktioniert die `retention.ms` Konfiguration unabhängig von `segment.ms` den `segment.bytes` Konfigurationen. Darüber hinaus löst sie das Rollen eines neuen Segments aus, wenn die `retention.ms` Bedingung erfüllt ist. |
# Express vermittelt Konfigurationen, die nur lesbar sind
Amazon MSK legt die Werte für diese Konfigurationen fest und schützt sie vor Änderungen, die sich auf die Verfügbarkeit Ihres Clusters auswirken könnten. Diese Werte können sich je nach der Apache Kafka-Version, die auf dem Cluster ausgeführt wird, ändern. Denken Sie also daran, die Werte Ihres spezifischen Clusters zu überprüfen.
In der folgenden Tabelle sind die schreibgeschützten Konfigurationen für Express-Broker aufgeführt.
| Property (Eigenschaft) | Description (Beschreibung) | Der Wert von Express Broker |
| --- | --- | --- |
| broker.id | Die Broker-ID für diesen Server. | 1,2,3... |
| Broker.Rack | Rack des Brokers. Dies wird aus Gründen der Fehlertoleranz bei der Zuweisung von Replikationen mit Rack-Unterstützung verwendet. Beispiele: `RACK1`, `us-east-1d` | AZ-ID oder Subnetz-ID |
| default.replication.factor | Standardreplikationsfaktoren für alle Themen. | 3 |
| fetch.max.bytes | Die maximale Anzahl von Byte, die wir für eine Abrufanforderung zurückgeben. | Apache Kafka Standard |
| group.max.size | Die maximale Anzahl von Verbrauchern, die eine einzelne Verbrauchergruppe aufnehmen kann. | Apache Kafka Standard |
| inter.broker.listener.name | Name des Listeners, der für die Kommunikation zwischen Brokern verwendet wird. | REPLICATION\$1SECURE oder REPLICATION |
| inter.broker.protocol.version | Gibt an, welche Version des Inter-Broker-Protokolls verwendet wird. | Apache Kafka (Standard) |
| Listener | Listener-Liste — Kommagetrennte Liste der Listener-Namen, auf die URIs wir hören werden. Sie können die Eigenschaft festlegenadvertised.listeners property, aber nicht die Eigenschaft. listeners | Von MSK generiert |
| log.message.format.version | Geben Sie die Version des Nachrichtenformats an, die der Broker verwenden wird, um Nachrichten an die Protokolle anzuhängen. | Apache Kafka (Standard) |
| min.insync.replicas | Wenn ein Producer acks auf `all` (oder`-1`) setzt, `min.insync.replicas` gibt der Wert in 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 Producer eine Ausnahme aus (entweder `NotEnoughReplicas` oder`NotEnoughReplicasAfterAppend`). Sie können die Value-Acks Ihres Herstellers verwenden, um höhere Haltbarkeitsgarantien durchzusetzen. Indem Sie Acks auf „Alle“ setzen. Dadurch wird sichergestellt, dass der Produzent eine Ausnahme auslöst, wenn die Mehrheit der Replikate keinen Schreibvorgang erhält. | 2 |
| num.io.threads | Anzahl der Threads, die der Server verwendet, um Anfragen zu erzeugen, die Festplatten-I/O beinhalten können. (m7g.large, 8), (m7g.xlarge, 8), (m7g.2xlarge, 16), (m7g.4xlarge, 32), (m7g.8xlarge, 64), (m7g.12xlarge, 96), (m7g.16xlarge, 128) | Basierend auf dem Instanztyp. =Math.max (8, 2 \$1 v) CPUs |
| num.network.threads | Anzahl der Threads, die der Server verwendet, um Anfragen vom Netzwerk zu empfangen und Antworten an das Netzwerk zu senden. (m7g.large, 8), (m7g.xlarge, 8), (m7g.2xlarge, 8), (m7g.4xlarge, 16), (m7g.8xlarge, 32), (m7g.12xlarge, 48), (m7g.16xlarge, 64) | Basiert auf dem Instanztyp. =Math.max (8, v) CPUs |
| 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 config) oder max.message.bytes (topic config) geben die maximale Batchgröße von Datensätzen an, die der Broker akzeptiert. | Apache Kafka (Standard) |
| request.timeout.ms | Die Konfiguration steuert, wie lange der Client maximal auf die Antwort auf eine Anfrage wartet. Wenn die Antwort nicht vor Ablauf des Timeouts eingeht, sendet der Client die Anfrage gegebenenfalls erneut oder schlägt die Anfrage fehl, wenn die Wiederholungsversuche erschöpft sind. | Apache Kafka (Standard) |
| transaction.state.log.min.isr | Die min.insync.replicas Konfiguration für das Transaktionsthema wurde außer Kraft gesetzt. | 2 |
| transaction.state.log.replication.factor | Der Replikationsfaktor für das Transaktionsthema. | Apache Kafka (Standard) |
| unclean.leader.election.enable | Ermöglicht Replikaten, die nicht in der ISR-Gruppe enthalten sind, als letztes Mittel als führendes Mittel zu dienen, auch wenn dies zu Datenverlust führen kann. | FALSE |
# Operationen zur Broker-Konfiguration
Apache Kafka-Broker-Konfigurationen sind entweder statisch oder dynamisch. Statische Konfigurationen erfordern einen Neustart des Brokers, damit die Konfiguration angewendet werden kann. Dynamische Konfigurationen erfordern keinen Broker-Neustart, damit die Konfiguration aktualisiert wird. Weitere Informationen zu Konfigurationseigenschaften und Aktualisierungsmodi finden Sie unter Apache Kafka-Konfiguration.
In diesem Thema wird beschrieben, wie benutzerdefinierte MSK-Konfigurationen erstellt und Vorgänge an diesen ausgeführt werden. Informationen zur Verwendung von MSK-Konfigurationen zum Erstellen oder Aktualisieren von Clustern finden Sie unter [Die wichtigsten Funktionen und Konzepte von Amazon MSK](operations.md).
**Topics**
+ [Erstellen einer Konfiguration](msk-configuration-operations-create.md)
+ [Konfiguration aktualisieren](msk-configuration-operations-update.md)
+ [Konfiguration löschen](msk-configuration-operations-delete.md)
+ [Rufen Sie die Konfigurationsmetadaten ab](msk-configuration-operations-describe.md)
+ [Erfahren Sie mehr über die Revision der Konfiguration](msk-configuration-operations-describe-revision.md)
+ [Listet die Konfigurationen in Ihrem Konto für die aktuelle Region auf](msk-configuration-operations-list.md)
+ [Amazon MSK-Konfigurationsstatus](msk-configuration-states.md)
# Erstellen einer Konfiguration
In diesem Prozess wird beschrieben, wie Sie eine benutzerdefinierte Amazon MSK-Konfiguration erstellen und Operationen damit durchführen.
1. Erstellen Sie eine Datei, in der Sie die festzulegenden Konfigurationseigenschaften und die Werte angeben, die Sie ihnen zuweisen möchten. Im Folgenden finden Sie den Inhalt einer Beispielkonfigurationsdatei.
```
auto.create.topics.enable = true
log.roll.ms = 604800000
```
1. Führen Sie den folgenden AWS CLI Befehl aus und *config-file-path* ersetzen Sie ihn durch den Pfad zu der Datei, in der Sie Ihre Konfiguration im vorherigen Schritt gespeichert haben.
**Anmerkung**
Der Name, den Sie für Ihre Konfiguration auswählen, muss mit dem folgenden regulären Ausdruck übereinstimmen: „^[0-9A-Za-z][0-9A-Za-z-]\$10,\$1\$1“.
```
aws kafka create-configuration --name "ExampleConfigurationName" --description "Example configuration description." --kafka-versions "1.1.1" --server-properties fileb://config-file-path
```
Im Folgenden finden Sie ein Beispiel für eine erfolgreiche Antwort nach der Ausführung dieses Befehls.
```
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-1234-abcd-1234-abcd123e8e8e-1",
"CreationTime": "2019-05-21T19:37:40.626Z",
"LatestRevision": {
"CreationTime": "2019-05-21T19:37:40.626Z",
"Description": "Example configuration description.",
"Revision": 1
},
"Name": "ExampleConfigurationName"
}
```
1. Der vorherige Befehl gibt einen Amazon-Ressourcennamen (ARN) für die neue Konfiguration zurück. Speichern Sie diesen ARN, da Sie bei anderen Befehlen auf diese Konfiguration verweisen müssen. Wenn Sie den Konfigurations-ARN verlieren, finden Sie ihn in der Konfigurationsliste in Ihrem Konto wieder.
# Konfiguration aktualisieren
Dieser Prozess beschreibt, wie eine benutzerdefinierte Amazon MSK-Konfiguration aktualisiert wird.
1. Erstellen Sie eine Datei, in der Sie die zu aktualisierenden Konfigurationseigenschaften angeben, und die Werte, die Sie ihnen zuweisen möchten. Im Folgenden finden Sie den Inhalt einer Beispielkonfigurationsdatei.
```
auto.create.topics.enable = true
min.insync.replicas = 2
```
1. Führen Sie den folgenden AWS CLI Befehl aus und *config-file-path* ersetzen Sie ihn durch den Pfad zu der Datei, in der Sie Ihre Konfiguration im vorherigen Schritt gespeichert haben.
*configuration-arn*Ersetzen Sie es durch den ARN, den Sie bei der Erstellung der Konfiguration erhalten haben. Wenn Sie den ARN beim Erstellen der Konfiguration nicht gespeichert haben, können Sie den `list-configurations`-Befehl verwenden, um alle Konfigurationen in Ihrem Konto aufzulisten. Die Konfiguration, die Sie in der Liste haben möchten, wird in der Antwort angezeigt. Der ARN der Konfiguration wird ebenfalls in dieser Liste angezeigt.
```
aws kafka update-configuration --arn configuration-arn --description "Example configuration revision description." --server-properties fileb://config-file-path
```
1. Im Folgenden finden Sie ein Beispiel für eine erfolgreiche Antwort nach der Ausführung dieses Befehls.
```
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-1234-abcd-1234-abcd123e8e8e-1",
"LatestRevision": {
"CreationTime": "2020-08-27T19:37:40.626Z",
"Description": "Example configuration revision description.",
"Revision": 2
}
}
```
# Konfiguration löschen
Das folgende Verfahren zeigt, wie Sie eine Konfiguration löschen, die nicht einem Cluster angefügt ist. Sie können eine Konfiguration nicht löschen, die einem Cluster angefügt ist.
1. Um dieses Beispiel auszuführen, *configuration-arn* ersetzen Sie es durch den ARN, den Sie bei der Erstellung der Konfiguration erhalten haben. Wenn Sie den ARN beim Erstellen der Konfiguration nicht gespeichert haben, können Sie den `list-configurations`-Befehl verwenden, um alle Konfigurationen in Ihrem Konto aufzulisten. Die Konfiguration, die Sie in der Liste haben möchten, wird in der Antwort angezeigt. Der ARN der Konfiguration wird ebenfalls in dieser Liste angezeigt.
```
aws kafka delete-configuration --arn configuration-arn
```
1. Im Folgenden finden Sie ein Beispiel für eine erfolgreiche Antwort nach der Ausführung dieses Befehls.
```
{
"arn": " arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-1234-abcd-1234-abcd123e8e8e-1",
"state": "DELETING"
}
```
# Rufen Sie die Konfigurationsmetadaten ab
Das folgende Verfahren zeigt, wie eine Amazon MSK-Konfiguration beschrieben wird, um Metadaten über die Konfiguration abzurufen.
1. Der folgende Befehl gibt Metadaten zur Konfiguration zurück. Um eine detaillierte Beschreibung der Konfiguration zu erhalten, führen Sie `describe-configuration-revision` aus .
Um dieses Beispiel auszuführen, *configuration-arn* ersetzen Sie es durch den ARN, den Sie bei der Erstellung der Konfiguration erhalten haben. Wenn Sie den ARN beim Erstellen der Konfiguration nicht gespeichert haben, können Sie den `list-configurations`-Befehl verwenden, um alle Konfigurationen in Ihrem Konto aufzulisten. Die Konfiguration, die Sie in der Liste haben möchten, wird in der Antwort angezeigt. Der ARN der Konfiguration wird ebenfalls in dieser Liste angezeigt.
```
aws kafka describe-configuration --arn configuration-arn
```
1. Im Folgenden finden Sie ein Beispiel für eine erfolgreiche Antwort nach der Ausführung dieses Befehls.
```
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-abcd-1234-abcd-abcd123e8e8e-1",
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"KafkaVersions": [
"1.1.1"
],
"LatestRevision": {
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"Revision": 1
},
"Name": "SomeTest"
}
```
# Erfahren Sie mehr über die Revision der Konfiguration
Bei diesem Vorgang erhalten Sie eine detaillierte Beschreibung der Amazon MSK-Konfigurationsrevision.
Wenn Sie den `describe-configuration`-Befehl verwenden, um eine MSK-Konfiguration zu beschreiben, erhalten Sie die Metadaten der Konfiguration. Um eine Beschreibung der Konfiguration zu erhalten, verwenden Sie den Befehl `describe-configuration-revision`.
+ Führen Sie den folgenden Befehl aus und *configuration-arn* ersetzen Sie ihn durch den ARN, den Sie bei der Erstellung der Konfiguration erhalten haben. Wenn Sie den ARN beim Erstellen der Konfiguration nicht gespeichert haben, können Sie den `list-configurations`-Befehl verwenden, um alle Konfigurationen in Ihrem Konto aufzulisten. Die Konfiguration, die Sie in der Liste suchen, wird in der Antwort angezeigt. Der ARN der Konfiguration wird ebenfalls in dieser Liste angezeigt.
```
aws kafka describe-configuration-revision --arn configuration-arn --revision 1
```
Im Folgenden finden Sie ein Beispiel für eine erfolgreiche Antwort nach der Ausführung dieses Befehls.
```
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-abcd-1234-abcd-abcd123e8e8e-1",
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"Revision": 1,
"ServerProperties": "YXV0by5jcmVhdGUudG9waWNzLmVuYWJsZSA9IHRydWUKCgp6b29rZWVwZXIuY29ubmVjdGlvbi50aW1lb3V0Lm1zID0gMTAwMAoKCmxvZy5yb2xsLm1zID0gNjA0ODAwMDAw"
}
```
Der Wert von `ServerProperties` wird mit base64 codiert. Wenn Sie einen base64-Decoder (z. B. https://www.base64decode.org/) verwenden, um den Wert manuell zu dekodieren, erhalten Sie den Inhalt der ursprünglichen Konfigurationsdatei, mit der Sie die benutzerdefinierte Konfiguration erstellt haben. In diesem Fall erhalten Sie Folgendes:
```
auto.create.topics.enable = true
log.roll.ms = 604800000
```
# Listet die Konfigurationen in Ihrem Konto für die aktuelle Region auf
Dieser Prozess beschreibt, wie Sie alle Amazon MSK-Konfigurationen in Ihrem Konto für die aktuelle AWS Region auflisten.
+ Führen Sie den folgenden Befehl aus.
```
aws kafka list-configurations
```
Im Folgenden finden Sie ein Beispiel für eine erfolgreiche Antwort nach der Ausführung dieses Befehls.
```
{
"Configurations": [
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-abcd-1234-abcd-abcd123e8e8e-1",
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"KafkaVersions": [
"1.1.1"
],
"LatestRevision": {
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"Revision": 1
},
"Name": "SomeTest"
},
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-1234-abcd-1234-abcd123e8e8e-1",
"CreationTime": "2019-05-03T23:08:29.446Z",
"Description": "Example configuration description.",
"KafkaVersions": [
"1.1.1"
],
"LatestRevision": {
"CreationTime": "2019-05-03T23:08:29.446Z",
"Description": "Example configuration description.",
"Revision": 1
},
"Name": "ExampleConfigurationName"
}
]
}
```
# Amazon MSK-Konfigurationsstatus
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`