（六）Redis主從自動恢復-sentinel

 

原文地址，轉載請注明出處： http://blog.csdn.net/qq_34021712/article/details/72026313     ©王賽超

准備工作：（1個master，2個slave）

1. redis-3.x安裝好，具體步驟看前邊的博客
2. 安裝出來的bin復制4份，命名bin,bin1,bin2,sentinel
3. redis.conf和sentinel.conf各四份，具體如圖

目錄結構

master（slave同）

哨兵，三分sentinel配置文件

 

1.Redis主從配置

修改每一個redis的bin*目錄下的redis.conf

   bind 192.168.1.103 #修改為自己對應的服務器ip，實際應用中都會分配專門的ip，自己測試用可以注釋掉或者改成0.0.0.0表示允許所有連接 
   port 6379   #依次修改為 6379  6380  6381端口  

###可選項
   pidfile /var/run/redis_6379.pid  #依次修改為其對應的端口號，可以忽略，讓其默認
　　daemonize yes #允許后台運行
　　appendonly yes #根據需求是否開啟
　　repl-diskless-sync no #yes：主從復制采用網絡傳輸，不傳輸rdb文件，默認：no
　　requirepass  xxxx #從機和哨兵連接自身的密碼，默認不需要密碼   主機時有效
　　masterauth   xxxx #從機和哨兵連接主機時的密碼　　從機和哨兵時有效

 

設置主從

修改redis.conf文件,這里將6379端口設置為master所以不需要做任何操作,只需要修改6380端口和6381端口就可以了
　　slaveof 127.0.0.1 6379

連接redis的master節點,查看主從狀態

 

 

[root@localhost bin]# ./redis-cli -p 6379 -h 192.168.1.103   #連接redis服務
192.168.1.103:6379> INFO replication      #查看當前節點的信息
# Replication
role:master #master

connected_slaves:2 #slave節點的個數

slave0:ip=192.168.1.103,port=6380,state=online,offset=1443,lag=1    #slave節點的信息

slave1:ip=192.168.1.103,port=6381,state=online,offset=1443,lag=1#slave節點的信息

master_repl_offset:1443

repl_backlog_active:1

repl_backlog_size:1048576

repl_backlog_first_byte_offset:2

repl_backlog_histlen:1442

測試主備是否好用

2.Redis讀寫分離

2.1：根據上圖可以看出slave只有讀的權限,不能寫,如果想要slave開啟寫的操作需要修改redis.conf文件

　　slave-read-only yes  #修改為yes 表示slave可寫  

2.2：復制的過程原理

1)、當從庫和主庫建立MS關系后，會向主數據庫發送SYNC命令；
2)、主庫接收到SYNC命令后會開始在后台保存快照（RDB持久化過程），並將期間接收到的寫命令緩存起來；
3)、當快照完成后，主Redis會將快照文件和所有緩存的寫命令發送給從Redis；
4)、從Redis接收到后，會載入快照文件並且執行收到的緩存的命令；
5)、之后，主Redis每當接收到寫命令時就會將命令發送從Redis，從而保證數據的一致；

2.3：開啟無磁盤復制

通過前面的復制過程我們了解到，主庫接收到SYNC的命令時會執行RDB過程，即使在配置文件中禁用RDB持久化也會生成，那么如果主庫所在的服務器磁盤IO性能較差，那么這個復制過程就會出現瓶頸，慶幸的是，Redis在2.8.18版本開始實現了無磁盤復制功能
原理：
Redis在與從數據庫進行復制初始化時將不會將快照存儲到磁盤，而是直接通過網絡發送給從數據庫，避免了IO性能差問題。
開啟無磁盤復制：repl-diskless-sync yes(默認是no不開啟)

3.redis的哨兵(sentinel)配置

3.1：如果redis的主從架構中出現宕機怎么辦？

如果在主從復制架構中出現宕機的情況，需要分情況看：
1)、從Redis宕機
a)這個相對而言比較簡單，在Redis中從庫重新啟動后會自動加入到主從架構中，自動完成同步數據；
b)如果從庫在斷開期間，主庫的變化不大，從庫有做持久化的前提下,再次啟動后，會實現增量復制。
2、主Redis宕機
a)這個相對而言就會復雜一些，需要以下2步才能完成
i.第一步，在從數據庫中執行SLAVEOF NO ONE命令，斷開主從關系並且提升為主庫繼續服務；
ii.第二步，將主庫重新啟動后，執行SLAVEOF命令，將其設置為其他庫的從庫，這時數據就能更新回來；
這個手動完成恢復的過程其實是比較麻煩的並且容易出錯，有沒有好辦法解決呢？當前有的，Redis提供的哨兵（sentinel）的功能。

3.2：哨兵模式原理

Redis提供了sentinel（哨兵）機制，通過sentinel模式啟動redis后，自動監控master/slave的運行狀態，基本原理是：心跳機制+投票裁決
每個sentinel會向其它sentinal、master、slave定時發送消息，以確認對方是否“活”着，如果發現對方在指定時間（可配置）內未回應，則暫時認為對方已掛（所謂的“主觀認為宕機” Subjective Down，簡稱SDOWN）。
若"哨兵群"中的多數sentinel，都報告某一master沒響應，系統才認為該master"徹底死亡"(即：客觀上的真正down機，Objective Down，簡稱ODOWN)，通過一定的vote算法，從剩下的slave節點中，選一台提升為master，然后自動修改相關配置。

3.3：哨兵模式的配置

1)、去./sentinel/下配置哨兵：sentinel-1.conf，內容如下

• port 26379  #另外兩個哨兵26380 26381
• dir /tmp  #默認即可
• sentinel monitor master 127.0.0.1 6379 2 #監聽master， 2 表示只要有兩個或兩個以上哨兵判定master掛了，那么就執行替換任務 
• sentinel down-after-milliseconds master 30000  
• sentinel parallel-syncs master 1  
• sentinel failover-timeout master 180000  
• logfile "/var/log/sentinel_log.log"  

 

2)、配置文件的說明

1. port :當前Sentinel服務運行的端口
2. dir : Sentinel服務運行時使用的臨時文件夾
3.sentinel monitor master 192.168.110.101 6379 　　2:Sentinel去監視一個名為master的主redis實例，這個主實例的IP地址為本機地址192.168.1.103，端口號為6379，而將這個主實例判斷為失效至少需要1個 　　Sentinel進程的同意，只要同意Sentinel的數量不達標，自動failover就不會執行
4.sentinel down-after-milliseconds master 30000:指定了Sentinel認為Redis實例已經失效所需的毫秒數。當實例超過該時間沒有返回PING，或者直接返回錯誤，那么Sentinel將這個實例標記為主觀下線。只有一個 Sentinel進程將實例標記為主觀下線並不一定會引起實例的自動故障遷移：只有在足夠數量的Sentinel都將一個實例標記為主觀下線之后，實例才會被標記為客觀下線，這時自動故障遷移才會執行
5.sentinel parallel-syncs master 1：指定了在執行故障轉移時，最多可以有多少個從Redis實例在同步新的主實例，在從Redis實例較多的情況下這個數字越小，同步的時間越長，完成故障轉移所需的時間就越長
6.sentinel failover-timeout master 180000：如果在該時間（ms）內未能完成failover操作，則認為該failover失敗

3.4啟動哨兵和master、slave

編寫腳本來執行

最后的“&” 表示哨兵后台運行運行  ./start-all.sh

3.5測試master宕機

先用客戶端干掉6379：#./reids-cli -h 127.0.0.1 -p 6379 shutdown

日志打印：部分省略
1861:X 13 May 04:16:15.632 # +sdown master master 192.168.1.103 6379   #檢測到master服務已經宕機
1861:X 13 May 04:16:15.632 # +try-failover master master 192.168.1.103 6379   #開始恢復故障
1861:X 13 May 04:16:15.640 # +vote-for-leader 6de45c32109f5cf472c3130c38a537188d352c12 1  #投票選舉哨兵leader
1861:X 13 May 04:16:15.640 # +elected-leader master master 192.168.1.103 6379    #選中leader
1861:X 13 May 04:16:15.640 # +failover-state-select-slave master master 192.168.1.103 6379   #選中其中的一個slave當做master
1861:X 13 May 04:16:15.725 # +selected-slave slave 192.168.1.103:6380 192.168.1.103 6380 @ master 192.168.1.103 6379  #這里選中的是6380slave
1861:X 13 May 04:16:15.725 * +failover-state-send-slaveof-noone slave 192.168.1.103:6380 192.168.1.103 6380 @ master 192.168.1.103 6379   #發送slaveof no one命令
1861:X 13 May 04:16:15.788 * +failover-state-wait-promotion slave 192.168.1.103:6380 192.168.1.103 6380 @ master 192.168.1.103 6379    #等待升級master
1861:X 13 May 04:16:16.117 # +promoted-slave slave 192.168.1.103:6380 192.168.1.103 6380 @ master 192.168.1.103 6379    #升級6380為master
1861:X 13 May 04:16:16.117 # +failover-state-reconf-slaves master master 192.168.1.103 6379
1861:X 13 May 04:16:16.181 * +slave-reconf-sent slave 192.168.1.103:6381 192.168.1.103 6381 @ master 192.168.1.103 6379
1861:X 13 May 04:16:17.123 * +slave-reconf-inprog slave 192.168.1.103:6381 192.168.1.103 6381 @ master 192.168.1.103 6379
1861:X 13 May 04:16:18.182 * +slave-reconf-done slave 192.168.1.103:6381 192.168.1.103 6381 @ master 192.168.1.103 6379
1861:X 13 May 04:16:18.243 # +failover-end master master 192.168.1.103 6379   #故障恢復完成
1861:X 13 May 04:16:18.244 * +slave slave 192.168.1.103:6381 192.168.1.103 6381 @ master 192.168.1.103 6380   #添加6381為6380的從庫
結果：

用客戶端打開：# ./redis-cli -h 127.0.0.1 -p 6380

xxxxx> info replication

role:master

slave: 1

...

結果表示：6379已經掛了，6380上位。

恢復6379：把rdb文件從別處復制到6379，然后修改配置文件，作為6380的奴隸，最后啟動