【Redis-Sentinel cluster log information]
+reset-master: The master server has been reset.
+slave: A new slave server has beenSentinelIdentify and associate.
+failover-state-reconf-slaves: The failover state switches to the reconf-slaves state.
+failover-detected: Another Sentinel starts a failover operation, or a slave server is converted to a master server.
+slave-reconf-sent: The leader Sentinel sends the SLAVEOF command to the instance to set up a new master server for the instance.
+slave-reconf-inprog: The instance is setting itself as the slave server of the specified master, but the corresponding synchronization process has not been completed.
+slave-reconf-done: The slave server has successfully completed synchronization of the new master server.
-dup-sentinel: One or more Sentinels that monitor a given master have been removed due to repeated occurrences - this happens when the Sentinel instance is restarted.
+sentinel: A new Sentinel that monitors a given master server has been recognized and added.
+sdown: The given instance is now in subjective downline state.
-sdown: The given instance is no longer in subjective offline state.
+odown: The given instance is now in an objective offline state.
-odown: The given instance is no longer in an objective offline state.
+new-epoch: The current epoch (epoch) has been updated.
+try-failover: A new failure migration operation is being executed, waiting to be selected by most Sentinels (waitingtobeelectedbythemajority).
+elected-leader: Win the election for a designated epoch and can perform failure migration operations.
+failover-state-select-slave: Failover operation is now in select-slave state – Sentinel is looking for a slave server that can be upgraded to the master server.
no-good-slave: Sentinel operation failed to find a slave server suitable for upgrading. Sentinel will try to find a suitable slave server to upgrade again after a period of time, or directly give up failover operations.
selected-slave: Sentinel successfully finds a slave server suitable for upgrading.
failover-state-send-slaveof-noone: Sentinel is upgrading the specified slave server to the primary server, waiting for the upgrade function to complete.
failover-end-for-timeout: Failover aborted due to timeout, but in the end all slaves will start to replicate the new master (slaveswilleventuallybe configured toreplicate with the new master).
failover-end: The failover operation is completed smoothly. All slave servers have started to replicate the new master server.
+switch-master: Configuration changes, the IP and address of the master server have been changed. This is information that most external users care about.
+tilt: Enter tilt mode.
-tilt: Exit tilt mode.
+reset-master: The master server has been reset.
+slave: A new slave server has beenSentinelIdentify and associate.
+failover-state-reconf-slaves: The failover state switches to the reconf-slaves state.
+failover-detected: Another Sentinel starts a failover operation, or a slave server is converted to a master server.
+slave-reconf-sent: The leader Sentinel sends the SLAVEOF command to the instance to set up a new master server for the instance.
+slave-reconf-inprog: The instance is setting itself as the slave server of the specified master, but the corresponding synchronization process has not been completed.
+slave-reconf-done: The slave server has successfully completed synchronization of the new master server.
-dup-sentinel: One or more Sentinels that monitor a given master have been removed due to repeated occurrences - this happens when the Sentinel instance is restarted.
+sentinel: A new Sentinel that monitors a given master server has been recognized and added.
+sdown: The given instance is now in subjective downline state.
-sdown: The given instance is no longer in subjective offline state.
+odown: The given instance is now in an objective offline state.
-odown: The given instance is no longer in an objective offline state.
+new-epoch: The current epoch (epoch) has been updated.
+try-failover: A new failure migration operation is being executed, waiting to be selected by most Sentinels (waitingtobeelectedbythemajority).
+elected-leader: Win the election for a designated epoch and can perform failure migration operations.
+failover-state-select-slave: Failover operation is now in select-slave state – Sentinel is looking for a slave server that can be upgraded to the master server.
no-good-slave: Sentinel operation failed to find a slave server suitable for upgrading. Sentinel will try to find a suitable slave server to upgrade again after a period of time, or directly give up failover operations.
selected-slave: Sentinel successfully finds a slave server suitable for upgrading.
failover-state-send-slaveof-noone: Sentinel is upgrading the specified slave server to the primary server, waiting for the upgrade function to complete.
failover-end-for-timeout: Failover aborted due to timeout, but in the end all slaves will start to replicate the new master (slaveswilleventuallybe configured toreplicate with the new master).
failover-end: The failover operation is completed smoothly. All slave servers have started to replicate the new master server.
+switch-master: Configuration changes, the IP and address of the master server have been changed. This is information that most external users care about.
+tilt: Enter tilt mode.
-tilt: Exit tilt mode.