redis4.x 主從複製(讀寫分離)
基於Redis版本: redis-4.0.11
主從複製
▶ 避免redis單點故障
▶ 構建讀寫分離架構,滿足讀多寫少的應用場景
主從架構
一:下載 、安裝
解壓、複製:
tar -zxvf redis-4.0.11.tar.gz #解壓
mv redis-4.0.11/ redis6379 #重新命名
cp -r redis6379/ redis6380 #複製
cp -r redis6379/ redis6381 #複製
編譯:
cd redis6379 #進入目錄 make #編譯 cp src/redis-cli ./ #複製命令 (這兩步可以省略,只為了操作起來方便) cp src/redis-server ./ #複製命令
redis6380、redis6381執行同樣的編譯操作
二:修改redis.conf
redis6379/redis.conf
port 6379 # 埠
pidfile /var/run/redis_6379.pid # pid檔案位置
daemonize yes # 開啟支援後臺啟動
redis6380/redis.conf
port 6380 # 埠 pidfile /var/run/redis_6380.pid # pid檔案位置 daemonize yes # 開啟支援後臺啟動
redis6381/redis.conf
port 6381 # 埠
pidfile /var/run/redis_6381.pid # pid檔案位置
daemonize yes # 開啟支援後臺啟動
三:設定主從
在redis中設定主從有2種方式
▶ 在從redis服務的redis.conf中設定 slaveof <masterip> <masterport>
配置 6380 和 6381 的redis.conf
▶ 使用redis-cli客戶端連線到從redis服務,執行slaveof命令 slaveof <masterip> <masterport>
連線 6380 和 6381 的客戶端
tip:第二種方式是一次性的,在重啟後將失去主從複製關係。
啟動redis
redis6379/redis-server redis6379/redis.conf
redis6380/redis-server redis6380/redis.conf
redis6381/redis-server redis6381/redis.conf
連線客戶端,檢視主從資訊:INFO replication
主:
從:
四:讀寫分離
在主庫寫入資料:
在從庫讀取資料:
tip:預設情況下,redis資料庫充當slave角色時是隻讀的不能進行寫操作。
開啟slave非只讀:slave-read-only no
主從複製過程
1:當從庫和主庫建立MS(主從)關係後,會向主資料庫傳送SYNC(同步)命令;
2:主庫接收到SYNC命令後會開始在後臺儲存快照(RDB持久化過程),並將期間接收到的寫命令快取起來;
3:當快照完成後,主Redis會將快照檔案和所有快取的寫命令傳送給從Redis;
4:從Redis接收到後,會載入快照檔案並且執行收到的快取的命令;
5:之後,主Redis每當接收到寫命令時就會將命令傳送從Redis,從而保證資料的一致;
五:主從架構中出現宕機怎麼辦
如果在主從複製架構中出現宕機的情況,需要分情況看:
● 從Redis宕機
策略:重新啟動從資料庫,會自動加入到主從架構中,自動完成同步資料;
● 主Redis宕機
第一步,在從資料庫中執行SLAVEOF NO ONE命令,斷開主從關係並且提升為主庫繼續服務;
第二步,將主庫重新啟動後,執行SLAVEOF命令,將其設定為其他庫的從庫,這時資料就能更新回來;
主資料庫宕機後的手動完成恢復的過程其實是比較麻煩的並且容易出錯,有沒有好辦法解決呢?當前有的,Redis提供的哨兵(sentinel)的功能。
六:redis哨兵
1:哨兵是什麼?
哨兵的作用就是對Redis的系統的執行情況的監控,它是一個獨立程序
2:哨兵的作用?
監控(Monitoring): 哨兵(sentinel) 會不斷地檢查你的Master和Slave是否運作正常。
· 提醒(Notification):當被監控的某個 Redis出現問題時, 哨兵(sentinel) 可以通過 API 向管理員或者其他應用程式傳送通知。
· 自動故障遷移(Automatic failover):當一個Master不能正常工作時,哨兵(sentinel) 會開始一次自動故障遷移操作,它會將失效Master的其中一個Slave升級為新的Master, 並讓失效Master的其他Slave改為複製新的Master; 當客戶端試圖連線失效的Master時,叢集也會向客戶端返回新Master的地址,使得叢集可以使用Master代替失效Master。
哨兵(sentinel) 是一個分散式系統,你可以在一個架構中執行多個哨兵(sentinel) 程序,這些程序使用流言協議(gossipprotocols)來接收關於Master是否下線的資訊,並使用投票協議(agreement protocols)來決定是否執行自動故障遷移,以及選擇哪個Slave作為新的Master.
單哨兵監控
配置單哨兵監控
1:修改哨兵檔案 sentinel.conf
vim redis6379/sentinel.conf
2:修改內容
mymaster:監控主資料的名稱,支援自定義
127.0.0.1:監控的主資料庫的IP
6379:監控的主資料庫的埠
1:最低通過票數
:
3:啟動哨兵程序:
cd redis6379/ #進去redis安裝目錄
cp src/redis-sentinel ./ #複製哨兵服務啟動命令
./redis-sentinel sentinel.conf #啟動哨兵服務
由上圖可以看到:
1:哨兵已經啟動,它的id為0e786aa868334de731814accecb107a35c0a5320
2:為master資料庫添加了一個監控
3:發現了2個slave(由此可以看出,哨兵無需配置slave,只需要指定master,哨兵會自動發現slave)
測試從庫宕機
檢視哨兵控制檯輸出
+sdown:服務宕機,說明哨兵監控到slave宕機了,那麼,如果我們將宕機的slave服務重啟後,會自動加入到主從複製嗎?
重新啟動後,檢視哨兵控制檯輸出
-sdown:服務恢復,可以看出slave重新加入了主從架構中
測試主庫宕機
檢視哨兵控制檯輸出
連線6381檢視狀態
可以看出,目前,6381位master,擁有一個slave為6380.
接下來,我們恢復6379檢視哨兵控制檯輸出:
測試發現:主庫宕機後,會將一個從庫選為主,當宕機的主庫重新連線時,也只能作為新主庫的小弟了。
配置多個哨兵
配置了一個哨兵,如果該哨兵宕機了,那麼整個主從架構就回復到了原始的情況,所以我們可以配置多個哨兵,每個哨兵監控Redis資訊,並且哨兵之間也會互相監控。哨兵也具有類似zookeeper的選舉機制,所以測試配置三個哨兵。
修改sentinel.conf
vim redis6379/sentinel.conf
設定最低通過票數為 2,並且設定哨兵服務支援後臺啟動
複製兩份哨兵檔案
cp sentinel.conf sentinel_1.conf
cp sentinel.conf sentinel_2.conf
修改sentinel_1.conf、sentinel_1.conf的port
啟動哨兵
./redis-sentinel sentinel.conf
./redis-sentinel sentinel_1.conf
./redis-sentinel sentinel_2.conf
效果測試和一個哨兵差不多。有興趣的自己去玩一下。