Redis 主從集群搭建及哨兵模式配置

最近搭建了redis集群及哨兵模式，為方便以后查看特此記錄下來；

1.Redis安裝

2.主從架構

　　2.1 Redis主從架構圖

　　

　　2.2Redis主從結構搭建

　　Redis集群不用安裝多個Redis,只需復制多個配置文件,修改即可；

　　搭建redis master

　　進入redis安裝目錄，創建redis_master文件夾，并且拷貝redis的可執行文件

　　　　cd redis-4.0.8

　　　　mkdir?redis_master

　　　　cp redis-4.0.8/src/redis-cli .

　　　　cp redis-4.0.8/src/redis-server .

　　　　cp redis-4.0.8/redis.conf

　　修改redis.conf配置文件

# 守護進程模式 daemonize yes
# pid file 修改pidfile指向路徑 pidfile /usr/local/redis-4.0.8/redis_master/redis_master.pid# 監聽端口 port 7001# TCP接收隊列長度，受/proc/sys/net/core/somaxconn和tcp_max_syn_backlog這兩個內核參數的影響 tcp-backlog 511# 一個客戶端空閑多少秒后關閉連接(0代表禁用，永不關閉) timeout 0# 如果非零，則設置SO_KEEPALIVE選項來向空閑連接的客戶端發送ACK tcp-keepalive 60# 指定服務器調試等級 # 可能值： # debug （大量信息，對開發/測試有用） # verbose （很多精簡的有用信息，但是不像debug等級那么多） # notice （適量的信息，基本上是你生產環境中需要的） # warning （只有很重要/嚴重的信息會記錄下來） loglevel notice# 指明日志文件名 logfile "./redis7001.log"# 設置數據庫個數 databases 16# 會在指定秒數和數據變化次數之后把數據庫寫到磁盤上 # 900秒（15分鐘）之后，且至少1次變更 # 300秒（5分鐘）之后，且至少10次變更 # 60秒之后，且至少10000次變更 save 900 1 save 300 10 save 60 10000# 默認如果開啟RDB快照(至少一條save指令)并且最新的后臺保存失敗，Redis將會停止接受寫操作 # 這將使用戶知道數據沒有正確的持久化到硬盤，否則可能沒人注意到并且造成一些災難 stop-writes-on-bgsave-error yes# 當導出到 .rdb 數據庫時是否用LZF壓縮字符串對象 rdbcompression yes# 版本5的RDB有一個CRC64算法的校驗和放在了文件的最后。這將使文件格式更加可靠。 rdbchecksum yes# 持久化數據庫的文件名 dbfilename dump-master.rdb# 工作目錄 dir /usr/local/redis-4.0.8/redis_master/# 當master服務設置了密碼保護時，slav服務連接master的密碼 masterauth testmaster123# 當一個slave失去和master的連接，或者同步正在進行中，slave的行為可以有兩種： # # 1) 如果 slave-serve-stale-data 設置為 "yes" (默認值)，slave會繼續響應客戶端請求， # 可能是正常數據，或者是過時了的數據，也可能是還沒獲得值的空數據。 # 2) 如果 slave-serve-stale-data 設置為 "no"，slave會回復"正在從master同步 # （SYNC with master in progress）"來處理各種請求，除了 INFO 和 SLAVEOF 命令。 slave-serve-stale-data yes# 你可以配置salve實例是否接受寫操作。可寫的slave實例可能對存儲臨時數據比較有用(因為寫入salve # 的數據在同master同步之后將很容易被刪除 slave-read-only yes# 是否在slave套接字發送SYNC之后禁用 TCP_NODELAY？ # 如果你選擇“yes”Redis將使用更少的TCP包和帶寬來向slaves發送數據。但是這將使數據傳輸到slave # 上有延遲，Linux內核的默認配置會達到40毫秒 # 如果你選擇了 "no" 數據傳輸到salve的延遲將會減少但要使用更多的帶寬 repl-disable-tcp-nodelay no# slave的優先級是一個整數展示在Redis的Info輸出中。如果master不再正常工作了，哨兵將用它來 # 選擇一個slave提升=升為master。 # 優先級數字小的salve會優先考慮提升為master，所以例如有三個slave優先級分別為10，100，25， # 哨兵將挑選優先級最小數字為10的slave。 # 0作為一個特殊的優先級，標識這個slave不能作為master，所以一個優先級為0的slave永遠不會被 # 哨兵挑選提升為master slave-priority 100# 密碼驗證 # 警告：因為Redis太快了，所以外面的人可以嘗試每秒150k的密碼來試圖破解密碼。這意味著你需要 # 一個高強度的密碼，否則破解太容易了 requirepass testmaster123# redis實例最大占用內存，不要用比設置的上限更多的內存。一旦內存使用達到上限，Redis會根據選定的回收策略（參見： # maxmemmory-policy）刪除key maxmemory 3gb# 最大內存策略：如果達到內存限制了，Redis如何選擇刪除key。你可以在下面五個行為里選： # volatile-lru -> 根據LRU算法刪除帶有過期時間的key。 # allkeys-lru -> 根據LRU算法刪除任何key。 # volatile-random -> 根據過期設置來隨機刪除key, 具備過期時間的key。 # allkeys->random -> 無差別隨機刪, 任何一個key。 # volatile-ttl -> 根據最近過期時間來刪除（輔以TTL）, 這是對于有過期時間的key # noeviction -> 誰也不刪，直接在寫操作時返回錯誤。 maxmemory-policy volatile-lru# 默認情況下，Redis是異步的把數據導出到磁盤上。這種模式在很多應用里已經足夠好，但Redis進程 # 出問題或斷電時可能造成一段時間的寫操作丟失(這取決于配置的save指令)。 # # AOF是一種提供了更可靠的替代持久化模式，例如使用默認的數據寫入文件策略（參見后面的配置） # 在遇到像服務器斷電或單寫情況下Redis自身進程出問題但操作系統仍正常運行等突發事件時，Redis # 能只丟失1秒的寫操作。 # # AOF和RDB持久化能同時啟動并且不會有問題。 # 如果AOF開啟，那么在啟動時Redis將加載AOF文件，它更能保證數據的可靠性。 appendonly no# aof文件名 appendfilename "appendonly.aof"# fsync() 系統調用告訴操作系統把數據寫到磁盤上，而不是等更多的數據進入輸出緩沖區。 # 有些操作系統會真的把數據馬上刷到磁盤上；有些則會盡快去嘗試這么做。 # # Redis支持三種不同的模式： # # no：不要立刻刷，只有在操作系統需要刷的時候再刷。比較快。 # always：每次寫操作都立刻寫入到aof文件。慢，但是最安全。 # everysec：每秒寫一次。折中方案。 appendfsync everysec# 如果AOF的同步策略設置成 "always" 或者 "everysec"，并且后臺的存儲進程（后臺存儲或寫入AOF # 日志）會產生很多磁盤I/O開銷。某些Linux的配置下會使Redis因為 fsync()系統調用而阻塞很久。 # 注意，目前對這個情況還沒有完美修正，甚至不同線程的 fsync() 會阻塞我們同步的write(2)調用。 # # 為了緩解這個問題，可以用下面這個選項。它可以在 BGSAVE 或 BGREWRITEAOF 處理時阻止主進程進行fsync()。 # # 這就意味著如果有子進程在進行保存操作，那么Redis就處于"不可同步"的狀態。 # 這實際上是說，在最差的情況下可能會丟掉30秒鐘的日志數據。（默認Linux設定） # # 如果你有延時問題把這個設置成"yes"，否則就保持"no"，這是保存持久數據的最安全的方式。 no-appendfsync-on-rewrite yes# 自動重寫AOF文件 auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb# AOF文件可能在尾部是不完整的（這跟system關閉有問題，尤其是mount ext4文件系統時 # 沒有加上data=ordered選項。只會發生在os死時，redis自己死不會不完整）。 # 那redis重啟時load進內存的時候就有問題了。 # 發生的時候，可以選擇redis啟動報錯，并且通知用戶和寫日志，或者load盡量多正常的數據。 # 如果aof-load-truncated是yes，會自動發布一個log給客戶端然后load（默認）。 # 如果是no，用戶必須手動redis-check-aof修復AOF文件才可以。 # 注意，如果在讀取的過程中，發現這個aof是損壞的，服務器也是會退出的， # 這個選項僅僅用于當服務器嘗試讀取更多的數據但又找不到相應的數據時。 aof-load-truncated yes# Lua 腳本的最大執行時間，毫秒為單位 lua-time-limit 5000# Redis慢查詢日志可以記錄超過指定時間的查詢 slowlog-log-slower-than 10000# 這個長度沒有限制。只是要主要會消耗內存。你可以通過 SLOWLOG RESET 來回收內存。 slowlog-max-len 128# redis延時監控系統在運行時會采樣一些操作，以便收集可能導致延時的數據根源。 # 通過 LATENCY命令 可以打印一些圖樣和獲取一些報告，方便監控 # 這個系統僅僅記錄那個執行時間大于或等于預定時間（毫秒）的操作, # 這個預定時間是通過latency-monitor-threshold配置來指定的， # 當設置為0時，這個監控系統處于停止狀態 latency-monitor-threshold 0# Redis能通知 Pub/Sub 客戶端關于鍵空間發生的事件，默認關閉 notify-keyspace-events ""# 當hash只有少量的entry時，并且最大的entry所占空間沒有超過指定的限制時，會用一種節省內存的 # 數據結構來編碼。可以通過下面的指令來設定限制 hash-max-ziplist-entries 512 hash-max-ziplist-value 64# 與hash似，數據元素較少的list，可以用另一種方式來編碼從而節省大量空間。 # 這種特殊的方式只有在符合下面限制時才可以用 list-max-ziplist-entries 512 list-max-ziplist-value 64# set有一種特殊編碼的情況：當set數據全是十進制64位有符號整型數字構成的字符串時。 # 下面這個配置項就是用來設置set使用這種編碼來節省內存的最大長度。 set-max-intset-entries 512# 與hash和list相似，有序集合也可以用一種特別的編碼方式來節省大量空間。 # 這種編碼只適合長度和元素都小于下面限制的有序集合 zset-max-ziplist-entries 128 zset-max-ziplist-value 64# HyperLogLog稀疏結構表示字節的限制。該限制包括 # 16個字節的頭。當HyperLogLog使用稀疏結構表示 # 這些限制，它會被轉換成密度表示。 # 值大于16000是完全沒用的，因為在該點 # 密集的表示是更多的內存效率。 # 建議值是3000左右，以便具有的內存好處, 減少內存的消耗 hll-sparse-max-bytes 3000# 啟用哈希刷新，每100個CPU毫秒會拿出1個毫秒來刷新Redis的主哈希表（頂級鍵值映射表） activerehashing yes# 客戶端的輸出緩沖區的限制，可用于強制斷開那些因為某種原因從服務器讀取數據的速度不夠快的客戶端 client-output-buffer-limit normal 0 0 0 client-output-buffer-limit slave 256mb 64mb 60 client-output-buffer-limit pubsub 32mb 8mb 60# 默認情況下，“hz”的被設定為10。提高該值將在Redis空閑時使用更多的CPU時，但同時當有多個key # 同時到期會使Redis的反應更靈敏，以及超時可以更精確地處理 hz 10# 當一個子進程重寫AOF文件時，如果啟用下面的選項，則文件每生成32M數據會被同步 aof-rewrite-incremental-fsync yes

　　啟動master :?redis-server ./redis.conf

　　查看下redis進程有沒有 7001的：ps axu|grep redis

　　在客戶端做鏈接測試 :?redis-cli? -p 7001 -a testmaster123

　　插入一條數據：set name lisi

　　查詢數據：get name

　　"lisi"

　　退出：quit

　　至此 redis_master 啟動成功，能正常讀寫數據

　　搭建redis slave

　　進入redis安裝目錄，創建redis_slave文件夾，并且拷貝redis的可執行文件

　　　　cd redis-4.0.8

　　　　mkdir?redis_slave

　　　　cp redis-4.0.8/src/redis-cli .

　　　　cp redis-4.0.8/src/redis-server .

　　　　cp redis-4.0.8/redis.conf

　　修改redis.conf配置文件??slave的配置和master基本一致，只需要修改相應的pidfile，端口，日志文件名，并配上master的地址和認證密碼

　　　　# pid file

　　　　pidfile??/usr/local/redis-4.0.8/redis_slave/redis_slave.pid

　　　　#?監聽端口　　

　　　　port 7002

　　　　#?指明日志文件名

　　　　logfile "./redis7002.log"

?　　　　#?設置當本機為slav服務時，設置master服務的IP地址及端口，在Redis啟動時，它會自動從master進行數據同步

　　　　slaveof 127.0.0.1 7001

?　　　　#?當master服務設置了密碼保護時，slav服務連接master的密碼

　　　　masterauth testmaster123

　　　#（默認情況下redis數據庫充當slave角色時是只讀的不能進行寫操作 可以在配置文件中開啟非只讀:slave-read-only no）

　　啟動redis slave 查看數據同步情況

　　啟動redis slave : redis-server ./redis.conf

　　鏈接redis slave :? redis-cli -p 7002 -a testmaster123

　　查詢數據 ： get name

　　"zhangsan"

　　至此 master中設置的key-value已經成功同步過來

?

?　 主從復制原理：

　　　1.當從庫和主庫建立MS關系后,會向主數據庫發送SYNC命令

　　???2.主庫接收到SYNC命令后會開始在后臺保存快照(RDB持久化過程),并將期間接收到的寫命令緩存起來

? ? ? ? ? 3.當快照完成后,主Redis會將快照文件和所有緩存的寫命令發送給從Redis

? ? ? ? ?4.從Redis接收到后,會載入快照文件并且執行收到的緩存的命令

? ? ? ? ?5.之后,主Redis每當接收到寫命令時就會將命令發送從Redis，從而保證數據的一致

?

　　Redis Sentinel (哨兵)部署

　　　　Sentinel介紹：Sentinel是Redis的高可用性（HA）解決方案，由一個或多個Sentinel實例組成的Sentinel系統可以監視任意多個主服務器，以及這些主服務器屬下的所有從服務器，并在被監視的主服務器進行下線狀態時，

　　　　　　　　　　　自動將下線主服務器屬下的某個從服務器升級為新的主服務器，然后由新的主服務器代替已下線的主服務器繼續處理命令請求。Redis提供的sentinel（哨兵）機制，通過sentinel模式啟動redis后，

　　　　　　　　　　　自動監控master/slave的運行狀態，基本原理是：心跳機制+投票裁決（每個sentinel只有一次選舉的機會，當主庫出現故障，哨兵會投票從庫中選出一個承擔主庫的任務，剩下的還是從庫）

　　　　Sentinel作用:

　　　　　　1.?監控：監控主從是否正常
　　　　　　2.?通知：出現問題時，可以通知相關人員
　　　　　　3. 自動故障遷移：自動主從切換
　　　　　　4.?統一的配置管理：連接者詢問sentinel取得主從的地址

　　　　哨兵配置：

　　　　進入redis的安裝目錄 創建sentinel文件夾 拷貝可執行文件 配置哨兵

　　　　　　cd redis-4.0.8

　　　　　　mkdir?redis_sentinel

　　　　　　cp redis-4.0.8/src/redis-cli .

　　　　　　cp redis-4.0.8/src/redis-server .

　　　　　　touch sentinel1.conf?

　　　　哨兵一配置 sentinel1.conf　　

# Example sentinel.conf# port <sentinel-port> port 8001# 守護進程模式 daemonize yes# 指明日志文件名 logfile "./sentinel1.log"# 工作路徑，sentinel一般指定/tmp比較簡單 dir ./# 哨兵監控這個master，在至少quorum個哨兵實例都認為master down后把master標記為odown # （objective down客觀down；相對應的存在sdown，subjective down，主觀down）狀態。 # slaves是自動發現，所以你沒必要明確指定slaves。 sentinel monitor MyMaster 127.0.0.1 7001 1# master或slave多長時間（默認30秒）不能使用后標記為s_down狀態。 sentinel down-after-milliseconds MyMaster 1500# 若sentinel在該配置值內未能完成failover操作（即故障時master/slave自動切換），則認為本次failover失敗。 sentinel failover-timeout TestMaster 10000# 設置master和slaves驗證密碼 sentinel auth-pass TestMaster testmaster123sentinel config-epoch TestMaster 15 #除了當前哨兵, 還有哪些在監控這個master的哨兵 sentinel known-sentinel TestMaster 127.0.0.1 8002 0aca3a57038e2907c8a07be2b3c0d15171e44da5 sentinel known-sentinel TestMaster 127.0.0.1 8003 ac1ef015411583d4b9f3d81cee830060b2f29862

?　　

　　哨兵二配置 sentinel2.conf

　　　　復制 sentinel1.conf 命名為??sentinel2.conf

　　　　修改sentinel2.conf配置文件?需要修改端口，日志文件名，其他監控哨兵配置

　　　　　　# port <sentinel-port>

　　　　　　port 8002

　　　　　　# 指明日志文件名

　　　　　　logfile "./sentinel2.log"

　　　　　　#除了當前哨兵, 還有哪些在監控這個master的哨兵

　　　　　　sentinel known-sentinel TestMaster 127.0.0.1 8002 0aca3a57038e2907c8a07be2b3c0d15171e44da5

　　　　　　sentinel known-sentinel TestMaster 127.0.0.1 8003 ac1ef015411583d4b9f3d81cee830060b2f29862

?

　　哨兵三配置 sentinel3.conf

　　　　復制 sentinel1.conf 命名為??sentinel3.conf

　　　　修改sentinel3.conf配置文件?需要修改端口，日志文件名，其他監控哨兵配置

　　　　　　# port <sentinel-port>

　　　　　　port 8003

　　　　　　# 指明日志文件名

　　　　　　logfile "./sentinel3.log"

　　　　　　#除了當前哨兵, 還有哪些在監控這個master的哨兵

　　　　　　sentinel known-sentinel TestMaster 127.0.0.1 8001 0aca3a57038e2907c8a07be2b3c0d15171e44da5

　　　　　　sentinel known-sentinel TestMaster 127.0.0.1 8002 ac1ef015411583d4b9f3d81cee830060b2f29862

啟動哨兵：redis.sentinel? ./sentinel1.conf? 或使用 redis.server ./sentinel1.conf? --sentinel

　　　　　redis.sentinel? ./sentinel2.conf

　　　　　redis.sentinel? ./sentinel3.conf

在sentinel中查看 所監控的master 和slave?

鏈接哨兵：redis-cli -p 8001

查看master:??SENTINEL masters

　　查看當前mastrer :SENTINEL get-master-addr-by-name TestMaster

　　

?

　　檢查容災切換情況

　　查看當前redis進程：ps -ef|grep redis

　　殺掉當前master進程 ： kill -9 進程號

　　再在哨兵中查看當前master，已經切換成了 7002

　　

　　啟動原來的master ，查詢當前的slave? （SENTINEL slaves TestMaster）? 主從發生了對調

?

　　Redis注意事項：

　　　　1.最大內存問題：要設置好最大內存，以防不停的申請內存，造成系統內存都被用完。

　　　　2.Fork進程問題：'vm.overcommit_memory = 1'這一個選項要加到系統的配置中，防止fork因內存不足而失敗。

　　　　3.密碼問題：需要設置復雜一些，防止暴力破解。

　　

?

　　

　　　　

　　

　　

posted on 2018-09-12 10:46 【cosmo】 閱讀(...) 評論(...) 編輯 收藏

轉載于:https://www.cnblogs.com/qinxu/p/9633418.html

總結

以上是生活随笔為你收集整理的Redis 主从集群搭建及哨兵模式配置的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。