Redis篇6-replication主從複製與哨兵模式

概述

官方說明：https://redis.io/topics/replication
做用：讀（Slave）寫（Master）分離，容災恢復
哨兵模式能夠實現無人值守
缺點：主從複製無疑會帶來延遲（Master機器同步到Slave機器），使用哨兵模式則延遲會更明顯。

測試配置準備（一臺主機兩臺備機）

拷貝多個配置文件分別命名區分 redis{port}.confredis

Master 端口6379
Slave1 端口6380
Slave2 端口6381
其餘方便區別配置
- 使用後臺方式啓動服務 daemonize yes
- pidfile redis{port}.pid
- logfile redis{port}.log
- dbfilename dump{port}.rdb

測試1 Master<Slave1, Slave2

分別啓動並鏈接上三個服務

redis-server redis{port}.conf
ps -ef|grep redis|grep -v grep
redis-cli -p {port}

客戶端分別查看主從複製的信息 info replication

# Replication
role:master
connected_slaves:0
master_replid:d3d1de9a393d82c4dc1787800471fffba1323b3a
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

開始數據主從複製
- Master
```
set k1 v1
set k2 v2
```
- Slave1和Slave2
```
get k1
slaveof 127.0.0.1 6379
get k1
get k2
```
- 能夠看到Slave已經把Master的數據複製過來了
- Master繼續設置KV，驗證Slave數據同步
- 再次查看主從複製信息 info replication 能夠看到匹配的信息
- Slave上進行寫操做則會報錯
  (error) READONLY You can't write against a read only replica.
將Master shutdown，Slave不動
- Slave查看 info replication
- 能夠看到Slave數據依然在，且與Master的關係還在
- 當Master從新啓動，主從關係恢復如初
將Slave1 shutdown，Master不動
- Slave2的主從關係不會有變化
- Slave1從新啓動後，主從關係消失了，須要從新 slaveof 127.0.0.1 6379 進行數據同步
- 若是但願Slave掛/斷掉重啓後「再續前緣」，需進行Slave-server的配置 replicaof 127.0.0.1 6379

測試2 Master<Slave1<Slave2（Slave1是Slave2的Master）

上一個Slave能夠是下一個Slave的Master，這樣能夠分擔Master的寫壓力
Slave2改變Master：slaveof 127.0.0.1 6380
查看Slave1的主從信息變化：info replication
目前從總體上看，數據完整性和以前「一主二僕」模式是同樣的，只是如今Slave2是從Slave1同步數據，變成「薪火相傳」模式，那麼Slave1怎麼分擔Master的壓力？繼續操做..
將Master shutdown，模擬Master機器掛掉了，此時能夠對Slave1 slaveof no one，讓Slave1「反客爲主」新的Master（role有Slave變成Master），這樣就能夠對其進行寫操做，並和Slave2繼續主從關係
此時，原Master服務重啓恢復，將成爲單獨的Master服務，被原Slave一、Slave2孤立在外。
而後，將Slave1從新掛給Master，恢復最原始的「一主二僕」關係，會發現Slave1和Slave2在Slave1「反客爲主」時期寫的數據消失了，而變成了Master的數據。由此可知Slave變動Master後，Slave的數據會先清空，而後同步爲新的Master的數據

哨兵（sentinel）模式

說明

前面的測試中，當Master掛掉，還須要人爲的將某個Slave轉換爲Master，而實際上機器掛掉可能發生在任意時刻，好比凌晨，因此不能依靠人爲處理。
哨兵模式彌補了上面的缺點，達到所謂「無人值守」的效果。
效果1：使用哨兵模式，會另啓動一個進程，對Master進行監控，若是監控到Master故障，則根據投票機制自動將某個Slave升級爲新的Master（查看sentinel日誌能夠看到投票細節）。
效果2：哨兵模式將Slave1升級爲Master後，若是原Master恢復，哨兵監控到後，會自動把原Master降級掛給Slave1，主從關係徹底變動。

配置與測試

恢復「一主二僕」模式，一個Master（79），兩個Slave（80、81）
新建sentinel配置文件 vi sentinel.conf，內容：
```
sentinel monitor master6379 127.0.0.1 6379 1
```
說明：
- sentinel monitor ... 指示sentinel監聽後面機器上的Master
- master6379 給後面要監聽的Master取個名字
- 127.0.0.1 6379 監聽目標Master服務的ip和端口
- 最後的數字m=1表示sentinel投票數，即當有n個sentinel（sentinel集羣）認爲這個Master掛了時，纔會認爲它真的掛了，而後進行故障遷移動做。這裏是單機測試，因此n直接設置爲1。
- 能夠新行，監聽多個主機Master

啓動哨兵

redis-sentinel sentinel.conf 
或者
redis-server sentinel.conf --sentinel

啓動後能夠看到日誌：

# Sentinel ID is 89568e210930ec9fe58e4cf856a5ef8e14501955
# +monitor master master6379 127.0.0.1 6379 quorum 1
* +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ master6379 127.0.0.1 6379
* +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ master6379 127.0.0.1 6379

將Master shutdown，觀察哨兵日誌

# +sdown master master6379 127.0.0.1 6379
# +odown master master6379 127.0.0.1 6379 #quorum 1/1
# +new-epoch 1
# +try-failover master master6379 127.0.0.1 6379
# +vote-for-leader 89568e210930ec9fe58e4cf856a5ef8e14501955 1
# +elected-leader master master6379 127.0.0.1 6379
# +failover-state-select-slave master master6379 127.0.0.1 6379
# +selected-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ master6379 127.0.0.1 6379
* +failover-state-send-slaveof-noone slave 127.0.0.1:6380 127.0.0.1 6380 @ master6379 127.0.0.1 6379
* +failover-state-wait-promotion slave 127.0.0.1:6380 127.0.0.1 6380 @ master6379 127.0.0.1 6379
# +promoted-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ master6379 127.0.0.1 6379
# +failover-state-reconf-slaves master master6379 127.0.0.1 6379
* +slave-reconf-sent slave 127.0.0.1:6381 127.0.0.1 6381 @ master6379 127.0.0.1 6379
* +slave-reconf-inprog slave 127.0.0.1:6381 127.0.0.1 6381 @ master6379 127.0.0.1 6379
* +slave-reconf-done slave 127.0.0.1:6381 127.0.0.1 6381 @ master6379 127.0.0.1 6379
# +failover-end master master6379 127.0.0.1 6379
# +switch-master master6379 127.0.0.1 6379 127.0.0.1 6380
* +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ master6379 127.0.0.1 6380
* +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ master6379 127.0.0.1 6380
# +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ master6379 127.0.0.1 6380

能夠看出，哨兵監控到79Master掛掉了，而後投票肯定，而後從新選舉80爲新的Master。

查看原Slave的主從信息，能夠看出80Slave的role變成了Master
重啓79Master，查看哨兵日誌和主從關係
```
* +convert-to-slave slave 127.0.0.1:6379 127.0.0.1 6379 @ master6379 127.0.0.1 6380
```
從日誌也能看出，哨兵對79進行了convert-to-slave操做