Skip to content

Correct k8s rebalance delay advice [CTT-820] #2090

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

Merged
JamesHazelcast merged 2 commits into from
Feb 9, 2026
Merged

Correct k8s rebalance delay advice [CTT-820] #2090

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
53a223f
Correct k8s rebalance delay advice [CTT-820]
JamesHazelcast Feb 2, 2026
27d8b62
copy edit
Rob-Hazelcast Feb 3, 2026
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
8 changes: 4 additions & 4 deletions docs/modules/storage/pages/configuring-persistence.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -195,14 +195,12 @@ partial-start automatically on the members that have either the most recent or m

You can make a cluster wait for a period of time before repartitioning after one or more members fail to rejoin. When a cluster stores lots of persisted data, it may take a long time to repartition the data after a member leaves the cluster. But, you may expect members to shut down and restart quickly, in which case the cluster doesn't need to repartition the data as soon as a member leaves. You can delay repartitioning for as long as you expect members to rejoin the cluster.

For example, you may want to delay repartitioning when you're running a cluster on Kubernetes and expect members to be restarted quickly.

NOTE: If you're planning a cluster-wide shutdown, you also can stop members from repartitioning by putting the cluster in a `FROZEN` state. See xref:maintain-cluster:cluster-member-states.adoc[].

To delay repartitioning during a single member failure, configure a _rebalance delay_, using the <<persistence-rebalance-delay-seconds, `rebalance-delay-seconds`>> option.

WARNING: If your cluster also stores in-memory data that is not persisted, do not configure a rebalance delay. Clusters do not repartition in-memory data if a member rejoins within the delay. As a result, any data that is not persisted will be lost if the member restarts within the delay, including backups.

WARNING: If you are running Hazelcast on Kubernetes, do not configure a rebalance delay. See xref:kubernetes:kubernetes-persistence.adoc[] for guidance.

Consider the following scenario:

* A cluster consists of members A, B, and C with Persistence enabled.
Expand All @@ -219,6 +217,8 @@ If member B does not restart within the rebalance delay, the cluster recovers me
repartitions the data among the remaining members (members A and C
in this case). If member B is later restarted, it recovers its persisted data from disk and brings it up-to-date with data from members A and C. If Merkle trees are enabled on available data structures, members use those to request only missing persisted data. For details about how members use Merkle trees, see <<synch-data, Synchronizing Persisted Data Faster>>.

NOTE: If you are planning a cluster-wide shutdown, you also can stop members from repartitioning by putting the cluster in a `FROZEN` state. See xref:maintain-cluster:cluster-member-states.adoc[].

[[sync-data]]
== Synchronizing Persisted Data Faster

Expand Down
Loading