Redis 主從配置心得及其高可用方案

z_vv 8年前發布 | 28K 次閱讀 Redis NoSQL數據庫

redis主從復制過程：

當配置好slave后，slave與master建立連接，然后發送sync命令。無論是第一次連接還是重新連接，master都會啟動一個后臺進程，將數據庫快照保存到文件中，同時master主進程會開始收集新的寫命令并緩存。后臺進程完成寫文件后，master就發送文件給slave，slave將文件保存到硬盤上，再加載到內存中，接著master就會把緩存的命令轉發給slave，后續master將收到的寫命令發送給slave。

如果master同時收到多個slave發來的同步連接命令，master只會啟動一個進程來寫數據庫鏡像，然后發送給所有的slave。master同步數據時是非阻塞式的，可以接收用戶的讀寫請求。然而在slave端是阻塞模式的，slave在同步master數據時，并不能夠響應客戶端的查詢。

可以在master禁用數據持久化，只需要注釋掉master 配置文件中的所有save配置，然后只在slave上配置數據持久化

擁有主從服務器的好處（從服務器是只讀的，可以一主多從）

1. 主服務器進行讀寫時，會轉移到從讀，減輕服務器壓力

2. 熱備份主從都可以設置密碼，也可以密碼不一致

進入/usr/data/redis/slave

創建 master slave1 slave2

1.復制redis.conf到3個目錄，修改端口 1000，2000，3000

2.修改pid路徑，日志路徑

pidfile /usr/data/redis/slave/master/redis.pid

logfile /usr/data/redis/slave/master/redis.log

ps -ef | grep redis

root 19000 1 0 08:27 ? 00:00:00 redis-server 192.168.1.1:1000

root 19012 1 0 08:27 ? 00:00:00 redis-server 192.168.1.1:2000

root 19016 1 0 08:27 ? 00:00:00 redis-server 192.168.1.1:3000

連接客戶端

[root@iZ23pv5rps8Z ~]# redis-cli -h 192.168.1.1 -p 3000

查看權限

192.168.1.1:3000> info

3臺服務器都是 # Replication role:master

設置從服務器方式

1.命令方式

# Replication

role:master

connected_slaves:2

slave0:ip=192.168.1.1,port=2000,state=online,offset=113,lag=0

slave1:ip=192.168.1.1,port=3000,state=online,offset=113,lag=0

master_repl_offset:113

# Replication

role:slave

master_host:192.168.1.1

master_port:1000

master_link_status:up

服務器停止，主從就不起作用

2.配置文件

# slaveof

slaveof 192.168.1.1 1000

服務器停止，主從依然起作用

主從同步，2者密碼可以不一致

192.168.1.1:1000> setlyg945liuyonggang
192.168.1.1:1000> getlyg945
"liuyonggang"
 
192.168.1.1:2000> getlyg945
"liuyonggang"
 
192.168.1.1:3000> getlyg945
"liuyonggang"

Redis的主從架構，如果master發現故障了，還得手動將slave切換成master繼續服務，手動的方式容易造成失誤，導致數據丟失，那Redis有沒有一種機制可以在master和slave進行監控，并在master發送故障的時候，能自動將slave切換成master呢？有的，那就是哨兵。

哨兵的作用：

1、監控redis進行狀態，包括master和slave

2、當master down機，能自動將slave切換成master

下面配置哨兵監控redis進程，假如我們已經配置好了Master和Slave，具體詳細配置參

手動切換master

master SLAVEOF NO ONE

slave SLAVEOF 192.168.1.1 3000

創建哨兵

touch sentinel.conf 內容如下

sentinel monitor 主機名主機ip 主機端口票數n 票數多余n的從機作為主機

sentinel monitor mymaster 192.168.1.1 1000 1

啟動哨兵

redis-sentinel sentinel.conf

20526:X 20 Nov 13:24:29.243 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
20526:X 20 Nov 13:24:29.303 # Sentinel ID is 5d351f7edc80148f60036a6c0c2e74510ece4221
20526:X 20 Nov 13:24:29.303 # +monitor master mymaster 192.168.1.1 1000 quorum 1
20526:X 20 Nov 13:24:29.304 * +slaveslave 192.168.1.1:2000 192.168.1.1 2000 @ mymaster 192.168.1.1 1000
20526:X 20 Nov 13:24:29.317 * +slaveslave 192.168.1.1:3000 192.168.1.1 3000 @ mymaster 192.168.1.1 1000

1.將3000 kill掉

redis-cli -h 192.168.1.1 -p 3000
Couldnot connectto Redisat 192.168.1.1:3000: Connectionrefused
Couldnot connectto Redisat 192.168.1.1:3000: Connectionrefused
 
192.168.1.1:1000> setzhangsan 1
192.168.1.1:1000> getzhangsan
 
"1"
 
192.168.1.1:2000> getzhangsan
 
"1"
 
3000重啟
 
192.168.1.1:3000> getzhangsan
 
"1"

2.將master(1000) kill掉

redis-cli -h 192.168.1.1 -p 1000

Could not connect to Redis at 192.168.1.1:1000: Connection refused

查看哨兵后臺打印信息

20526:X 20 Nov 13:27:40.550 # +sdown master mymaster 192.168.1.1 1000
20526:X 20 Nov 13:27:40.550 # +odown master mymaster 192.168.1.1 1000 #quorum 1/1
20526:X 20 Nov 13:27:40.550 # +new-epoch 1
20526:X 20 Nov 13:27:40.550 # +try-failover master mymaster 192.168.1.1 1000
20526:X 20 Nov 13:27:40.559 # +vote-for-leader 5d351f7edc80148f60036a6c0c2e74510ece4221 1
20526:X 20 Nov 13:27:40.559 # +elected-leader master mymaster 192.168.1.1 1000
20526:X 20 Nov 13:27:40.559 # +failover-state-select-slave master mymaster 192.168.1.1 1000
20526:X 20 Nov 13:27:40.612 # +selected-slave slave 192.168.1.1:2000 192.168.1.1 2000 @ mymaster 192.168.1.1 1000
20526:X 20 Nov 13:27:40.612 * +failover-state-send-slaveof-nooneslave 192.168.1.1:2000 192.168.1.1 2000 @ mymaster 192.168.1.1 1000
20526:X 20 Nov 13:27:40.688 * +failover-state-wait-promotionslave 192.168.1.1:2000 192.168.1.1 2000 @ mymaster 192.168.1.1 1000
20526:X 20 Nov 13:27:40.766 # +promoted-slave slave 192.168.1.1:2000 192.168.1.1 2000 @ mymaster 192.168.1.1 1000
20526:X 20 Nov 13:27:40.766 # +failover-state-reconf-slaves master mymaster 192.168.1.1 1000
20526:X 20 Nov 13:27:40.818 * +slave-reconf-sentslave 192.168.1.1:3000 192.168.1.1 3000 @ mymaster 192.168.1.1 1000
20526:X 20 Nov 13:27:41.813 * +slave-reconf-inprogslave 192.168.1.1:3000 192.168.1.1 3000 @ mymaster 192.168.1.1 1000
20526:X 20 Nov 13:27:41.813 * +slave-reconf-doneslave 192.168.1.1:3000 192.168.1.1 3000 @ mymaster 192.168.1.1 1000
20526:X 20 Nov 13:27:41.896 # +failover-end master mymaster 192.168.1.1 1000
20526:X 20 Nov 13:27:41.896 # +switch-master mymaster 192.168.1.1 1000 192.168.1.1 2000
20526:X 20 Nov 13:27:41.896 * +slaveslave 192.168.1.1:3000 192.168.1.1 3000 @ mymaster 192.168.1.1 2000
20526:X 20 Nov 13:27:41.896 * +slaveslave 192.168.1.1:1000 192.168.1.1 1000 @ mymaster 192.168.1.1 2000
20526:X 20 Nov 13:28:11.907 # +sdown slave 192.168.1.1:1000 192.168.1.1 1000 @ mymaster 192.168.1.1 2000

192.168.1.1:2000> info 變成了主

# Replication

role:master

connected_slaves:1

slave0:ip=192.168.1.1,port=3000,state=online,offset=1625,lag=0

192.168.1.1:2000> set aa 11

192.168.1.1:2000> get aa

“11”

192.168.1.1:3000> info 還是從

# Replication

role:slave

master_host:192.168.1.1

master_port:2000

master_link_status:up

192.168.1.1:3000> get aa

“11”

重啟1000原來的master服務器

查看哨兵

20526:X 20 Nov 13:42:51.554 # -sdown slave 192.168.1.1:1000 192.168.1.1 1000 @ mymaster 192.168.1.1 2000
20526:X 20 Nov 13:43:01.604 * +convert-to-slaveslave 192.168.1.1:1000 192.168.1.1 1000 @ mymaster 192.168.1.1 2000

192.168.1.1:1000> info 變成從

# Replication

role:slave

master_host:192.168.1.1

master_port:2000

master_link_status:up

192.168.1.1:1000> get aa

“11”

Redis-sentinel高可用

Redis-Sentinel是Redis官方推薦的高可用性(HA)解決方案，當用Redis做Master-slave的高可用方案時，假如master宕機了，Redis本身(包括它的很多客戶端)都沒有實現自動進行主備切換，而Redis-sentinel本身也是一個獨立運行的進程，它能監控多個master-slave集群，發現master宕機后能進行自動切換。

它的主要功能有以下幾點

不時地監控redis是否按照預期良好地運行;

如果發現某個redis節點運行出現狀況，能夠通知另外一個進程(例如它的客戶端);

能夠進行自動切換。當一個master節點不可用時，能夠選舉出master的多個slave(如果有超過一個slave的話)中的一個來作為新的master,其它的slave節點會將它所追隨的master的地址改為被提升為master的slave的新地址。

需要注意的是，配置文件在sentinel運行期間是會被動態修改的，例如當發生主備切換時候，配置文件中的master會被修改為另外一個slave。這樣，之后sentinel如果重啟時，就可以根據這個配置來恢復其之前所監控的redis集群的狀態。

sentinelmonitormymaster 192.168.1.1 1000 1 sentineldown-after-millisecondsmymaster 60000

sentinel can-failover mymaster yes

sentinelfailover-timeoutmymaster 180000 sentinelparallel-syncsmymaster 1 </pre>

當sentinel集群式，解決這個問題的方法就變得很簡單，只需要多個sentinel互相溝通來確認某個master是否真的死了，這個 2 代表，當集群中有2個sentinel認為master死了時，才能真正認為該master已經不可用了。

down-after-milliseconds

sentinel會向master發送心跳PING來確認master是否存活，如果master在“一定時間范圍”內不回應PONG 或者是回復了一個錯誤消息，那么這個sentinel會主觀地(單方面地)認為這個master已經不可用了(subjectively down, 也簡稱為SDOWN)。而這個down-after-milliseconds就是用來指定這個“一定時間范圍”的，單位是毫秒。

can-failover

no 表示當前sentinel是一個觀察者，只參與投票不參與實施failover

全局中至少有一個是yes

parallel-syncs

當新master產生時，同時進行“slaveof”到新master并進行“SYNC”的slave個數

默認為1,建議保持默認值

在salve執行salveof與同步時，將會終止客戶端請求

failover-timeout

failover過期時間，當failover開始后，在此時間內仍然沒有觸發任何failover操作

當前sentinel將會認為此次failoer失敗

來自：http://blog.jobbole.com/107941/

本文由用戶 z_vv 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。

轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。

本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！

本文地址：http://www.baiduhome.net/lib/view/open1479820573888.html

Redis NoSQL數據庫

Redis 主從配置心得及其高可用方案

redis主從復制過程：

Redis-sentinel高可用

sentinel can-failover mymaster yes

相關經驗

相關資訊

相關文檔

目錄