Skip to content

fix: regenerate property docs with corrected property names (DOC-2351 follow-up) #1884

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
JakeSCahill wants to merge 1 commit into
base: main
Choose a base branch
from
Open

fix: regenerate property docs with corrected property names (DOC-2351 follow-up) #1884

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 1 addition & 5 deletions docs-data/property-overrides.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1407,11 +1407,7 @@
"config_scope": "cluster"
},
"leader_balancer_mute_timeout": {
"description": "The length of time that a glossterm:Raft[] group is muted after a leadership rebalance operation. Any group that has been moved, regardless of whether the move succeeded or failed, undergoes a cooling-off period. This prevents Raft groups from repeatedly experiencing leadership rebalance operations in a short time frame, which can lead to instability in the cluster.\n\nThe leader balancer maintains a list of muted groups and reevaluates muted status at the start of each balancing iteration. Muted groups still contribute to overall cluster balance calculations although they can't themselves be moved until the mute period is over.",
"config_scope": "cluster"
},
"leader_balancer_node_mute_timeout": {
"description": "The duration after which a broker that hasn't sent a heartbeat is considered muted. This timeout sets a threshold for identifying brokers that shouldn't be targeted for leadership transfers when the cluster rebalances, for example, because of unreliable network connectivity.",
"description": "The length of time that a glossterm:Raft[] group is muted after a leadership rebalance operation. Any group that has been moved, regardless of whether the move succeeded or failed, undergoes a cooling-off period. This prevents Raft groups from repeatedly experiencing leadership rebalance operations in a short time frame, which can lead to instability in the cluster.\n\nThe leader balancer maintains a list of muted groups and reevaluates muted status at the start of each balancing iteration. Muted groups still contribute to overall cluster balance calculations although they can't themselves be moved until the mute period is over.\n\nThis timeout also determines how long a broker that hasn't sent a heartbeat is considered muted. Muted brokers are not targeted for leadership transfers when the cluster rebalances, for example, because of unreliable network connectivity.",
"config_scope": "cluster"
},
"log_cleanup_policy": {
Expand Down
6 changes: 3 additions & 3 deletions modules/manage/partials/tiered-storage.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1631,7 +1631,7 @@ endif::[]

To ensure that the cache does not grow uncontrollably, which could lead to performance issues or disk space exhaustion, you can control the maximum size of the cache.

Redpanda checks the cache periodically according to the interval set in config_ref:cloud_storage_cache_check_interval_ms,true,properties/object-storage-properties[]. If the size of the stored data exceeds the configured limit, the eviction process starts. This process removes segments that haven't been accessed recently until the cache size drops to the target level.
Redpanda checks the cache periodically according to the interval set in config_ref:cloud_storage_cache_check_interval,true,properties/object-storage-properties[]. If the size of the stored data exceeds the configured limit, the eviction process starts. This process removes segments that haven't been accessed recently until the cache size drops to the target level.

*Related properties*:

Expand Down Expand Up @@ -1685,7 +1685,7 @@ endif::[]
|===
| Property | Description

| config_ref:cloud_storage_cache_check_interval_ms,true,properties/object-storage-properties[]
| config_ref:cloud_storage_cache_check_interval,true,properties/object-storage-properties[]
| The time, in milliseconds, between cache checks. The size of the cache can grow quickly, so it's important to have a small interval between checks. However, if the checks are too frequent, they consume a lot of resources. Default is 30000 ms (30 sec).

| config_ref:cloud_storage_cache_chunk_size,true,properties/object-storage-properties[]
Expand Down Expand Up @@ -1949,7 +1949,7 @@ You may want to configure the following properties:
| config_ref:cloud_storage_segment_max_upload_interval_sec,true,properties/object-storage-properties[]
| Sets the number of seconds for idle timeout. If this property is empty, Redpanda uploads metadata to the object storage, but the segment is not uploaded until it reaches the `segment.bytes` size. By default, the property is empty.

| config_ref:cloud_storage_cache_check_interval_ms,true,properties/object-storage-properties[]
| config_ref:cloud_storage_cache_check_interval,true,properties/object-storage-properties[]
| The time, in milliseconds, between cache checks. The size of the cache can grow quickly, so it's important to have a small interval between checks, but if the checks are too frequent, they consume a lot of resources. Default is 30000 ms.

| config_ref:cloud_storage_idle_timeout_ms,true,properties/object-storage-properties[]
Expand Down
Loading
Loading