redis 持久化 哨兵 主從

                            Redis搭建步驟

環境：

三臺機器  centos7

關閉防火牆 selinux

Redis版本 3.0.5

依賴環境

yum install gcc-c++ ruby rubygems –y

把版本包上傳到服務器上，redis-3.0.5.tar.gz

解壓tar -zxvf redis-3.0.5.tar.gz

而後進入目錄

cd redis-3.0.5

直接make

而後進入

cd /redis/redis-3.0.5/src/

make install

而後把啓動文件還有配置文件移除到其餘地方方便管理

   mkdir -p/usr/local/redis/bin

   mkdir -p /usr/local/redis/bin

   mkdir -p /usr/local/redis/etc

移動文件

mv redis.conf /usr/local/redis/etc/

如下文件在src目錄裏：

mv mkreleasehdr.sh redis-benchmark redis-check-aof redis-check-dump redis-cli redis-server /usr/local/redis/bin/

方便後臺啓動須要改動redis.conf 配置文件

Vim redis.conf首先編輯conf文件，將daemonize屬性改成yes（代表須要在後臺運行）

redis-server /usr/local/redis/etc/redis.conf  完成單點

 

經常使用命令：

 

Redis：

Redis-server /usr..../redis.conf 啓動redis服務，並指定配置文件

Redis-cli 啓動redis 客戶端

Pkill redis-server 關閉redis服務

Redis-cli shutdown 關閉redis客戶端

Netstat -tunpl|grep 6379 查看redis 默認端口號6379佔用狀況

 

Redis集羣模式（主從）

     主庫不須要動

     從庫修改salveof 後面添加主庫IP + redis端口號

     配置主服務器

一、進入192.168.2.100服務器，打開redis配置文件

[root@localhost redis-4.0.10]# vim /etc/redis/6379.conf

1

二、將bind 127.0.0.1這行註釋或者指定ip。（本例是註釋，即全部ip都能鏈接）

 

 

 

三、開啓守護進程

 

 

 

 

四、設置訪問密碼（因爲redis性能很是高，撞庫風險極大，建議線上把密碼設置很是複雜，最好能在第2步中指定ip）

 

 

 

 

注意：

固然，既然用到主從了，那說明對redis依賴很是高，還有幾個參數須要根據服務器配置來設置

第一個就是客戶端最大鏈接數（maxclients），默認是10000，可根據需求更改

 

 

 

第二個就是最大內存（默認不受限制，但若是有多個從服務器，建議仍是設置個低於服務器內存的值）

 

 

 

第三個是內存策略，若是內存足夠用則不用管，若是內存不夠用，建議設置最近最少使用策略（LRU）,默認是內存不夠則報錯

 

 

 

至此主服務器配置完畢！

 

3、配置從服務器

前四步與主服務器配置基本一致

五、配置所屬主服務器ip和端口

 

 

 

六、配置所屬主服務器的密碼（再次強調，要將密碼設置很是複雜，這裏只是演示）

 

 

 

須要注意的是，從服務器一般是隻讀，因此要配置只讀（默認是隻讀，不要更改便可）

 

 

 

配置完成，啓動服務

1

4、測試

使用redis客戶端或者telnet均可以

本次使用redis客戶端

 

 

 

一、進入主服務器（192.168.2.100）

進入redis客戶端

 

[root@localhost redis-4.0.10]# /usr/local/redis/bin/redis-cli

1

因爲設置了密碼，因此須要鑑權

 

 

 

設置一個值

 

 

 

 

二、進入從服務器（192.168.2.101）

使用get命令獲取name的值，能夠看到

 

 

 

表明配置成功

若是在從服務器上寫，則會報錯，以下圖

 

 

 

 

至此，redis主從複製配置完成，若是須要配置多臺從服務器，能夠重複第三步

 

主從複製原理：

　　　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取得主從的地址

部署哨兵

yum install gcc-c++ ruby rubygems –y

須要單獨一個機器作哨兵部署

配置文件在redis包里名字sentinel.conf

配置以下

          protected-mode no      （去掉註釋）
            daemonize yes          （自行添加守護進程）
            dir /tmp
            logfile "/var/log/redis/redis_26379.log"    （自行添加哨兵的日誌）
            sentinel monitor mymaster 192.168.52.138 6379 2   （原基礎上更改）
            sentinel down-after-milliseconds mymaster 30000   （默認）
            sentinel parallel-syncs mymaster 1                （默認）
            sentinel failover-timeout mymaster 180000         （默認）  ）

 

 

 

 

 

 

Redis持久化

都在redis.conf中配置

 

  1、RDB持久化

1.1介紹

RDB方式是經過快照完成的,當符合必定的條件時,redis會自動將內存中的全部數據進行快照而且存儲到硬盤上，默認存儲在redis根目錄的dump.rdb文件中(文件名在配置文件中dbfilename),進行快照的條件在redis.conf配置文件中指定，有兩個參數構成，時間和改動的鍵的個數，當在指定時間被更改的鍵的個數大於指定數值時就會進行快照，RDB是redis默認的持久化方式

1.2快照過程

當redis須要作持久化時，redis會fork一個子進程；子進程將數據寫到磁盤上一個臨時RDB文件中；當子進程完成寫臨時文件後，將原來的RDB替換掉,而後子進程退出

1.3RDB持久化配置

RDB是Redis默認採用的持久化方式，在redis.conf配置文件中默認有此下配置：
save 900 1
save 300 10
save 60 10000

save 開頭的一行就是持久化配置，能夠配置多個條件（每行配置一個條件），每一個條件之間是「或」的關係，「save 900 1」表示15分鐘（900秒鐘）內至少1個鍵被更改則進行快照，「save 300 10」表示5分鐘（300秒）內至少10個鍵被更改則進行快照。"60 10000"表示60秒內有10000個key出現變動  作一次快照

在redis.conf中：

配置dir指定rdb快照文件的位置

配置dbfilenam指定rdb快照文件的名稱

1.4RDB的優缺點

RDB的優勢：

1). 一旦採用該方式，那麼你的整個Redis數據庫將只包含一個文件，這對於文件備份而言是很是完美的。好比，你可能打算每一個小時歸檔一次最近24小時的數據，同時還要天天歸檔一次最近30天的數據。經過這樣的備份策略，一旦系統出現災難性故障，咱們能夠很是容易的進行恢復。

2). 對於災難恢復而言，RDB是很是不錯的選擇。由於咱們能夠很是輕鬆的將一個單獨的文件壓縮後再轉移到其它存儲介質上。

3). 性能最大化。對於Redis的服務進程而言，在開始持久化時，它惟一須要作的只是fork出子進程，以後再由子進程完成這些持久化的工做，這樣就能夠極大的避免服務進程執行IO操做了。

4). 相比於AOF機制，若是數據集很大，RDB的啓動效率會更高。

RDB的缺點：

1). 若是你想保證數據的高可用性，即最大限度的避免數據丟失，那麼RDB將不是一個很好的選擇。由於系統一旦在定時持久化以前出現宕機現象，此前沒有來得及寫入磁盤的數據都將丟失。
2). 因爲RDB是經過fork子進程來協助完成數據持久化工做的，所以，若是當數據集較大時，可能會致使整個服務器中止服務幾百毫秒，甚至是1秒鐘。

2、AOF持久化

1.1介紹

redis會將每個收到的寫命令都經過write函數追加到文件中(默認是 appendonly.aof)。AOF就能夠作到全程持久化，只須要在配置文件中開啓（默認是no不開啓的）,開啓AOF以後，（默認是：每秒fsync一次）

1.2持久化過程

Redis 執行 fork() ，如今同時擁有父進程和子進程。子進程開始將新 AOF 文件的內容寫入到臨時文件。對於全部新執行的寫入命令，父進程一邊將它們累積到一個內存緩存中，一邊將這些改動追加到現有 AOF 文件的末尾： 這樣即便在重寫的中途發生停機，現有的 AOF 文件也仍是安全的。當子進程完成重寫工做時，它給父進程發送一個信號，父進程在接收到信號以後，將內存緩存中的全部數據追加到新 AOF 文件的末尾。如今 Redis 原子地用新文件替換舊文件，以後全部命令都會直接追加到新 AOF 文件的末尾。

1.3AOF的配置

開啓AOF持久化

appendonly yes #啓用aof持久化方式

在Redis的配置文件中存在三種同步方式，它們分別是：

appendfsync always #每次有數據修改發生時都會寫入AOF文件。
appendfsync everysec #每秒鐘同步一次，該策略爲AOF的缺省策略。
appendfsync no #從不一樣步。高效可是數據不會被持久化。

AOF持久化文件的名稱

appendfilename 「appendonly.aof」

1.4如何修復壞損的AOF文件：

將現有已經壞損的AOF文件額外拷貝出來一份

執行」redis-check-aof –fix 」命令來修復壞損的AOF文件。

用修復後的AOF文件從新啓動Redis服務器。

1.5AOF的優缺點

AOF的優勢：

1). 該機制能夠帶來更高的數據安全性，即數據持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不一樣步。事實上，每秒同步也是異步完成的，其效率也是很是高的，所差的是一旦系統出現宕機現象，那麼這一秒鐘以內修改的數據將會丟失。而每修改同步，咱們能夠將其視爲同步持久化，即每次發生的數據變化都會被當即記錄到磁盤中。能夠預見，這種方式在效率上是最低的。至於無同步，無需多言，我想你們都能正確的理解它。
2). 因爲該機制對日誌文件的寫入操做採用的是append模式，所以在寫入過程當中即便出現宕機現象，也不會破壞日誌文件中已經存在的內容。然而若是咱們本次操做只是寫入了一半數據就出現了系統崩潰問題，不用擔憂，在Redis下一次啓動以前，咱們能夠經過redis-check-aof工具來幫助咱們解決數據一致性的問題。
3). 若是日誌過大，Redis能夠自動啓用rewrite機制。即Redis以append模式不斷的將修改數據寫入到老的磁盤文件中，同時Redis還會建立一個新的文件用於記錄此期間有哪些修改命令被執行。所以在進行rewrite切換時能夠更好的保證數據安全性。
4). AOF包含一個格式清晰、易於理解的日誌文件用於記錄全部的修改操做。事實上，咱們也能夠經過該文件完成數據的重建。

AOF的劣勢：

1). 對於相同數量的數據集而言，AOF文件一般要大於RDB文件。 2). 根據同步策略的不一樣，AOF在運行效率上每每會慢於RDB。總之，每秒同步策略的效率是比較高的，同步禁用策略的效率和RDB同樣高效。