doc-bug-579: added caution about earlier versions (#1381)

See doc bug: #579 Added note as agreed with HasanC Backporting to all versions --------- Co-authored-by: Oliver Howell <[email protected]>
hazelcast · Nov 19, 2024 · c17c1f0 · c17c1f0
1 parent 5530198
commit c17c1f0
Showing 1 changed file with 2 additions and 0 deletions.
diff --git a/docs/modules/kubernetes/pages/kubernetes-persistence.adoc b/docs/modules/kubernetes/pages/kubernetes-persistence.adoc
@@ -43,3 +43,5 @@ When running Hazelcast with persistence in Kubernetes, the following configurati
  ** Never set a non-zero value for the `rebalance-delay-seconds` property. Automatic cluster state management switches to the cluster to the appropriate state, which may or may not allow partition rebalancing to occur depending on the detected status of the cluster.
  ** Use `PARTIAL_RECOVERY_MOST_COMPLETE` as `cluster-data-recovery-policy` and set `auto-remove-stale-data` to `true`, to minimize the need for manual interventions. Even in edge cases in which a member performs force-start (that is, cleans its persistent data directory and rejoins the cluster with a new identity), data can usually be recovered from backup partitions (assuming `IMap` and `ICache` are configured with one or more backups).
  - Start Hazelcast with the `-Dhazelcast.stale.join.prevention.duration.seconds=5` Java option. Since Kubernetes can quickly reschedule pods, the default value of `30` seconds is too high and can cause unnecessary delays in members rejoining the cluster.
+
+CAUTION: In versions earlier than 5.2.0, persistence on Kubernetes may not work as expected. You can scale up or down, but cluster-wide shutdown can result in an Out of Memory Error (OOME) and you may have to restart the cluster manually.