What is the user interaction of your feature
As an operator of a Redis replication cluster, I want to set sentinel failover timings
(at least down-after-milliseconds) declaratively — via the Cluster spec, component
parameters, or addon values — instead of relying on the hardcoded value.
Is your feature request related to a problem? Please describe.
Yes — #10753. down-after-milliseconds is hardcoded to 20000 in
redis-register-to-sentinel.sh (redis addon chart). On Kubernetes, a primary pod whose
PVC is lost can be recreated by the InstanceSet in ~10-15s — faster than the 20s window —
so sentinel never fails over (+reboot master only) and the node resumes as master with
an empty data dir, wiping replicas via full resync (total data loss with default settings).
If this is a new feature, please describe the motivation and goals.
Pod recreation on Kubernetes is much faster than the crash-recovery scenarios the 20s
default was designed for. Operators need to tune the failover race window to their
environment. Goal: expose sentinel monitor timings as first-class configuration.
Describe the solution you'd like
Expose down-after-milliseconds (and ideally failover-timeout, parallel-syncs) as:
- addon chart values, and/or
- a ParametersDefinition/ComponentParameter for the redis-sentinel component,
applied consistently in redis-register-to-sentinel.sh and redis-sentinel-member-join.sh
(both currently carry the hardcoded value).
Describe alternatives you've considered
Runtime SENTINEL SET <master> down-after-milliseconds 5000 on each sentinel — validated
as an effective mitigation for #10753 (failover completes in ~6s and the reborn empty node
joins as replica; no data loss). But it is imperative, not declarative: it lives outside
GitOps, must be reapplied per cluster, and the hardcoded 20000 is still applied on initial
registration.
Additional context
Tested on KubeBlocks 1.0.2, redis addon 1.0.4, Redis 8.4.3, replication topology
(2 replicas + 3 sentinels). Full reproduction and evidence in #10753.
What is the user interaction of your feature
As an operator of a Redis replication cluster, I want to set sentinel failover timings
(at least
down-after-milliseconds) declaratively — via the Cluster spec, componentparameters, or addon values — instead of relying on the hardcoded value.
Is your feature request related to a problem? Please describe.
Yes — #10753.
down-after-millisecondsis hardcoded to20000inredis-register-to-sentinel.sh(redis addon chart). On Kubernetes, a primary pod whosePVC is lost can be recreated by the InstanceSet in ~10-15s — faster than the 20s window —
so sentinel never fails over (
+reboot masteronly) and the node resumes as master withan empty data dir, wiping replicas via full resync (total data loss with default settings).
If this is a new feature, please describe the motivation and goals.
Pod recreation on Kubernetes is much faster than the crash-recovery scenarios the 20s
default was designed for. Operators need to tune the failover race window to their
environment. Goal: expose sentinel monitor timings as first-class configuration.
Describe the solution you'd like
Expose
down-after-milliseconds(and ideallyfailover-timeout,parallel-syncs) as:applied consistently in
redis-register-to-sentinel.shandredis-sentinel-member-join.sh(both currently carry the hardcoded value).
Describe alternatives you've considered
Runtime
SENTINEL SET <master> down-after-milliseconds 5000on each sentinel — validatedas an effective mitigation for #10753 (failover completes in ~6s and the reborn empty node
joins as replica; no data loss). But it is imperative, not declarative: it lives outside
GitOps, must be reapplied per cluster, and the hardcoded 20000 is still applied on initial
registration.
Additional context
Tested on KubeBlocks 1.0.2, redis addon 1.0.4, Redis 8.4.3, replication topology
(2 replicas + 3 sentinels). Full reproduction and evidence in #10753.