Solve the problem of inability to sense between sentries in the Redis sentry cluster
Swarm sentinel cannot sense the impact
When the Master node in the Redis service cluster is down, Redis will automatically fail to switch between master and slave.
Reis cluster content
One Master, two Slaves, and three Sentinels.
The master-slave switch configuration information related to sentinel is also correct.
Root of the problem
The source of the problem is likely to be: Is the myid used to identify the uniqueness of the sentinel in your sentinel configuration file duplicated?
Recall the steps to configure the sentry yourself:
- Configure 26379 sentry;
- Started the 26379 sentry service;
- Start to configure 26380 sentinel, when configuring the file directly: cp sentinel-26379.conf sentinel-26380.conf
- Start to configure 26381 sentinel, when configuring the file directly: cp sentinel-26379.conf sentinel-26381.conf
won’t write about the following steps. The problem has been found in the above three steps. The third step is to directly copy the configuration file of Sentinel 26379. If the 26379 sentinel has not started the service, there is no problem with your copy, because 26379 has not yet generated myid; and you let 26379 start first, and then configure the 26380 sentinel. At this time, you copy the myid of 26379 together. , And you haven't deleted myid at the end, which causes the myid of the three sentries to be the same.
Sentinel master-slave switch
So how is the sentry node automatically discovered directly, or where can the automatic discovery between sentry nodes be reflected?
Since it will be automatically recognized, it is suspected that after the sentinel node is started, it will automatically record this information in the configuration file. I tried it, and it didn't happen.
The following is on the basis of Redis master-slave replication, after the three sentinel nodes are enabled in turn, the changes in sentinel.cnf
can be found. When the three sentinel nodes are enabled, the sentinel.cnf configuration file will be automatically rewritten, mainly There are several points:
- Added a sentinel myid (identifying the uniqueness of sentinel nodes)
- Automatically append the information of the sentinel node itself (so that the sentinel nodes will automatically discover each other), and the information of the slave of the redis data service
- Automatically remove the password of the master node
- The relative path of dir is modified to an absolute path
It can be seen that the sentinel of Redis is not only Redis automatic failure escape, but also realizes the high availability of the sentinel node. At the same time, information such as passwords is also automatically removed after the sentinel node is initialized.
The sentinel's myid is automatically generated by redis when the sentinel starts the service, and the generated location is at the end of the configuration file: