redis主從複製,讀寫分離以及哨兵的配置
阿新 • • 發佈：2018-12-22
1.Redis主從配置
1.1：安裝redis 具體教程可以看我安裝redis-cluster部落格中的內容,這裡就不再重寫一遍了。
1.2：在/usr/local/目錄下建立redis-jiqun資料夾
mkdir /usr/local/redis-jiqun1.3：拷貝三份redis到剛才建立的redis-jiqun目錄下
cp -r /usr/local/redis /usr/local/redis-jiqun/redis01
cp -r /usr/local/redis /usr/local/redis-jiqun/redis02
cp -r /usr/local/redis /usr/local/redis-jiqun/redis031.4：修改每一個redis的bin目錄下的redis.conf
bind 192.168.1.103 #修改為自己對應的伺服器ip
port 6379 #依次修改為 6379 6380 6381埠
pidfile /var/run/redis_6379.pid #依次修改為其對應的埠號1.5：設定主從
修改redis.conf檔案,這裡將6379埠設定為master所以不需要做任何操作,只需要修改6380埠和6381埠就可以了slaveof 192.168.1.103 6379
1.6：啟動3個redis節點
cd /usr/local/redis-jiqun/redis01/bin &&./redis-server redis.conf cd /usr/local/redis-jiqun/redis02/bin &&./redis-server redis.conf cd /usr/local/redis-jiqun/redis03/bin &&./redis-server redis.conf
1.7：連線redis的master節點,檢視主從狀態
[[email protected] 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
1.8：測試主備是否好用
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)、先在redis根目錄下建立conf子目錄，新建配置檔案sentinel.conf，或者拷貝解壓的redis原始檔的根目錄下有sentinel.conf，內容如下port 26379
dir /tmp
sentinel monitor master 192.168.1.103 6379 1
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啟動哨兵
方式一：redis-sentinel /path/to/sentinel.conf & (推薦，這種方式啟動和redis例項沒有任何關係，後面加&可以在後臺啟動,關閉ssh視窗依然會在後臺執行)方式二：redis-server /path/to/sentinel.conf --sentinel
3.5測試master宕機
1861:X 13 May 04:14:39.549 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.1861:X 13 May 04:14:39.585 # Sentinel ID is 6de45c32109f5cf472c3130c38a537188d352c12
1861:X 13 May 04:14:39.585 # +monitor master master 192.168.1.103 6379 quorum 1
1861:X 13 May 04:14:39.588 * +slave slave 192.168.1.103:6380 192.168.1.103 6380 @ master 192.168.1.103 6379
1861:X 13 May 04:14:39.591 * +slave slave 192.168.1.103:6381 192.168.1.103 6381 @ master 192.168.1.103 6379
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 # +odown master master 192.168.1.103 6379 #quorum 1/1
1861:X 13 May 04:16:15.632 # +new-epoch 1
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，現在就一個哨兵所以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.243 # +switch-master master 192.168.1.103 6379 192.168.1.103 6380 #主資料庫從6379轉變為6380
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的從庫
1861:X 13 May 04:16:18.244 * +slave slave 192.168.1.103:6379 192.168.1.103 6379 @ master 192.168.1.103 6380 #新增6379為6380的從庫
1861:X 13 May 04:16:48.246 # +sdown slave 192.168.1.103:6379 192.168.1.103 6379 @ master 192.168.1.103 6380 #這裡檢測6379還是宕機狀態
1861:X 13 May 04:28:34.252 # -sdown slave 192.168.1.103:6379 192.168.1.103 6379 @ master 192.168.1.103 6380 #這裡檢測6379還是宕機狀態
1861:X 13 May 04:28:44.196 * +convert-to-slave slave 192.168.1.103:6379 192.168.1.103 6379 @ master 192.168.1.103 6380 #顯示6379重新啟動了,並作為6380slave