# Change Kafka Configurations Without Restart for Confluent Platform Some of the Apache Kafka® broker and topic configuration property values can be updated without restarting the Kafka broker. You can also update KRaft controller settings while brokers are offline. This topic discusses and provides examples for how to update these configuration options dynamically. ## Dynamically change broker settings Some of the broker configuration settings can be updated without restarting the broker. See the `Update Mode` option in [Broker Configurations](../installation/configuration/broker-configs.md#cp-config-brokers) for the update mode of each broker configuration. * `read-only`: Requires a broker restart for update. * `per-broker`: May be updated dynamically for each broker. * `cluster-wide`: May be updated dynamically as a cluster-wide default. May also be updated as a per-broker value for testing. To alter the current broker settings for broker ID 0 (for example, the number of log cleaner threads): ```bash bin/kafka-configs --bootstrap-server localhost:9092 --entity-type brokers --entity-name 0 --alter --add-config log.cleaner.threads=2 ``` To alter several configuration settings at the same time, or to alter configurations with complex values (for example, the [Router config for Audit Logs](../security/compliance/audit-logs/audit-logs-properties-config.md#custom-audit-log-config)), create a file with the new values in the `.properties` format and use `--add-config-file` parameter. For example, if you have the new settings in a file named `new.properties`, the command might look like the following: ```bash bin/kafka-configs --bootstrap-server localhost:9092 --entity-type brokers --entity-default --alter --add-config-file new.properties ``` When you need to update a broker configuration that accepts a list of values (e.g., a list of protocols or enabled features), you must enclose the comma-separated list in square brackets (`[]`). Omitting the brackets will cause the command to fail. For example, to dynamically update the enabled SSL protocols for a specific broker, use the following format: ```bash kafka-configs --bootstrap-server : --entity-type brokers --entity-name 1 --alter --add-config 'ssl.enabled.protocols=[TLSv1.2,TLSv1.3]' ``` The command to to describe the current dynamic broker settings for broker ID 0 is: ```bash bin/kafka-configs --bootstrap-server localhost:9092 --entity-type brokers --entity-name 0 --describe ``` To delete a configuration override and revert to the statically configured or default value for broker ID 0 (for example, the number of log cleaner threads), use the following command: ```bash bin/kafka-configs --bootstrap-server localhost:9092 --entity-type brokers --entity-name 0 --alter --delete-config log.cleaner.threads ``` Some settings can be configured as cluster-wide defaults to maintain consistent values across the whole cluster. All brokers in the cluster will process the cluster default update. For example, to update log cleaner threads on all brokers, you could use the following command: ```bash bin/kafka-configs --bootstrap-server localhost:9092 --entity-type brokers --entity-default --alter --add-config log.cleaner.threads=2 ``` To describe the currently configured dynamic cluster-wide default configurations, use the following command: ```bash bin/kafka-configs --bootstrap-server localhost:9092 --entity-type brokers --entity-default --describe ``` All settings that are configurable at cluster level may also be configured at per-broker level, for testing, for example. If a configuration value is defined at different levels, the following order of precedence is used: * Dynamic per-broker configuration * Dynamic cluster-wide default configuration * Static broker configuration from the `broker.properties` file ### Update password configurations dynamically The broker configuration `password.encoder.secret` must be configured in `broker.properties` to enable dynamic update of password settings. The secret may be different on different brokers. All dynamically updated password settings must be provided in every alter request when updating configurations using `kafka-configs`, even if the password configuration is not being altered. The following command shows how you can dynamically update the password configuration for a broker while it is running: ```bash bin/kafka-configs --bootstrap-server localhost:9092 --entity-type brokers --entity-name 0 --alter --add-config 'listener.name.internal.ssl.key.password=key-password' ``` ### Update the TLS/SSL keystore of an existing listener Brokers may be configured with TLS/SSL key stores with short validity periods to reduce the risk of compromised certificates. Key stores may be updated dynamically without restarting the broker. The configuration name must be prefixed with the listener prefix `listener.name.{listenerName}.` so that only the key store configuration of a specific listener is updated. The following configurations may be updated in a single alter request at per-broker level: * `ssl.keystore.type` * `ssl.keystore.location` * `ssl.keystore.password` * `ssl.key.password` If the listener is the inter-broker listener, then the update is allowed only if the new key store is trusted by the trust store configured for that listener. For other listeners, no trust validation is performed on the key store by the broker. Certificates must be signed by the same certificate authority that signed the old certificate to avoid any client authentication failures. ### Update the TLS/SSL trust store of an existing listener Broker trust stores may be updated dynamically without restarting the broker to add or remove certificates. Updated trust store will be used to authenticate new client connections. The configuration name must be prefixed with the listener prefix `listener.name.{listenerName}.` so that only the trust store configuration of a specific listener is updated. The following configurations may be updated in a single alter request at per-broker level: * `ssl.truststore.type` * `ssl.truststore.location` * `ssl.truststore.password` If the listener is the inter-broker listener, then the update is allowed only if the existing key store for that listener is trusted by the new trust store. For other listeners, no trust validation is performed by the broker before the update. Removal of CA certificates used to sign client certificates from the new trust store can lead to client authentication failures. To dynamically update TLS/SSL listeners so that connections use a new keystore (and expired certificates are updated on brokers without a rolling restart): ```none kafka-configs --command-config /etc/kafka/client.properties --bootstrap-server hostname:port --entity-type brokers --entity-name --alter --add-config listener.name..ssl.keystore.location= ``` ## Dynamically change controller settings Starting with Confluent Platform 7.7, you can use the `kafka-configs` tool to query and make changes to a KRaft controller by specifying the `--bootstrap-controller` option. If you specify a `bootstrap-controller`, you must not specify a `bootstrap-server` value. For example, to retrieve the cluster ID, you could use the following command: ```none bin/kafka-cluster cluster-id --bootstrap-controller localhost:9092 ``` The output resembles: ```none Cluster ID: HCRSHoTkSZ6w1rzKrEv12w ``` You can also use the `--bootstrap-controller` option with the `kafka-features` and `kafka-metadata-quorum` tools to query or make changes to a KRaft controller. For a full list of tools with usage instructions, see [Kafka CLI Tools](/kafka/operations-tools/kafka-tools.html). ## Dynamically change topic settings Some config settings in Kafka are static, meaning they only be changed in a properties file and require a broker restart. However, there are some settings that you can dynamically change on a per-topic basis using the `kafka-configs` tool. When changed using the `kafka-configs` tool, each change is persistent and remains through broker restarts. Following are some per-topic configurations that you can change: - [cleanup.policy](/platform/current/installation/configuration/topic-configs.html#cleanup-policy) - [flush.messages](/platform/current/installation/configuration/topic-configs.html#flush-messages) - [flush.ms](/platform/current/installation/configuration/topic-configs.html#flush-ms) - [max.message.bytes](/platform/current/installation/configuration/topic-configs.html#max-message-bytes) - [min.insync.replicas](/platform/current/installation/configuration/topic-configs.html#min-insync-replicas) - [retention.bytes](/platform/current/installation/configuration/topic-configs.html#retention-bytes) - [retention.ms](/platform/current/installation/configuration/topic-configs.html#retention-ms) - [segment.bytes](/platform/current/installation/configuration/topic-configs.html#segment-bytes) - [segment.jitter.ms](/platform/current/installation/configuration/topic-configs.html#segment-jitter-ms) - [segment.ms](/platform/current/installation/configuration/topic-configs.html#segment-ms) - [unclean.leader.electon.enable](/platform/current/installation/configuration/topic-configs.html#unclean-leader-election-enable) For a full list of topic-level configurations, see [Kafka Topic Configuration Reference for Confluent Platform](../installation/configuration/topic-configs.md#cp-config-topics). ## Related content - [CLI Tools Shipped With Confluent Platform](../tools/cli-reference.md#cp-all-cli) - [Kafka CLI Tools](/kafka/operations-tools/kafka-tools.html)