-
Notifications
You must be signed in to change notification settings - Fork 678
Added property to control enablement of __consumer_offsets
cache
#26522
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.
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
Added property to control enablement of __consumer_offsets
cache
#26522
Conversation
90a4884
to
283213e
Compare
"topic. By default cache for consumer offsets topic is disabled. " | ||
"Changing this property is not recommended in production systems as it " | ||
"may affect performance. The change is applied only after the restart", | ||
{.needs_restart = needs_restart::yes, .visibility = visibility::tunable}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not a blocker, just curious why this would need a restart (probably a disruptive action in certain clusters)? It seems like it can be made to pickup for new segments without a restart.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would also recommend considering making this needs_restart::no
, because to Bharath's point, cloud operators will automatically detect when a needs_restart::yes
property is flipped and trigger a rolling restart of a cluster. If the intent here is quick debugability, needs_restart::yes
will probably cause headaches.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is not so easy, the log property is set when a partition replica is created on the node. We do not change that property dynamically. I wanted to make sure the cluster view is consistent. Therefore i made it to require a restart.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
makes sense. i also didn't expect it to be nuanced like this
CI test resultstest results on build#67663
|
…sets It may sometimes be beneficial for troubleshooting to enable `__consumer_offsets` topic batch cache. The cache is disabled for this topic as it is read only once when applying batches to the stm. The batches written to the topic are usually very small. Skipping storing them in the cache relieve the cache index pressure. Signed-off-by: Michał Maślanka <[email protected]>
Added code handing a configuration property that controls the presence of the cache for the `__consumer_offsets` topic Signed-off-by: Michał Maślanka <[email protected]>
Added a test case that validates if `__consumer_offsets` cache is enabled when cluster property changes. Signed-off-by: Michał Maślanka <[email protected]>
094ddcb
283213e
to
094ddcb
Compare
/backport v25.1.x |
/backport v24.3.x |
Failed to create a backport PR to v24.3.x branch. I tried:
|
It may sometimes be required to enabled batch cache for
__consumer_offsets
topic. Added a cluster property that will allow us to change the cache settings.Backports Required
Release Notes
Improvements
__consumer_offsets
topic