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.