I'm trying to define a process for bootstrapping new Redis Sentinel nodes. My initial thought was to back up existing Sentinel configuration files and use them directly on new nodes.
However, I observed that the sentinel.conf
file is dynamically updated by the Sentinel process itself, particularly after a failover or even during regular operation. This includes the addition of Sentinel-specific configurations like myid and epoch related settings.
My primary goal is to bootstrap a new Sentinel node that can immediately and accurately monitor existing Redis clusters and correctly identify the current primary Redis server state.
My core question is: Is it safe and advisable to copy a sentinel.conf
file (one that has been modified by a running Sentinel over time) to a new Sentinel node?
I'm trying to understand if this method will reliably allow the new Sentinel to: - Correctly discover and monitor the existing Redis primary and replica instances. - Integrate seamlessly into the existing Sentinel quorum without causing any inconsistencies or issues.
Any guidance on the recommended approach for bootstrapping new Sentinel nodes, especially regarding configuration management, would be greatly appreciated.
Comment From: sundb
yes, you can copy this config file, but you need to remove all the dynamically generated configs, like sentinel myid
, known-sentinel
, .etc.