Detailed explanation of Redis Sentinel, Sentinel construction process, Sentinel operation process and election principle (subjective offline, objective offline, how to elect the Sentinel leader).

Redis Sentinel (sentinel)

What is a sentinel?

The whistleblower patrols and monitors whether the background master host is faulty. If it is faulty, it will automatically convert a slave database to a new master database based on the number of votes to continue external services. [Related recommendations: Redis video tutorial]

is commonly known as unattended operation and maintenance.

What to do?

• Master-slave monitoring: Monitor whether the master-slave redis library is running normally
• Message notification: Sentinel can send the failover results to the client
• Failover: Use one of the Slave as the new Master
• Configuration center: The client obtains the master node address of the current Redis service by connecting to the sentinel

Case

Architecture

3 Sentinels: Automatically monitor and maintain the cluster. It does not store data and is just a whistleblower.

1 Master 2 Slave : used to read and store data

Steps

• Copy sentinel.conf in the redis installation path to the myredis directory

  cp sentinel.conf /myredis/sentinel26379.conf

• Modify the configuration file

  vim sentinel26379.conf
      
  bind 0.0.0.0
      
  # protected-mode yes 修改為 protected-mode no
  protected-mode no
  
  # daemonize no 修改為 daemonize yes
  daemonize yes
  
  # port 
  port 26379
  
  # pid文件名字，pidfile
  pidfile /var/run/redis_26379.pid
      
  # log文件名字，logfile（修改 logfile "" 為 logfile "/myredis/26379.log"）
  logfile "/myredis/26379.log"
  
  # 指定當(dāng)前的工作目錄（修改 dir /temp 為 dir /myredis）
  dir /myredis

  Set the master server to be monitored

  quorum: The minimum number of sentinels to confirm objective offline. Quorum of votes to approve failover.

  # sentinel monitor <master-name> <ip> <redis-port> <quorum>

  Set the password to connect to the master service

  # sentinel auth-pass <master-name> <password>

  We know that the network is unreliable. Sometimes a sentinel will mistakenly think that it is a new one due to network congestion. Master redis is dead. In a sentinel cluster environment, multiple sentinels need to communicate with each other to confirm whether a master is really dead. The quorum parameter is a basis for objective offline, which means that at least quorum sentinels think this If the master fails, the master will be offline and failed over. Because sometimes, a sentinel node may be unable to connect to the master due to its own network reasons, but the master is not faulty at this time. Therefore, multiple sentinels need to agree that there is a problem with the master before proceeding to the next step. operation, which ensures fairness and high availability.

Install three linux

ip and port are

# sentinel00
192.168.157.112    26379
# sentinel01
192.168.157.113    26380
# sentinel02
192.168.157.118    26381

Configure three sentinels

sentinelxxxx.conf File

sentinel00

sentinel26379.conf

bind 0.0.0.0
daemonize yes
protected-mode no
port 26379
logfile "/myredis/sentinel26379.log"
pidfile /var/run/redis-sentinel26379.pid
dir /myredis
sentinel monitor mymaster 192.168.157.115 6379 2
sentinel auth-pass mymaster 1234

sentinel01

sentinel26380.conf

bind 0.0.0.0
daemonize yes
protected-mode no
port 26380
logfile "/myredis/sentinel26380.log"
pidfile /var/run/redis-sentinel26380.pid
dir /myredis
sentinel monitor mymaster 192.168.157.115 6379 2
sentinel auth-pass mymaster 1234

sentinel02

sentinel26381. conf

bind 0.0.0.0
daemonize yes
protected-mode no
port 26381
logfile "/myredis/sentinel26381.log"
pidfile /var/run/redis-sentinel26381.pid
dir /myredis
sentinel monitor mymaster 192.168.157.115 6379 2
sentinel auth-pass mymaster 1234

Test

• Based on the previous redis replication, start 1 master and 2 slaves to test whether the master-slave replication is normal, enter info replication to check whether it is normal

• Start three sentries and complete monitoring

  redis-sentinel /myredis/sentinel26379.conf --sentinel
  redis-sentinel /myredis/sentinel26380.conf --sentinel
  redis-sentinel /myredis/sentinel26381.conf --sentinel

• Test master-slave replication, everything is fine

• View log

• ##View the configuration file sentinel.conf

> 后面為自動新增內(nèi)容

• master host

  # 模擬宕機(jī)
  shudown

  Problem

  Is the data of the two slave machines normal? (yes)
  Will a new master be selected from the remaining two machines? (yes)
  Will the previous master take over again and become the master again after restarting? (no)
• salveGet data

• View new The master

• rewrite starts the original master
  and the master will not come back on.

file will be dynamically modified by sentinel during operation. After the master-slave master-slave relationship is switched, the content of the configuration file will automatically change.

• sentinel6379.conf file

##old master

• 新master

哨兵運(yùn)行流程和選舉原理

當(dāng)一個(gè)主從配置中的master失效后，sentinel可以選舉出一個(gè)新的master用于自動替換原master的工作，主從配置中的其他redis服務(wù)自動指向新的master同步數(shù)據(jù)，一般建議sentinel采取奇數(shù)臺，防止某一臺sentinel無法連接到master導(dǎo)致誤切換。

SDown主觀下線(Subjectively Down)

SDOWN（主觀不可用）是單個(gè)哨兵自己主觀檢測到的關(guān)于master的狀態(tài)，從sentinel的角度來看，如果發(fā)送了PING心跳后，在一定時(shí)間內(nèi)沒有收到合法的回復(fù)，就到達(dá)了SDOQN的條件。

sentinel配置文件中的 down-after-milliseconds 設(shè)置了主觀下線的時(shí)間長度（默認(rèn)30秒）。

# sentinel down-after-milliseconds <masterName> <timeout>
sentinel down-after-milliseconds mymaster 30000

ODown客觀下線(Objectively Down)

ODOWN需要一定數(shù)量的sentinel，多個(gè)哨兵達(dá)成一致意見才能確認(rèn)一個(gè)master客觀上已經(jīng)宕機(jī)了。

# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2

選舉出領(lǐng)導(dǎo)者哨兵

當(dāng)主節(jié)點(diǎn)被判斷客觀下線后，各個(gè)哨兵節(jié)點(diǎn)會進(jìn)行協(xié)商，先選舉出一個(gè)領(lǐng)導(dǎo)者哨兵節(jié)點(diǎn)，并由該領(lǐng)導(dǎo)者哨兵節(jié)點(diǎn)進(jìn)行failover（故障遷移）

領(lǐng)導(dǎo)者哨兵如何選出來的？

Raft算法

監(jiān)視該主節(jié)點(diǎn)的所有哨兵都有可能被選為領(lǐng)導(dǎo)者，選舉使用的算法是Raft算法；Raft算法的基本思路是先到先得，即在一輪選舉中，哨兵A向B發(fā)送成為領(lǐng)導(dǎo)者的申請，如果B沒有同意過其他哨兵，則會同意A成為領(lǐng)導(dǎo)者。

選新的master（im）

整個(gè)過程由sentinel自己獨(dú)立完成，無需人工干涉。

新主登基

某一個(gè)slave被選中成為master

選出新的master的規(guī)則，剩余slave節(jié)點(diǎn)健康的前提下

1. redis.conf文件中，優(yōu)先級slave-priority或者replica-priority最高節(jié)點(diǎn)（數(shù)字越小優(yōu)先級越高）
2. 復(fù)制偏移量offset最大的從節(jié)點(diǎn)。
3. 最小Run ID的從節(jié)點(diǎn)。

群臣俯首

• 執(zhí)行 slaveof no one 命令讓選出來的從節(jié)點(diǎn)成為新的主節(jié)點(diǎn)，并通過 slaveof 命令讓其他節(jié)點(diǎn)成為其從節(jié)點(diǎn)。

• sentinel leader 會對選舉出來的新 master 執(zhí)行 slaveof no one，將其提升為master節(jié)點(diǎn)

• sentinel leader 向其他slave發(fā)送命令，讓剩余的slave成為新的master節(jié)點(diǎn)的slave。

舊主拜服

• 將之前的已經(jīng)下線的舊master設(shè)置為新選出的新master的從節(jié)點(diǎn)，當(dāng)舊master重新上線后，它會成為新master的從節(jié)點(diǎn)
• sentinel leader 會讓原來的master降級為slave并恢復(fù)正常工作。

哨兵使用建議

• 哨兵節(jié)點(diǎn)數(shù)量應(yīng)該為多個(gè)，哨兵本身應(yīng)該為集群，保證高可用
• 哨兵節(jié)點(diǎn)數(shù)量應(yīng)該是奇數(shù)
• 各個(gè)哨兵節(jié)點(diǎn)的配置應(yīng)該一致
• 如果哨兵節(jié)點(diǎn)部署在docker等容器里面，尤其要注意端口的正確映射
• 哨兵集群 + 主從復(fù)制，并不能保證數(shù)據(jù)零丟失

更多編程相關(guān)知識，請?jiān)L問：編程視頻！！

The above is the detailed content of Understand the sentinel in Redis in depth. For more information, please follow other related articles on the PHP Chinese website!