OPPO 最新摺疊手機專利公佈：鉸鏈矚目
阿新 • • 發佈：2020-10-06
redis哨兵的搭建建立在已經存在的主從叢集之上，因此你需要先搭建好一套redis主從叢集，這裡我們使用三個節點，即一主兩從。
主節點ip地址：192.168.50.130
第一個從節點ip地址：192.168.50.131
第二個從節點ip地址：192.168.50.132
1、主從搭建
主節點配置檔案新增一行配置masterauth "111111"
從節點配置檔案新增如下配置
replicaof 192.168.50.130 6379
masterauth "111111"
注意：masterauth是主從之間連線的密碼，節點的密碼都是一樣的，此外這個密碼與requirepass不是一回事。
搭建好之後啟動一下redis。
在主節點上面，進入redis命令列執行info replication
127.0.0.1:6379> info replication # Replication role:master connected_slaves:2 slave0:ip=192.168.50.131,port=6379,state=online,offset=1109,lag=0 slave1:ip=192.168.50.132,port=6379,state=online,offset=1109,lag=0 master_replid:d1fb20462e09464a4b27400aa04c68de22663197 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:1109 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:1109
從上面可以看到從節點的資訊，以及當前節點確實是master節點。
現在我們來從節點看看，進入redis命令列執行info命令。
127.0.0.1:6379> info replication # Replication role:slave master_host:192.168.50.130 master_port:6379 master_link_status:up master_last_io_seconds_ago:1 master_sync_in_progress:0 slave_repl_offset:1305 slave_priority:100 slave_read_only:1 connected_slaves:0 master_replid:d1fb20462e09464a4b27400aa04c68de22663197 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:1305 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:1305
我們能夠看到上面的master_link_status為up狀態，說明當前節點是正常的。第二個從節點可以自己做驗證。
那麼驗證主從叢集是否可用，我們可以在主節點上面建立一個key和value，然後此時去兩個從節點分別檢視是否同步對應的key和value資料即可。
2、哨兵搭建
上面的主從搭建好之後，此時我們就可以來搭建哨兵模式了。簡單的介紹一下哨兵叢集。
Redis 的 Sentinel 系統用於管理多個 Redis 伺服器（instance）， 該系統執行以下三個任務：
監控（Monitoring）： Sentinel 會不斷地檢查你的主伺服器和從伺服器是否運作正常。
提醒（Notification）： 當被監控的某個 Redis 伺服器出現問題時， Sentinel 可以通過 API 向管理員或者其他應用程式傳送通知。
自動故障遷移（Automatic failover）： 當一個主伺服器不能正常工作時， Sentinel 會開始一次自動故障遷移操作， 它會將失效主伺服器的其中一個從伺服器升級為新的主伺服器， 並讓失效主伺服器的其他從伺服器改為複製新的主伺服器； 當客戶端試圖連線失效的主伺服器時， 叢集也會向客戶端返回新主伺服器的地址， 使得叢集可以使用新主伺服器代替失效伺服器。
Redis Sentinel 是一個分散式系統， 你可以在一個架構中執行多個 Sentinel 程序（progress）， 這些程序使用流言協議（gossip protocols)來接收關於主伺服器是否下線的資訊， 並使用投票協議（agreement protocols）來決定是否執行自動故障遷移， 以及選擇哪個從伺服器作為新的主伺服器。
雖然 Redis Sentinel 釋出為一個單獨的可執行檔案 redis-sentinel ， 但實際上它只是一個執行在特殊模式下的 Redis 伺服器， 你可以在啟動一個普通 Redis 伺服器時通過給定 –sentinel 選項來啟動 Redis Sentinel
首先是把哨兵的配置檔案sentinel.conf複製到/apps/redis/etc目錄下，這個目錄是我們編譯redis的工作目錄。三個節點都需要把配置檔案放到etc目錄下面。我們在主節點上面配置好sentinel.conf配置檔案，然後再複製該檔案到另外兩個節點上面去。
bind 0.0.0.0
port 26379
daemonize yes
pidfile "redis-sentinel.pid"
logfile "sentinel.log"
dir "/apps/redis/logs"
sentinel deny-scripts-reconfig yes
sentinel monitor mymaster 192.168.50.130 6379 2
sentinel down-after-milliseconds mymaster 15000
sentinel auth-pass mymaster 111111
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1
簡單講解一下上面的配置：
sentinel monitor mymaster 192.168.50.130 6379 2 #法定人數限制(quorum)，即有幾個slave認為master down了就進行故障轉移
sentinel auth-pass mymaster 111111 # 這個是密碼，密碼需要與requirepass密碼保持一直。
sentinel down-after-milliseconds mymaster 30000 #(SDOWN)主觀下線的時間
sentinel parallel-syncs mymaster 1 #發生故障轉移時候同時向新master同步資料的slave數量，數字越小總 同步時間越長
sentinel failover-timeout mymaster 180000 #所有slaves指向新的master所需的超時時間
sentinel deny-scripts-reconfig yes #禁止修改指令碼
複製該配置檔案到另外的兩個節點上面
[root@lvs etc]# scp sentinel.conf [email protected]:/apps/redis/etc/
[email protected]'s password:
sentinel.conf 100% 9814 6.8MB/s 00:00
三臺主機都啟動哨兵服務
redis-sentinel /apps/redis/etc/sentinel.conf
首先在主節點檢視哨兵服務
[root@lvs etc]# redis-cli -p 26379 # 這裡需要指定連線的是26379這個哨兵服務埠
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.50.130:6379,slaves=2,sentinels=3
顯示為ok狀態，說明這是沒有問題的。
再去其他的節點上看看哨兵服務是否正常。
[root@nginx-web1 etc]# redis-cli -p 26379
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.50.130:6379,slaves=2,sentinels=3
第三個節點
[root@nginx-web2 etc]# redis-cli -p 26379
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.50.130:6379,slaves=2,sentinels=3
看的出來幾個節點的哨兵服務都是正常的，然後現在我們看看主節點的哨兵日誌，。
1879:X 07 Oct 2020 12:10:51.186 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
1879:X 07 Oct 2020 12:10:51.186 # Redis version=5.0.9, bits=64, commit=00000000, modified=0, pid=1879, just started
1879:X 07 Oct 2020 12:10:51.186 # Configuration loaded
1880:X 07 Oct 2020 12:10:51.187 * Increased maximum number of open files to 10032 (it was originally set to 1024).
1880:X 07 Oct 2020 12:10:51.188 * Running mode=sentinel, port=26379.
1880:X 07 Oct 2020 12:10:51.190 # Sentinel ID is cdc81e010e3676379c065b3ea78c56a5ef761732
1880:X 07 Oct 2020 12:10:51.190 # +monitor master mymaster 192.168.50.130 6379 quorum 2
1880:X 07 Oct 2020 12:10:51.191 * +slave slave 192.168.50.131:6379 192.168.50.131 6379 @ mymaster 192.168.50.130 6379
1880:X 07 Oct 2020 12:10:51.192 * +slave slave 192.168.50.132:6379 192.168.50.132 6379 @ mymaster 192.168.50.130 6379
1880:X 07 Oct 2020 12:10:59.067 * +sentinel sentinel af707d062b0d449873e864005c1a308cbc2e48e4 192.168.50.131 26379 @ mymaster 192.168.50.130 6379
1880:X 07 Oct 2020 12:11:02.859 * +sentinel sentinel c4ba9fcb2a9d7dd835b37588a0238fb8c937109e 192.168.50.132 26379 @ mymaster 192.168.50.130 6379
從上面可以看出來，當前節點是主節點並已經被監控到，此外最後四行也檢測到了兩個從節點。整個哨兵叢集是沒有問題的。
3、測試哨兵叢集是否可正常切換
現在我們把主節點的redis服務給停止掉
systemctl stop redis
稍等片刻，大約15秒左右，開始進行故障轉移。
現在我們隨便連線到一個從節點上面，比如第二個節點192.168.50.132這個上面
[root@nginx-web2 etc]# redis-cli -a 111111
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
127.0.0.1:6379> info replication
# Replication
role:slave
master_host:192.168.50.131
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:117783
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:2f77718643d6b61adf730445575f16bb02a2714d
master_replid2:d1fb20462e09464a4b27400aa04c68de22663197
master_repl_offset:117783
second_repl_offset:95013
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:141
repl_backlog_histlen:117643
通過上面的可以看到，當前這個從節點依然是從節點，但是主節點發生了變化，現在主節點是192.168.50.131這個節點了，而且是up狀態，即當前節點是正常的。
那麼現在我們來到192.168.50.131這個節點上面，檢視叢集狀態
[root@nginx-web1 etc]# redis-cli -a 111111
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.50.132,port=6379,state=online,offset=139945,lag=0
master_replid:2f77718643d6b61adf730445575f16bb02a2714d
master_replid2:d1fb20462e09464a4b27400aa04c68de22663197
master_repl_offset:139945
second_repl_offset:95013
看得出來叢集角色已經由slave轉變為了master角色。此時這臺節點對外提供服務。
我們通過日誌也是可以從日誌判斷出叢集的變化的，比如現在我們開啟原來舊的master節點（192.168.50.130）的哨兵日誌sentinel.log，檢視一下
1880:X 07 Oct 2020 12:18:28.483 # +sdown master mymaster 192.168.50.130 6379
1880:X 07 Oct 2020 12:18:28.567 # +odown master mymaster 192.168.50.130 6379 #quorum 3/2
1880:X 07 Oct 2020 12:18:28.567 # +new-epoch 2
1880:X 07 Oct 2020 12:18:28.567 # +try-failover master mymaster 192.168.50.130 6379
1880:X 07 Oct 2020 12:18:28.571 # +vote-for-leader cdc81e010e3676379c065b3ea78c56a5ef761732 2
1880:X 07 Oct 2020 12:18:28.576 # c4ba9fcb2a9d7dd835b37588a0238fb8c937109e voted for cdc81e010e3676379c065b3ea78c56a5ef761732 2
1880:X 07 Oct 2020 12:18:28.576 # af707d062b0d449873e864005c1a308cbc2e48e4 voted for cdc81e010e3676379c065b3ea78c56a5ef761732 2
1880:X 07 Oct 2020 12:18:28.662 # +elected-leader master mymaster 192.168.50.130 6379
1880:X 07 Oct 2020 12:18:28.662 # +failover-state-select-slave master mymaster 192.168.50.130 6379
1880:X 07 Oct 2020 12:18:28.718 # +selected-slave slave 192.168.50.131:6379 192.168.50.131 6379 @ mymaster 192.168.50.130 6379
1880:X 07 Oct 2020 12:18:28.718 * +failover-state-send-slaveof-noone slave 192.168.50.131:6379 192.168.50.131 6379 @ mymaster 192.168.50.130 6379
1880:X 07 Oct 2020 12:18:28.784 * +failover-state-wait-promotion slave 192.168.50.131:6379 192.168.50.131 6379 @ mymaster 192.168.50.130 6379
1880:X 07 Oct 2020 12:18:29.084 # +promoted-slave slave 192.168.50.131:6379 192.168.50.131 6379 @ mymaster 192.168.50.130 6379
1880:X 07 Oct 2020 12:18:29.084 # +failover-state-reconf-slaves master mymaster 192.168.50.130 6379
1880:X 07 Oct 2020 12:18:29.157 * +slave-reconf-sent slave 192.168.50.132:6379 192.168.50.132 6379 @ mymaster 192.168.50.130 6379
1880:X 07 Oct 2020 12:18:29.708 # -odown master mymaster 192.168.50.130 6379
1880:X 07 Oct 2020 12:18:30.137 * +slave-reconf-inprog slave 192.168.50.132:6379 192.168.50.132 6379 @ mymaster 192.168.50.130 6379
1880:X 07 Oct 2020 12:18:30.138 * +slave-reconf-done slave 192.168.50.132:6379 192.168.50.132 6379 @ mymaster 192.168.50.130 6379
1880:X 07 Oct 2020 12:18:30.195 # +failover-end master mymaster 192.168.50.130 6379
1880:X 07 Oct 2020 12:18:30.195 # +switch-master mymaster 192.168.50.130 6379 192.168.50.131 6379
1880:X 07 Oct 2020 12:18:30.195 * +slave slave 192.168.50.132:6379 192.168.50.132 6379 @ mymaster 192.168.50.131 6379
1880:X 07 Oct 2020 12:18:30.196 * +slave slave 192.168.50.130:6379 192.168.50.130 6379 @ mymaster 192.168.50.131 6379
1880:X 07 Oct 2020 12:18:45.200 # +sdown slave 192.168.50.130:6379 192.168.50.130 6379 @ mymaster 192.168.50.131 6379
這裡我們解釋一下上面的日誌大概的含義
+reset-master ：主伺服器已被重置。
+slave ：一個新的從伺服器已經被 Sentinel 識別並關聯。
+failover-state-reconf-slaves ：故障轉移狀態切換到了 reconf-slaves 狀態。
+failover-detected ：另一個 Sentinel 開始了一次故障轉移操作，或者一個從伺服器轉換成了主伺服器。
+slave-reconf-sent ：領頭（leader）的 Sentinel 向例項傳送了 [SLAVEOF](/commands/slaveof.html) 命令，為例項設定新的主伺服器。
+slave-reconf-inprog ：例項正在將自己設定為指定主伺服器的從伺服器，但相應的同步過程仍未完成。
+slave-reconf-done ：從伺服器已經成功完成對新主伺服器的同步。
-dup-sentinel ：對給定主伺服器進行監視的一個或多個 Sentinel 已經因為重複出現而被移除 —— 當 Sentinel 例項重啟的時候，就會出現這種情況。
+sentinel ：一個監視給定主伺服器的新 Sentinel 已經被識別並新增。
+sdown ：給定的例項現在處於主觀下線狀態。
-sdown ：給定的例項已經不再處於主觀下線狀態。
+odown ：給定的例項現在處於客觀下線狀態。
-odown ：給定的例項已經不再處於客觀下線狀態。
+new-epoch ：當前的紀元（epoch）已經被更新。
+try-failover ：一個新的故障遷移操作正在執行中，等待被大多數 Sentinel 選中（waiting to be elected by the majority）。
+elected-leader ：贏得指定紀元的選舉，可以進行故障遷移操作了。
+failover-state-select-slave ：故障轉移操作現在處於 select-slave 狀態 —— Sentinel 正在尋找可以升級為主伺服器的從伺服器。
no-good-slave ：Sentinel 操作未能找到適合進行升級的從伺服器。Sentinel 會在一段時間之後再次嘗試尋找合適的從伺服器來進行升級，又或者直接放棄執行故障轉移操作。
selected-slave ：Sentinel 順利找到適合進行升級的從伺服器。
failover-state-send-slaveof-noone ：Sentinel 正在將指定的從伺服器升級為主伺服器，等待升級功能完成。
failover-end-for-timeout ：故障轉移因為超時而中止，不過最終所有從伺服器都會開始複製新的主伺服器（slaves will eventually be configured to replicate with the new master anyway）。
failover-end ：故障轉移操作順利完成。所有從伺服器都開始複製新的主伺服器了。
+switch-master ：配置變更，主伺服器的 IP 和地址已經改變。 這是絕大多數外部使用者都關心的資訊。