First, Protected-mode
By default, Redis node and Sentinel Protected-mode are yes, and if you want to connect a Redis cluster remotely from a remote connection, you need to modify the Protected-mode of Redis node and Sentinel to No, If you only modify Redis node, you will still not be able to use it from the remote Connection Sentinel, and the Sentinel configuration file does not have a Protected-mode configuration item, which needs to be added manually.
According to the Redis documentation, if the Protected-mode is set to No, you need to increase the password or IP restrictions and other protection mechanisms, otherwise it is extremely dangerous.
Second, Sentinel provides the master IP
Sentinel holds all of the available node Ip,jedis pool to obtain the available master IP for Redis through Sentinel to create connection pooling connections, where Sentinel and Redis node are deployed on the same server. Sentinel Monitoring Master IP cannot be written as 127.0.0.1 and needs to be written as a real IP.
When Sentinel manages the master IP externally, it simply saves the IP in the configuration file and does not dynamically convert to the real IP of the 127.0.0.1 machine when the service is provided externally.
Third, Sentinel does not share the configuration
Each sentinel node maintains its own configuration information, which is prone to the odd system problems caused by a sentinel node configuration and other inconsistencies when building a cluster.
Jedis pool after connecting to the Sentinel list, the Redis cluster information is obtained from the first available sentinel node to build the pool, which can result in build exceptions
Iv. Cluster Status Odown
Odown is sentinel that the entire cluster is not available. There is a situation where the odown is caused by improper configuration and not the real cluster.
SENTIENL the initial state of the entire cluster (including the availability of the master node and the state of all slave nodes) based on the master IP and the end product in the configuration file. When the master configuration in Sentienl and the true master in the cluster state do not match, Sentinel considers the cluster to be unavailable. After the cluster is hung after the master, Sentinel will carry out failover processing, if failover, unfortunately all Sentinel is hung, and then reboot Sentinel will be unable to find the master, and think the cluster odown