Broker Configuration Properties
Broker configuration properties are applied individually to each broker in a cluster.
After you change a broker-level property setting, you must restart the broker for the change to take effect. |
To learn how to set these properties from studying a sample configuration file, see the broker configuration sample.
Optional properties
admin_api_doc_dir
Path to the admin API documentation directory.
Default: /usr/share/redpanda/admin-api-doc
cloud_storage_cache_directory
The directory where the cache archive is stored. This property is mandatory when cloud_storage_enabled is set to true
.
Default: null
crash_loop_limit
A limit on the number of consecutive times a broker can crash within one hour before its crash-tracking logic is reset. This limit prevents a broker from getting stuck in an infinite cycle of crashes.
If null
, the property is disabled and no limit is applied.
The crash-tracking logic is reset (to zero consecutive crashes) by any of the following conditions:
-
The broker shuts down cleanly.
-
One hour passes since the last crash.
-
The broker configuration file,
redpanda.yaml
, is updated. -
The
startup_log
file in the broker’s data_directory is manually deleted.
Units: number of consecutive crashes of a broker
Default: 5
developer_mode
Enabling developer_mode isn’t recommended for production use.
|
Flag to enable developer mode, which skips most of the checks performed at startup.
Default: false
empty_seed_starts_cluster
Controls how a new cluster is formed. All brokers in a cluster must have the same value.
See how the empty_seed_starts_cluster
setting works with the seed_servers
setting to form a cluster.
Default: true
For backward compatibility, true is the default. Redpanda recommends using false in production environments to prevent accidental cluster formation.
|
kafka_api
IP address and port of the Kafka API endpoint that handles requests.
Default: 127.0.0.1:9092
kafka_api_tls
Transport Layer Security (TLS) configuration for the Kafka API endpoint.
Default: null
large_allocation_warning_threshold
Enables log warning messages for memory allocations greater than the given threshold size, in bytes.
If set to null
, the property is disabled, so no log messages are enabled.
If enabled, the log warnings are rate limited: the first warning will be for any allocation greater than or equal to the configured threshold, then for every subsequent warning the threshold is increased by 1.618x the current threshold.
Units: bytes per memory allocation
Default: null
node_id
A number that uniquely identifies the broker within the cluster. If null
(the default value), Redpanda automatically assigns an ID. If set, it must be non-negative value.
The node_id property must not be changed after a broker joins the cluster.
|
Default: null
Range: [0, …]
rack
A label that identifies a failure zone. Apply the same label to all brokers in the same failure zone. When enable_rack_awareness is set to true
at the cluster level, the system uses the rack labels to spread partition replicas across different failure zones.
Default: null
recovery_mode_enabled
If true
, start Redpanda in recovery mode, where user partitions are not loaded and only administrative operations are allowed.
Default: false
seed_servers
List of seed servers used to join an existing cluster.
If a cluster does not already exist:
-
When
empty_seed_starts_cluster
istrue
, Redpanda enables one broker with an emptyseed_servers
list to initiate a new cluster. The broker with an emptyseed_servers
becomes the cluster root, to which other brokers must connect to join the cluster. Brokers looking to join the cluster should have theirseed_servers
populated with the cluster root’s address, facilitating their connection to the cluster.Only one broker, the designated cluster root, should have an empty
seed_servers
list during the initial cluster bootstrapping. This ensures a single initiation point for cluster formation. -
When
empty_seed_starts_cluster
isfalse
, Redpanda requires all brokers to start with a known set of brokers listed inseed_servers
. Theseed_servers
list must not be empty and should be identical across these initial seed brokers, containing the addresses of all seed brokers. Brokers not included in theseed_servers
list use it to discover and join the cluster, allowing for expansion beyond the foundational members.The
seed_servers
list must be consistent across all seed brokers to prevent cluster fragmentation and ensure stable cluster formation.
Default: null