Redis持久化數據介紹&主從複製和哨兵模式環境部署

第一章.Redis的性能測試

性能測試是經過往Redis中插入數據和讀取數據執行多條命令實現的.

1. Redis- redis-benchmark

1.1 語法結構

redis-benchmark [option] [option value]

1.2 命令參數

序號	選項	描述	默認值
1	-h	指定服務器主機名,能夠是本地的和遠端的	127.0.0.1
2	-p	指定服務器端口	6379
3	-s	指定服務器 socket
4	-c	指定併發鏈接數	50
5	-n	指定請求數	10000
6	-d	以字節的形式指定 SET/GET 值的數據大小	2
7	-k	1=keep alive 0=reconnect	1
8	-r	SET/GET/INCR 使用隨機 key, SADD 使用隨機值
9	-P	經過管道傳輸 請求	1
10	-q	強制退出 redis。僅顯示 query/sec 值
11	--csv	以 CSV 格式輸出
12	-l	生成循環，永久執行測試
13	-t	僅運行以逗號分隔的測試命令列表。
14	-I	Idle 模式。僅打開 N 個 idle 鏈接並等待。

1.3 執行測試

[root@redis01 ~]# redis-benchmark -h 127.0.0.1 -p 6379 -t set,lpush -n 100000 -q
SET: 55401.66 requests per second
LPUSH: 58072.01 requests per second

性能測試,參考地址,點擊這裏

第二章.shell腳本簡單測試寫入

2.1 shell腳本

1.寫一個簡單的for ,由於for是一行一行的執行,插入的會相對慢.

[root@redis01 ~]# cat redis_performance.sh 
#!/bin/bash
##############################################################
# File Name: redis_performance.sh
# Version: V1.0
# Author: liych
# Organization: http://itshangyun.com
# Created Time : 2020-03-22 9:45:32
# Description:
##############################################################

for redis in {1..100000}
do
	redis-cli -h redis01 set K_${redis} v_${redis}
done

2.2 操做示例

1.執行腳本
[root@redis01 ~]# time sh redis_performance.sh
real	4m29.302s
user	0m51.673s
sys	2m54.324s

2.登錄到redis查看

> KEYS *

能夠看到已經寫入3萬多 用時0.78s
36372) "K_23129"
(0.78s)

第三章.Redis持久化緩存數據

3.1 爲何要用持久化緩存呢?

說明:

由於咱們插入到redis的數據都在redis自身的緩存程序中,並不在咱們的本地硬盤內,這樣的話,當咱們重啓或者殺死redis這個進程後,發現redis中的數據會不存在的,那麼以前咱們規劃的數據目錄中依舊也是沒有數據的,而後呢? 數據就真的不復存在了,這樣的話,沒有緩存就沒有數據,是不行的.不能實現數據緩存並加速讀的效率,首先來驗證一下 殺死或僵死的Redis中數據丟失這種狀況.以後才能認識到持久化的重要性.

3.2 Redis中數據丟失 殺死進程

1.查看redis中
[root@redis01 ~]# redis-cli -h redis01 
redis01:6379> KEYS * 
...
52334) "K_48636"
52335) "K_23129"
(1.07s)
#這時的redis中是有緩存數據的.

2.殺死進程
[root@redis01 ~]# pkill  redis
[root@redis01 ~]# ps -ef |grep redis
root      74652  17796  0 22:36 pts/0    00:00:00 grep --color=auto redis

3.啓動redis
[root@redis01 ~]# redis-server /opt/redis_cluster/redis_6379/conf/redis_6379.conf 

4.驗證數據是否還在redis中
[root@redis01 ~]# redis-cli -h redis01
redis01:6379> KEYS *
(empty list or set)
# 這時候發現緩存在內的數據已經不復存在了.

5.本地的數據目錄也是沒有的
[root@redis01 ~]# ll /data/redis_cluster/redis_6379/
總用量 0

緩存數據留存在Redis內存中的數據,當發生殺死進程,或異常斷電,重啓等,緩存數據會丟失

3.3 持久化緩存數據

點擊一下 官網介紹Redis的持久化性能

Redis的持久化提供給兩種 RDB和AOF.

3.4 RDB持久化介紹

RDB持久性, 按指定的時間間隔執行數據集的時間點快照,並把內存的數據快照到硬盤. 須要定時定點的執行bgsave將數據進行快照備份.

RDB優勢:
① RDB是很是緊湊的二進制文件用LZF壓縮格式留存,全量備份數據,恢復速度快 ,RDB文件很是適合備份。 
---
RDB不足:
① 存在丟失數據的風險,Redis使用特定的二進制文件格式留存,伴隨着Redis的更新,存在這老版本的Redis和新版本的Redis, 恢復數據時候的致使RDB數據格式不兼容
② RDB須要常用Fork才能使用子進程將其持久化在磁盤上。 若是數據量很大，Fork可能很耗時 , 則可能致使Redis中止爲客戶端服務幾毫秒甚至一秒鐘,沒有辦法作到實時的持久化,由於bgsave每次運行時候 ,都要啓動一個FORK進程.
③ 執行bgsave的時候,是將本來的內存數據,複製一份到本地存儲目錄,屬於重量性操做,耗內存.

3.4.1 RDB備份方式

1.執行bgsave命令Redis父進程判斷當前是否存在正在執行的子進程,如RDB/AOF子進程,若是存在,將直接返回.

2.父進程執行fork操做 建立子進程,fork操做過程當中,父進程會阻塞,能夠登錄經過Redis後執行 info stats 命令查看,latest_fork_usec選項,能夠獲取到最近一個fork操做的耗時時間.單位是秒

3.父進程fork完成 BGSAVE後 返回 Background saving started後,將再也不進行阻塞,能夠繼續響應其餘的命令.

4.子進程建立RDB文件,根據文件進程內存生成時的快照文件,完成後對原文件進行替換,命令行執行last save 命令能夠獲取最後一次生成的RDB的時間,對應的info stats 統計的是rdb_last_save_time選項,
	
5.進程發送信號給父進程表示完成,父進程更新統計信息,可執行info persistence查看rdb選項的狀態信息

6.須要注意的是 生成的子進程也是須要一個獨立的內存空間,當系統內存空間不足是,進程將進入僵死狀態.好比redis服務器共計64G內存,redis使用32G,剩下歸系統和子進程使用.

3.4.2 RDB文件處理

保存

1.RDB文件保存在配置文件內指定的目錄中,文件名經過dbfilename配置指定,Redis運行期間可經過config set 配置新的目錄保存位置,當下次運行RDB的時候文件會保存在set的目錄中.

壓縮

1.Redis默認採用LZF算法對生成的RDB文件作壓縮處理,壓縮後的文件小於內存大小,默認是開啓,能夠經過參數 config set rdbcompression (yes|no) 動態修改

校驗

1.若是Redis加載損壞的RDB文件是拒絕啓動,並打印以下信息

#Short read or OMM loading DB Unrecoverable error aborting now

這是可使用Redis提供的 redis-check-dump工具,檢測RDB文件並獲取對應的錯誤報告

3.4.3 如何配置ROB持久化

使用BGSAVE 保存數據緩存到本地的備份目錄

1.首先在配置文件內修改好本地硬盤存儲數據位置並設定持久化策略 /data/redis_cluster/redis_6379/

2.登錄到Redis中保存數據

參數	說明
save 900 1	900秒內有1個更改觸發備份
save 300 10	300秒內有10個更改觸發備份
save 60 10000	60秒內有10000個更改觸發備份
	# 知足上述條件之一就執行RDB存儲.

 一: 修改配置文件增長觸發條件

1.修改配置文件 增長設定持久化數據留存條件
[root@redis01 ~]# vim /opt/redis_cluster/redis_6379/conf/redis_6379.conf

## 指定本地持久化文件的文件名,默認是dump.rdb
dbfilename redis_6379.rdb
## 本地數據庫的目錄
dir /data/redis_cluster/redis_6379/
## 設定持久化數據留存條件
save 900 1
save 300 10
save 60 10000

-----
2.從新啓動redis
redis-server /opt/redis_cluster/redis_6379/conf/redis_6379.conf

3.關閉命令,不執行
redis-cli -h redis01 shutdown

 二: RDB備份持久化

一: RDB備份持久化
1.登錄到Redis內
redis01:6379> KEYS *
1000) "K_76"
redis01:6379> BGSAVE         #執行保存
Background saving started    #保存成功

2.查看本地數據目錄
[root@redis01 ~]# ls /data/redis_cluster/redis_6379/
redis_6379.rdb  #數據留存

 三: RDB恢復持久化

1. 將備份文件 (默認dump.rdb)移動到 redis 安裝目錄並啓動服務，redis就會自動加載文件數據至內存了。Redis 服務器在載入RDB文件期間，會一直處於阻塞狀態，直到載入工做完成爲止。

2. 使用 CONFIG GET dir 獲取持久化目錄
redis01:6379> CONFIG GET dir
1) "dir"
2) "/data/redis_cluster/redis_6379"

 四: RDB中止持久化

兩種方式:
1.註釋配置文件的save參數
2.替換空字符形式
redis-cli config set save " "

這時殺掉redis進程後,重啓Redis,數據依舊會顯示出來,那是由於咱們備份的數據會預加載到內存中

3.4.4 持久化數據總結

1.觸發條件設定後,執行shutdown,Redis會自動執行bgsave,而後再執行shutdown.數據會留存本地硬盤. 
2.觸發條件設定後,執行pkill kill(kill -15) killall.依舊會觸發條件並作持久化.
6.kill -9 redis 強制殺死進程後,Redis內部不會觸發持久化,數據目錄內沒有數據.
3.恢復持久化的數據的時候,RDB文件名稱要和配置文件裏dbfilename設定的同樣,沒有rdb數據內存也是不會有的
4.未配置save參數,執行shutdown不會自動觸發bgsave持久化,現象數據丟失
5.未配置save參數,手動執行bgsave觸發持久化並保存到本地設定好的目錄dir

3.5 AOF介紹(append only file)

AOF持久化會記錄服務器接收的每一個寫入操做，這些操做將在服務器啓動時再次執行，以恢復原始數據集。使用與Redis協議自己相同的格式記錄命令，而且僅採用追加方式。當日志太大時，Redis能夠在後臺重寫日誌.主要的做用是解決了數據持久化的實時性, 能夠理解爲 MySQL的binlog. 只記錄操做記錄,不記錄歷史數據.

AOF優勢:
1.AOF日誌僅是一個追加日誌，所以，若是斷電，也不會出現尋道或損壞問題。它是逐條記錄備份,損失數據最多1秒，當出現數據損壞可使用redis-check-aof 工具輕鬆修復它。

2.Redis數據集太大時，Redis能夠在後臺自動重寫AOF。重寫是徹底安全的，由於Redis繼續追加到舊文件時，會生成一個全新的文件，其中包含建立當前數據集所需的最少操做集，一旦準備好第二個文件，Redis會切換這兩個文件並開始追加到新的那一個。

3.AOF以易於理解和解析的格式包含全部操做的日誌。您甚至能夠輕鬆導出AOF文件。例如，即便您使用FLUSHALL命令刷新了全部錯誤文件，若是在此期間未執行任何日誌重寫操做，您仍然能夠保存數據集，只是中止服務器，刪除最新命令並從新啓動Redis。

---
AOF不足:
1.恢復較大數據會比較慢

3.5.1 AOF備份方式

1.全部寫入命令追加到AOF buffer 緩衝區中.

2.AOF緩衝區根據對應的策略向硬盤同步操做

3.隨着AOF文件愈來愈大,須要定時對AOF文件進行重寫,達到壓縮的目的

4.當Redis服務器重啓時,能夠加載AOF文件進行數據恢復

5.AOF命令寫入的內容是文本格式

3.5.2 關於AOF的兩個疑惑?

一. AOF爲何直接採用文件協議格式?

1.文本協議具備很好的兼容性
2.開啓AOF後,全部的寫入命令均可以追加操做,避免來回調用的數據開銷
3.文本協議具備可讀性,方便直接修改和處理

二. AOF爲何把命令追加到 AOF Buffer中?

1.Redis使用單線程響應命令,若是每次寫入AOF文件命令都直接追加到硬盤,那麼性能徹底取決當前硬盤的負載,先寫入緩衝區,還有另一個好處 ,能夠提供多種緩衝區同步硬盤的策略,在性能和安全安性方便作出平衡.

3.5.3 如何配置AOF持久化

redis提供多種AOF緩衝區同步文件策略,由參數 appendfsync控制

參數	說明
appendonly	yes 開啓AOF日誌功能
always	寫入AOF緩衝區調用系統的fsync 操做同步到AOF文件,執行當即持久化,完成後返回 | 配置爲always時,每次寫入都要同步AOF文件, 在通常的SATA硬盤上,Redis只支持大約幾百TPS寫入,不能實現高速緩存,並不建議配置.
everysec	寫入AOF緩衝區調用系統的write操做,完成後返回,fsync同步文件操線程每秒調用一次 | 建議配置爲everysec是建議的同步策略,同時也是默認配置,它作到兼顧性能和數據的安全性,固然在系統宕機的時候官方說丟失1秒的數據,也存在數據所有丟失的風險.
no	寫入AOF 緩衝區調用系統的write操做,不對AOF文件作fsync同步,同步硬盤由操做系統負責,一般同步週期最長30秒 | 配置爲 no .因爲操做系統每次同步AOF文件的週期不可控,並且會加大同步硬盤的數據量,雖然提高了性能,可是數據安全性沒法保證.

一: 修改配置文件增長觸發條件

1.修改配置文件 增長設定持久化數據留存條件
[root@redis01 ~]# vim /opt/redis_cluster/redis_6379/conf/redis_6379.conf

#指定本地持久化文件的文件名
appendfilename "redis_6379.aof"
#本地數據庫的目錄
dir /data/redis_cluster/redis_6379/
#開啓AOF
appendonly yes
#當即緩存到硬盤
appendfsync always
#一秒一次
appendfsync everysec
#交由系統負責緩存區大小在留存AOF中
appendfsync no

-----
2.從新啓動redis
redis-server /opt/redis_cluster/redis_6379/conf/redis_6379.conf

3.關閉命令,不執行
redis-cli -h redis01 shutdown

 二: 驗證數據 

[root@redis01 redis_6379]# ls /data/redis_cluster/redis_6379/
redis_6379.aof  redis_6379.rdb

#兩種數據同時存在數據目錄內,Redis出現故障後,在從新啓動的時候只讀AOF數據.

[root@redis01 redis_6379]# tail -10 redis_6379.aof 
K_1999
$6
v_1999
*3
$3
set
$6
K_2000
$6
v_2000	
#AOF持久化數據

二: 恢復數據 

[root@redis01 ~]# redis-cli -h redis01 -a 123456 < /data/redis_cluster/redis_6379/redis_6379.aof

3.5.4 write 和fsync說明

write	操做會觸發延遲寫(deiayed write)機制,linux內核提供頁緩衝區用來提升硬盤IO性能,操做在寫入系統緩衝區後直接返回,同步硬盤操做依賴系統調度. 例如: 緩衝區空間寫滿或達到特定時間週期,同步文件以前,若是此時系統故障或宕機,緩衝區內數據丟失
fsync	針對單個文件操做 (如AOF文件 ) 作強制磁盤同步fsync將阻塞直接寫入硬盤完成後返回,保證數據持久化

3.5.5 重寫機制

​ Redis持久化命令的不斷寫入到AOF文件,文件會愈來愈大,爲了解決這個問題,Redis引入AOF重寫機制,壓縮文件體積,AOF文件重寫是把Redis進程內部的數據轉化爲寫命令同步到新的AOF文件的過程.

第四章.Redis的安全認證

第四章.Redis安全認證

Redis的用戶認證指的是登錄的時候能夠輸入密碼,或其餘的token等認證方式,這裏說明的是基於密碼認證方式.默認開啓了密碼認證保護,只容許本地的127.0.0.1登錄.

4.1 開啓密碼認證

4.1.1 第一種方式

[root@redis01 ~]# vim /opt/redis_cluster/redis_6379/conf/redis_6379.conf
1.配置監聽內網主機地址
2.增長requirepass

##綁定主機上的網卡IP地址,這裏須要修改爲你當前主機的內網IP地址,容許主機認證
bind 127.0.0.1 192.168.188.159
##增長requirepass password
requirepass 123456

4.1.2 第二種方式

redis01:6379>  config set requirepass 123456

4.1.3 測試密碼登錄

1.第一種登錄測試
redis-cli -h db01 
redis01:6379> AUTH 123456
OK

2.第二種登錄測試
redis-cli -h db01 -a 123456 get kname

4.2 禁用危險命令

1）禁用命令
rename-command KEYS ""
rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command CONFIG ""

2）重命名命令
rename-command KEYS "X"
rename-command FLUSHALL "X"
rename-command FLUSHDB "X"
rename-command CONFIG "X"

第五章.Redis主從複製 Replication

5.1 主從複製的做用

​ 主要是解決單臺主機發生故障時候,數據丟失的風險, 作主從實現數據的備份,和MySQL的主從複製性質同樣.

5.2 主從同步操做示例

環境主機	角色
192.168.188.159-Redis01	主端(主庫)
192.168.188.160-Redis02	備端(從庫)

5.2.1 主節點操做

1.打包備份目錄的後上傳到備份節點
[root@redis01 ~]# tar zcvf redis01.tar.gz  /opt/redis_cluster/
[root@redis01 ~]# scp  redis01.tar.gz redis02:/opt/

5.2.2 從節點操做

1.解壓縮,生成redids-cli命令
[root@redis02 ~]# cd /opt/
[root@redis02 opt]# tar xf redis01.tar.gz
[root@redis02 opt]# mv opt/* .
[root@redis02 opt]# rm -rf redis01.tar.gz opt/
[root@redis02 opt]# cd redis_cluster/redis/ ; make install

2.建立備份目錄
[root@redis02 redis-3.2.9]# mkdir -p /data/redis_cluster/redis_6379/

3.修改配置文件
[root@redis02 redis]# vim /opt/redis_cluster/redis_6379/conf/redis_6379.conf 
## 綁定主機上的網卡IP地址,這裏須要修改爲你當前主機的內網IP地址，備的地址
bind 127.0.0.1 192.168.188.160
##同步主數據文件
SLAVEOF 192.168.188.159 6379
##驗證主庫認證密碼
#masterauth 123456
[root@redis02 redis]# redis-server /opt/redis_cluster/redis_6379/conf/redis_6379.conf
[root@redis02 redis]# netstat -lntp
[root@redis02 redis]# redis-cli -h redis02
redis02:6379>  KEYS *

5.2.3 創建主從複製關係

從庫端操做
配置方法:
1.臨時生效
[root@redis02 redis]# redis-cli -h redis02
redis02:6379> SLAVEOF 192.168.188.159 6379
OK

2.寫入配置文件永久生效
SLAVEOF 192.168.188.159 6379

5.2.4 檢查日誌,是否成功

主端日誌:
[root@redis01 ~]# tail -8  /opt/redis_cluster/redis_6379/logs/redis_6379.log 
1112:M 24 Mar 00:24:13.174 * Slave 192.168.188.160:6379 asks for synchronization
1112:M 24 Mar 00:24:13.174 * Full resync requested by slave 192.168.188.160:6379
1112:M 24 Mar 00:24:13.174 * Starting BGSAVE for SYNC with target: disk 
1112:M 24 Mar 00:24:13.358 * Background saving started by pid 1663
1663:C 24 Mar 00:24:13.432 * DB saved on disk
1663:C 24 Mar 00:24:13.433 * RDB: 6 MB of memory used by copy-on-write
1112:M 24 Mar 00:24:13.526 * Background saving terminated with success
1112:M 24 Mar 00:24:13.532 * Synchronization with slave 192.168.188.160:6379 succeeded
#出現鏈接的slave端信息後,日誌說明已經配置成功

備端日誌:
[root@redis02 redis]#  tail -8  /opt/redis_cluster/redis_6379/logs/redis_6379.log
2005:C 24 Mar 00:24:13.635 * Parent agreed to stop sending diffs. Finalizing AOF...
2005:C 24 Mar 00:24:13.636 * Concatenating 0.00 MB of AOF diff received from parent.
2005:C 24 Mar 00:24:13.637 * SYNC append only file rewrite performed
2005:C 24 Mar 00:24:13.638 * AOF rewrite: 6 MB of memory used by copy-on-write
1984:S 24 Mar 00:24:13.694 * Background AOF rewrite terminated with success
1984:S 24 Mar 00:24:13.694 * Residual parent diff successfully flushed to the rewritten AOF (0.00 MB)
1984:S 24 Mar 00:24:13.694 * Background AOF rewrite finished successfully
1984:S 24 Mar 00:25:51.481 * SLAVE OF would result into synchronization with the master we are already connected with. No operation performed.
#未檢測到主端的操做記錄,配置成功

5.2.5 主從複製流程

從日誌中看出:
1.從節點發送同步請求到主節點上進行確立同步關係
2.主節點接收到從節點的請求以後,作的相關操做
- 肯定主從關係
- 主節點當即執行bgsave將當前內存裏的持久化數據,保存在硬盤上,用做同步使用.
- 持久化完成以後(DB saved on disk),將持久化數據發送給從節點
3.從節點接收到持久化數據文件以後,作的相關操做
- 清空從節點的自身內存中的數據
- 加載來自主節點的持久化數據到從節點的內存中
- 從庫肯定完成結果,發送給主庫,主庫確認完成
4.肯定完成同步,日後的操做就是主寫入從同步(只讀,不可寫)

5.2.6 總結主從複製

關於同步:
1.配置主從同步的時候 ,須要優先備份主從庫的持久化數據,避免出現問題數據丟失的狀況.
2.開始同步 SLAVEOF 192.168.188.159 6379   	#從庫指定主庫的host和port
3.中止同步 SLAVEOF no one   				#可在從庫配置文件或內存中操做
4.主從同步的時候, 主庫負責寫入,從庫負責接收主庫的信息,且從庫不可寫,只能夠讀.
	如從庫插入數據會報錯 (error) READONLY You can't write against a read only slave.
5.當主節點發生故障後,從節點依舊同步主節點,從節點不會因主掛掉就不一樣步.日誌顯示一直鏈接主.
6.當主發生故障後,從節點操做以下:
	1.修改配置文件的bind指向主節點主機信息
	2.從節點執行中止同步 SLAVEOF no one
7.創建主從同步後,從節點會清空現有數據後,在開始發起同步請求.若是同步錯誤,從庫數據就不復存在.
8.主從同步配置完成後,當主庫有認證登陸的時候,從庫須要配置認證信息,配置文件增長 masterauth 123456

5.2.7 主從複製配置文件

###########1.基礎設定###################################################
#守護進程模式啓動
daemonize yes

#綁定redis監聽的主機IP地址.(當前主機IP地址)
bind 127.0.0.1 192.168.188.159 

#增長密碼認證安全(requirepass password)
#requirepass 123456

#默認redis監聽的端口
port 6379

#Pid文件和Log文件的保存目錄信息
pidfile /opt/redis_cluster/redis_6379/pid/redis_6379.pid
logfile /opt/redis_cluster/redis_6379/logs/redis_6379.log

#設置數據庫的數量,默認數據庫爲0,部署集羣節點只有1個數據庫
databases 16

##############2.主從複製####################################################
#配置主從複製時候,主節點配置文件不添加這行配置; 從節點添加SLAVEOF
#開啓主從複製模式,從同步主的IP+端口
#SLAVEOF 192.168.188.159 6379

############3.本地RDB持久化##################################################
#指定本地持久化文件的文件名,默認是dump.rdb
dbfilename redis_6379.rdb

#本地持久化數據庫存放的目錄
dir /data/redis_cluster/redis_6379/

#設定持久化數據留存條件
#900秒內有1個更改觸發備份
#300秒內有10個更改觸發備份
#60秒內有10000個更改觸發備份
save 900 1
save 300 10
save 60 10000

#############4.本地AOF持久化###################################################
#指定本地持久化文件的文件名,默認是appendonly.aof
appendfilename "redis_6379.aof"

#本地數據庫的目錄
dir /data/redis_cluster/redis_6379/

#開啓AOF持久化數據備份
appendonly yes

#當即緩存到硬盤,並不建議配置.數據直接寫入到硬盤
appendfsync always

#1秒1次的數據寫入到硬盤,官方建議默認的配置
appendfsync everysec

#寫入交給系統負責,操做系統每次同步AOF文件的週期不可控,並且會加大同步硬盤的數據量,雖然提高了性能,可是數據安全性沒法保證.不建議配置
appendfsync no
#########################################################################################

第六章.Redis哨兵(Sentinel )高可用

6.1 哨兵模式(sentinel)的做用

Sentinel介紹

Redis Sentinel是Redis的官方高可用性解決方案 , 使用Sentinel能夠建立Redis部署 ,解決redis單點故障,和主從複製時出現的故障後,不能自動遷移故障 ,有效的監控主從環境的健康狀態,並提供通知故障信息. Sentinel的當前版本稱爲Sentinel 2

具體提供了, 監控, 通知, 自動故障轉移. 配置提供程序; 點擊一下直達Redis Sentinel官方文檔

1.監控(Monitoring) 
Sentinel會按期檢查主從複製的服務器的工做狀態是否運行正常.

2.消息通知(Message notification)
監控主從服務狀態,當其中一臺發生故障後,Sentinel能夠經過API通知系統管理員或其餘計算機程序發送通知

3.自動故障轉移(Automatic failover) 配置提供程序(Configuration provider)
主從複製中,當一個主服務器不能正常工做時， Sentinel會啓動一次故障轉移，它會將失效主服務器的其中一個從服務器升級爲新的主服務器,並讓失效主服務器的其餘從服務器改成複製新的主服務器； 當客戶端試圖鏈接失效的主服務器時,集羣也會向客戶端返回新主服務器的地址,使得集羣可使用新主服務器代替失效服務器

6.2 哨兵模式操做示例

環境主機	角色	端口
192.168.188.159-Redis01	Master/ Sentinel-01	6379/ 26379
192.168.188.160-Redis02	Slave/ Sentinel-02	6379/ 26379
192.168.188.161-Redis03	Slave/ Sentinel-03	6379/ 26379

工做原理就是，當Master宕機的時候，Sentinel會選舉出新的Master，並根據Sentinel中配置的內容，去動態修改VIP(虛擬IP)，將VIP(虛擬IP)指向新的Master。咱們的客戶端就連向指定的VIP便可！

6.2.1 Sentinel環境

1.哨兵是基於主從複製,因此要先配置好主從複製 (159,160,160)
2.每一個redis節點都須要安裝哨兵

快速的配置1臺主從命令集合(基於redis基礎環境)
rsync -avz 192.168.188.159:/opt/* /opt/
mkdir -p /data/redis_cluster/redis_6379/
cd /opt/redis_cluster/redis; make install 
sed -i 's#159#161#g' /opt/redis_cluster/redis_6379/conf/redis_6379.conf
redis-server /opt/redis_cluster/redis_6379/conf/redis_6379.conf
redis-cli -h redis03

2.啓動全部節點
redis-server /opt/redis_cluster/redis_6379/conf/redis_6379.conf

3.開啓全部節點的主從複製
redis-cli -h 192.168.188.159 slaveof 192.168.188.159 6379
redis-cli -h 192.168.188.160 slaveof 192.168.188.159 6379
redis-cli -h 192.168.188.161 slaveof 192.168.188.159 6379

4.檢查登陸查看
[root@redis01 ~]# redis-cli -h redis01
redis01:6379> 
[root@redis02 ~]# redis-cli -h redis02
redis02:6379> 
[root@redis03 ~]# redis-cli - redis03
redis03:6379>

6.2.2 Master操做步驟(159)

1.在Master上配置
#配置哨兵的相關目錄
mkdir -p /data/redis_cluster/redis_26379
mkdir -p /opt/redis_cluster/redis_26379/{conf,pid,logs}

2.增長哨兵的配置文件,三臺機器都須要操做 (159,160,160)
cat >/opt/redis_cluster/redis_26379/conf/redis_26379.conf<< EOF
bind 192.168.188.159
port 26379
daemonize yes
logfile /opt/redis_cluster/redis_26379/logs/redis_26379.log
dir /data/redis_cluster/redis_26379
sentinel monitor myredis 192.168.188.159 6379 2 
sentinel down-after-milliseconds myredis 3000
sentinel parallel-syncs myredis 1
sentinel failover-timeout myredis 18000
EOF

配置文件註釋

sentinel monitor myredis 192.168.188.159 6379 2     
#myredis 主節點的別名  ip 和端口,判斷主節點失敗,至少兩個Sentinel節點參與競選

sentinel down-after-milliseconds myredis 3000 		
#指定Sentinel認爲Master已經掉線須要的毫秒數

sentinel parallel-syncs myredis 1 					
#向新的Master節點發起復制操做的從節點的個數,1 輪詢發起複製,響應複製的個數,完成1個在繼續下1個.

sentinel failover-timeout myredis 18000				
#故障轉移超時時間

6.2.3 Slave操做步驟(160)(161)

redis01操做

rsync -avz /opt/* redis02:/opt/
rsync -avz /opt/* redis03:/opt/

#沒有命令執行 yum install rsync -y

redis02操做

mkdir -p /data/redis_cluster/redis_26379
mkdir -p /opt/redis_cluster/redis_26379/{conf,pid,logs}
cd /opt/redis_cluster/redis
make install 
sed -i '/^bind/c bind 192.168.188.160' /opt/redis_cluster/redis_6379/conf/redis_6379.conf
sed -i '/^bind/c bind 192.168.188.160' /opt/redis_cluster/redis_26379/conf/redis_26379.conf

redis03操做

mkdir -p /data/redis_cluster/redis_26379
mkdir -p /opt/redis_cluster/redis_26379/{conf,pid,logs}
cd /opt/redis_cluster/redis
make install 
sed -i '/^bind/c bind 192.168.188.161' /opt/redis_cluster/redis_6379/conf/redis_6379.conf
sed -i '/^bind/c bind 192.168.188.161' /opt/redis_cluster/redis_26379/conf/redis_26379.conf

6.2.4 配置主從關係

redis02 redis03操做 都須要配置主從關係

#檢查一下主從複製的關係,沒有配置的話增長SLAVEOF參數(只檢查slave2臺)
vim /opt/redis_cluster/redis_6379/conf/redis_6379.conf
SLAVEOF 192.168.188.159 6379

#啓動&檢查
redis-server /opt/redis_cluster/redis_6379/conf/redis_6379.conf
ps -ef |grep redis

#檢查兩臺的日誌 看狀態是否成功
tailf /opt/redis_cluster/redis_6379/logs/redis_6379.log
13862:C 24 Mar 23:04:13.290 * Parent agreed to stop sending diffs. Finalizing AOF...
13862:C 24 Mar 23:04:13.290 * Concatenating 0.00 MB of AOF diff received from parent.
13862:C 24 Mar 23:04:13.290 * SYNC append only file rewrite performed
13862:C 24 Mar 23:04:13.291 * AOF rewrite: 6 MB of memory used by copy-on-write
13832:S 24 Mar 23:04:13.334 * Background AOF rewrite terminated with success
13832:S 24 Mar 23:04:13.334 * Residual parent diff successfully flushed to the rewritten AOF (0.00 MB)
13832:S 24 Mar 23:04:13.334 * Background AOF rewrite finished successfully  #證實配置成功.

6.2.5 啓動哨兵

#3臺都須要操做
redis-sentinel /opt/redis_cluster/redis_26379/conf/redis_26379.conf
ps -ef |grep redis
[root@redis03 redis]# ps -ef |grep redis   
root       2854      1  0 15:45 ?        00:00:45 redis-server 127.0.0.1:6379
root       4081      1  0 22:05 ?        00:00:05 redis-sentinel 192.168.188.161:26379 [sentinel]
root       4279   1922  0 22:34 pts/1    00:00:00 grep --color=auto redis

#測試檢查一下哨兵日誌,是否能夠識別到slave; 共計3臺作的一主兩從,每臺上面都會有另外2臺的信息.
[root@redis01 conf]# tail /opt/redis_cluster/redis_26379/logs/redis_26379.log 
4336:X 24 Mar 23:05:18.327 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
4336:X 24 Mar 23:05:18.332 # Sentinel ID is f9e2ef6e47f9e510f076ac04a98012b39f5439a8
4336:X 24 Mar 23:05:18.332 # +monitor master myredis 192.168.188.159 6379 quorum 2
4336:X 24 Mar 23:05:18.332 * +slave slave 192.168.188.161:6379 192.168.188.161 6379 @ myredis 192.168.188.159 6379
4336:X 24 Mar 23:05:18.336 * +slave slave 192.168.188.160:6379 192.168.188.160 6379 @ myredis 192.168.188.159 6379
4336:X 24 Mar 23:05:24.940 * +sentinel sentinel 464edc58a7480062b123a7ff427a1d2e95573d4a 192.168.188.160 26379 @ myredis 192.168.188.159 6379
4336:X 24 Mar 23:05:28.073 * +sentinel sentinel c39a54f22ad1ca5aeed7a6cc1afa2e4281ef9f17 192.168.188.161 26379 @ myredis 192.168.188.159 6379

6.2.6 對比配置文件

配置前

bind 192.168.188.159
port 26379
daemonize yes
logfile /opt/redis_cluster/redis_26379/logs/redis_26379.log
dir /data/redis_cluster/redis_26379
sentinel monitor myredis 192.168.188.159 6379 2 
sentinel down-after-milliseconds myredis 3000
sentinel parallel-syncs myredis 1
sentinel failover-timeout myredis 18000

啓動後

[root@redis01 conf]# cat /opt/redis_cluster/redis_26379/conf/redis_26379.conf  
bind 192.168.188.159
port 26379
daemonize yes
logfile "/opt/redis_cluster/redis_26379/logs/redis_26379.log"
dir "/data/redis_cluster/redis_26379"
sentinel myid f9e2ef6e47f9e510f076ac04a98012b39f5439a8     #啓動後新增的ID,每臺都有
sentinel monitor myredis 192.168.188.159 6379 2			   
sentinel down-after-milliseconds myredis 3000
sentinel failover-timeout myredis 18000
# Generated by CONFIG REWRITE     							#如下也是啓動後增長的信息
sentinel config-epoch myredis 0
sentinel leader-epoch myredis 0
sentinel known-slave myredis 192.168.188.160 6379
sentinel known-slave myredis 192.168.188.161 6379
sentinel known-sentinel myredis 192.168.188.161 26379 c39a54f22ad1ca5aeed7a6cc1afa2e4281ef9f17
sentinel known-sentinel myredis 192.168.188.160 26379 464edc58a7480062b123a7ff427a1d2e95573d4a
sentinel current-epoch 0

經過查看日誌和配置文件,能夠看出1主2從的環境配置完成.

6.2.7 哨兵配置文件

###############1.哨兵模式配置參數###################################################
#守護進程模式啓動
daemonize yes

#綁定redis監聽的主機IP地址.(當前主機IP地址)
bind 192.168.188.159 

#默認redis監聽的端口
port 26379

#Log文件的保存目錄信息
logfile /opt/redis_cluster/redis_26379/logs/redis_26379.log

#數據的保存目錄,記住哨兵模式不記錄數據,只複製自動故障轉移,消息通知,監控
dir /data/redis_cluster/redis_26379

#myredis主節點的別名;  ip+端口,判斷主節點故障後,至少兩個Sentinel節點參與競選,1主2從模式
sentinel monitor myredis 192.168.188.159 6379 2 

#指定Sentinel認爲Master已經節點掉線在3000毫秒後進行其餘節點競選master的毫秒數
sentinel down-after-milliseconds myredis 3000

#當master服務掛掉後, 從節點競選爲master後,須要同步數據時候,是1臺1臺的同步 ,完成後在同步另外1臺 ; 1 表示輪詢複製
sentinel parallel-syncs myredis 1

#自動故障轉移超時時間
sentinel failover-timeout myredis 18000
#########################################################################################

6.3 哨兵經常使用的命令 API

登陸命令: 
[root@redis01 conf]# redis-cli -h redis01 -p 26379
redis01:26379> 
-p 指定登陸到哨兵,默認是6379

INFO Sentinel   					 #查看當前哨兵的信息							
Sentinel masters					 #查看Master具體的信息
Sentinel master <master name> 		 #指定查看各節點master信息
Sentinel slaves <master name>        #查看從節點信息,會顯示2臺從節點信息狀態   
Sentinel sentinels <master name>     #顯示哨兵組信息
Sentinel get-master-addr-by-name <master name>  #顯示當前的master節點主機和端口
Sentinel failover <master name>  	 #查看自動故障轉移狀態,手動故障轉移
Sentinel flushconfig                 #刷新哨兵配置

6.4 案例一.Master故障,自動轉移

模擬master節點掛掉.

在哨兵模式下,怎麼樣纔會出現故障?

須要知道的是,哨兵模式下,這裏配置的是一主兩從,當主節點掛掉以後, 從的2個節點自動開始故障轉移,開始競選,在2個之中競選出來一個主 ,以後從同步競選後主的持久化數據; 那麼當原來的主修覆上線後,在哨兵內發現本身已經不是原來的主節點的了 ,通過消息共享後,已經競選的主告知修復原來是主節點,你已經不是主了,你要同步個人數據,便開始同步了.文字說明太模糊了,看下草圖,瞭解下.

操做示例:

1.master操做:
[root@redis01 ~]# pkill redis

2.slave (160)觀察日誌
#master節點宕機了.
12114:X 26 Mar 09:13:26.777 # +sdown master myredis 192.168.188.159 6379
12114:X 26 Mar 09:13:26.777 # +sdown sentinel eb8dfb48987a37637c62606d0bd88455244c9793 192.168.188.159 26379 @ myredis 192.168.188.159 6379
12114:X 26 Mar 09:13:26.861 # +odown master myredis 192.168.188.159 6379 #quorum 2/2
12114:X 26 Mar 09:13:26.861 # +new-epoch 1
12114:X 26 Mar 09:13:26.862 # +try-failover master myredis 192.168.188.159 6379
12114:X 26 Mar 09:13:26.864 # +vote-for-leader 75c70a0d58755223e74b9cbb2b7a28172c197744 1
12114:X 26 Mar 09:13:26.875 # 360a6a89bc576b150f00e967479851bc8a29c795 voted for 75c70a0d58755223e74b9cbb2b7a28172c197744 1
12114:X 26 Mar 09:13:26.921 # +elected-leader master myredis 192.168.188.159 6379
12114:X 26 Mar 09:13:26.921 # +failover-state-select-slave master myredis 192.168.188.159 6379
#開始故障轉移
12114:X 26 Mar 09:13:27.005 # +selected-slave slave 192.168.188.160:6379 192.168.188.160 6379 @ myredis 192.168.188.159 6379
12114:X 26 Mar 09:13:27.005 * +failover-state-send-slaveof-noone slave 192.168.188.160:6379 192.168.188.160 6379 @ myredis 192.168.188.159 6379
12114:X 26 Mar 09:13:27.071 * +failover-state-wait-promotion slave 192.168.188.160:6379 192.168.188.160 6379 @ myredis 192.168.188.159 6379
12114:X 26 Mar 09:13:27.886 # +promoted-slave slave 192.168.188.160:6379 192.168.188.160 6379 @ myredis 192.168.188.159 6379
12114:X 26 Mar 09:13:27.888 # +failover-state-reconf-slaves master myredis 192.168.188.159 6379
12114:X 26 Mar 09:13:27.947 * +slave-reconf-sent slave 192.168.188.161:6379 192.168.188.161 6379 @ myredis 192.168.188.159 6379
12114:X 26 Mar 09:13:28.893 * +slave-reconf-inprog slave 192.168.188.161:6379 192.168.188.161 6379 @ myredis 192.168.188.159 6379
12114:X 26 Mar 09:13:28.893 * +slave-reconf-done slave 192.168.188.161:6379 192.168.188.161 6379 @ myredis 192.168.188.159 6379
12114:X 26 Mar 09:13:28.955 # -odown master myredis 192.168.188.159 6379
12114:X 26 Mar 09:13:28.955 # +failover-end master myredis 192.168.188.159 6379
#轉移確立完成
12114:X 26 Mar 09:13:28.956 # +switch-master myredis 192.168.188.159 6379 192.168.188.160 6379
#通告最新主節點
12114:X 26 Mar 09:13:28.956 * +slave slave 192.168.188.161:6379 192.168.188.161 6379 @ myredis 192.168.188.160 6379
12114:X 26 Mar 09:13:28.957 * +slave slave 192.168.188.159:6379 192.168.188.159 6379 @ myredis 192.168.188.160 6379
12114:X 26 Mar 09:13:31.992 # +sdown slave 192.168.188.159:6379 192.168.188.159 6379 @ myredis 192.168.188.160 6379

3. slave(161)日誌
12138:X 26 Mar 09:13:26.731 # +sdown sentinel eb8dfb48987a37637c62606d0bd88455244c9793 192.168.188.159 26379 @ myredis 192.168.188.159 6379
12138:X 26 Mar 09:13:26.798 # +sdown master myredis 192.168.188.159 6379
12138:X 26 Mar 09:13:26.899 # +new-epoch 1
12138:X 26 Mar 09:13:26.903 # +vote-for-leader 75c70a0d58755223e74b9cbb2b7a28172c197744 1
12138:X 26 Mar 09:13:27.941 # +odown master myredis 192.168.188.159 6379 #quorum 2/2
12138:X 26 Mar 09:13:27.942 # Next failover delay: I will not start a failover before Thu Mar 26 09:14:03 2020
12138:X 26 Mar 09:13:27.979 # +config-update-from sentinel 75c70a0d58755223e74b9cbb2b7a28172c197744 192.168.188.160 26379 @ myredis 192.168.188.159 6379
#收到最新主節點後,同步最新節點
12138:X 26 Mar 09:13:27.980 # +switch-master myredis 192.168.188.159 6379 192.168.188.160 6379
12138:X 26 Mar 09:13:27.980 * +slave slave 192.168.188.161:6379 192.168.188.161 6379 @ myredis 192.168.188.160 6379
12138:X 26 Mar 09:13:27.981 * +slave slave 192.168.188.159:6379 192.168.188.159 6379 @ myredis 192.168.188.160 6379
12138:X 26 Mar 09:13:30.986 # +sdown slave 192.168.188.159:6379 192.168.188.159 6379 @ myredis 192.168.188.160 6379

存在的不足:
1.主從切換的過程當中會丟數據
2.Redis只能單點寫，不能水平擴容

6.5 案例二.Master故障主機上線

其實在自動轉移的是,從節點競選是根據權重id的大小,開始競選; 手動故障轉移是將權重 ID 調大,從節點權重ID調小,這樣的話就能實現手動故障轉移 .並上線!

權重的概念.

3臺ID均爲 0 的時候,公平競選; 當master節點爲2的時候,master節點便優先競選爲主; 從2個節點的權重ID是0,  即是從節點了.

設定權重命令.slave-priority

CONFIG GET slave-priority           		#查看當前主從複製權重值.優先級
CONFIG SET slave-priority 0 		        #設定優先級,權重
sentinel failover myredis                   #手動哨兵故障轉移

例如: 159 Master節點修復完成l,準備上線 ,仍是繼續作主節點,操做以下:

第一步: 恢復主master159上線

1.159master恢復上線:
[root@redis01 ~]# redis-se /opt/redis_cluster/redis_26379/conf/redis_26379.conf
[root@redis01 ~]# redis-sentinel /opt/redis_cluster/redis_26379/conf/redis_26379.conf

2. 從節點的日誌信息.
[root@redis02 redis]# tail /opt/redis_cluster/redis_26379/logs/redis_26379.log
12114:X 26 Mar 09:27:07.825 # -sdown slave 192.168.188.159:6379 192.168.188.159 6379 @ myredis 192.168.188.160 6379
12114:X 26 Mar 09:27:17.815 * +convert-to-slave slave 192.168.188.159:6379 192.168.188.159 6379 @ myredis 192.168.188.160 6379
12114:X 26 Mar 09:27:20.751 # -sdown sentinel eb8dfb48987a37637c62606d0bd88455244c9793 192.168.188.159 26379 @ myredis 192.168.188.160 6379
#日誌能夠看出,原來的master主,已經不是主了, 須要同步最新的主的節點是  160.

3.原來的master上線檢查,當前最新的主是誰
[root@redis01 ~]# redis-cli -h redis01 -p 26379
redis01:26379> Sentinel get-master-addr-by-name myredis
1) "192.168.188.160"
2) "6379"
#看到最新的主是 160,那麼我即熱已經恢復 ,我仍是繼續作主吧

第二步: 設定優先級,調整權重

1.查看當前3臺的環境的優先級
[root@redis01 ~]# redis-cli -h redis01 -p 6379 CONFIG GET slave-priority
1) "slave-priority"
2) "100"
[root@redis01 ~]# redis-cli -h redis02 -p 6379 CONFIG GET slave-priority
1) "slave-priority"
2) "100"
[root@redis01 ~]# redis-cli -h redis03 -p 6379 CONFIG GET slave-priority
1) "slave-priority"
2) "100"
#發現全都是100的權重.
	設定權重:
		1.能夠將兩個從節點均都設定爲0,這樣的master159,變優先晉升爲主
		2.權重不宜設定超過100的值

2.設定2個從節點爲0
[root@redis01 ~]# redis-cli -h redis02 -p 6379 CONFIG SET slave-priority 0 
OK
[root@redis01 ~]# redis-cli -h redis03 -p 6379 CONFIG SET slave-priority 0 
OK

第三步: 強制設定故障轉移

1.故障轉移須要在哨兵內執行.
[root@redis01 ~]# redis-cli -h redis01 -p 26379
redis01:26379> sentinel failover myredis
OK

2.查看從節點日誌160
12114:X 26 Mar 09:56:31.646 # +new-epoch 2
12114:X 26 Mar 09:56:31.925 # +config-update-from sentinel eb8dfb48987a37637c62606d0bd88455244c9793 192.168.188.159 26379 @ myredis 192.168.188.160 6379
12114:X 26 Mar 09:56:31.926 # +switch-master myredis 192.168.188.160 6379 192.168.188.159 6379
12114:X 26 Mar 09:56:31.927 * +slave slave 192.168.188.161:6379 192.168.188.161 6379 @ myredis 192.168.188.159 6379
12114:X 26 Mar 09:56:31.927 * +slave slave 192.168.188.160:6379 192.168.188.160 6379 @ myredis 192.168.188.159 6379
12114:X 26 Mar 09:56:41.983 * +convert-to-slave slave 192.168.188.160:6379 192.168.188.160 6379 @ myredis 192.168.188.159 6379

3.查看從節點日誌161
12138:X 26 Mar 09:56:31.708 # +new-epoch 2
12138:X 26 Mar 09:56:31.989 # +config-update-from sentinel eb8dfb48987a37637c62606d0bd88455244c9793 192.168.188.159 26379 @ myredis 192.168.188.160 6379
12138:X 26 Mar 09:56:31.989 # +switch-master myredis 192.168.188.160 6379 192.168.188.159 6379
12138:X 26 Mar 09:56:31.990 * +slave slave 192.168.188.161:6379 192.168.188.161 6379 @ myredis 192.168.188.159 6379
12138:X 26 Mar 09:56:31.991 * +slave slave 192.168.188.160:6379 192.168.188.160 6379 @ myredis 192.168.188.159 6379

4.哨兵模式內查看,當前組的成員的信息
redis01:26379> Sentinel get-master-addr-by-name myredis
1) "192.168.188.159"
2) "6379"
#日誌中和哨兵中均可以看出,如今的159又晉升爲主節點了.這樣就完成了,故障修復後上線,晉升主恢復.

第四步: 恢復從的2個節點優先級

爲何要恢復呢? 避免當master159.發生故障後,2臺從節點沒法開始競選,產生故障
1.恢復設定原來默認值:
[root@redis01 ~]# redis-cli -h redis02 -p 6379 CONFIG SET slave-priority 100
OK
[root@redis01 ~]# redis-cli -h redis03 -p 6379 CONFIG SET slave-priority 100
OK

2.查看最新優先級
[root@redis01 ~]# redis-cli -h redis02 -p 6379 CONFIG GET slave-priority 
1) "slave-priority"
2) "100"
[root@redis01 ~]# redis-cli -h redis03 -p 6379 CONFIG GET slave-priority 
1) "slave-priority"
2) "100"
[root@redis01 ~]# redis-cli -h redis01 -p 6379 CONFIG GET slave-priority 
1) "slave-priority"
2) "100"