redis學習三 redis持久化

 

1，快照持久化

     1簡介

     redis能夠經過建立快照來得到某個時間點上的內存內容的數據副本，有了副本以後，就能夠將副本發送到其餘redis服務器上從而建立相同數據的從服務器，同時快照留在原地以便重啓redis的時候實現數據恢復。

     2配置 

     save 60 1000  快照生成策略  若是服務器距離上一次成功生成快照已經超過六十秒，而且期間執行了至少1000次寫操做。

     stop-writes-on-bgsave-error yes 建立快照文件失敗後是否繼續執行寫命令

     rdbcompression yes   是否對快照文件進行壓縮

     dbfilename dump.rdb  快照文件名稱

     dir /opt/redis-2.8.13/dmp/  持久化文件保存的路徑

     3快照文件生成的時機

     1，向redis發送bgsave命令，redis會調用fork來建立一個子進程，子進程負責建立快照，父進程繼續處理命令請求。

     2，向redis發送save命令，父進程中止響應其餘命令，開始進行快照建立，save命令一般不用，通常在沒有足夠內存執行bgsave的時候或者讓客戶端等待也不要緊的時候使用。

     3，根據用戶設置的save 策略配置信息，進行執行。若是配置多個，只要知足一個就執行。

     4，redis接收到shutdown或者標準term命令的時候，會觸發save命令，建立快照。

     5，當從服務器連接到主服務器而且發送sync命令來同步數據的時候，而且這個時候主服務器沒有在執行bgsave或者不是剛剛執行完bgsave的話，就建立個快照，以供複製使用。

     當內存數據量不那麼大的時候，使用快照持久化比較不錯。可是若是數據量達到了十幾個G以上的那種，執行一個bgsave會特別慢，save的話會快點，可是也會耗費比較多時間，而且快照文件也比較大。這個時候就須要使用AOF持久化了。

2，AOF持久化

     1簡介

     簡單來講，AOF持久化會將執行的寫命令寫到AOF文件末尾來記錄全部的變化。redis只要從頭至尾執行一次AOF文件的命令，就能夠進行數據恢復了。

     2，配置

     appendonly yes  是否打開AOF持久化

     appendfilename "appendonly.aof"  持久化文件名稱

     # appendfsync always  每次redis寫命令都進行持久化，這樣會嚴重下降redis速度，可是數據基本不丟失

     appendfsync everysec     每秒進行一次，丟失數據也是一秒內的

     # appendfsync no     讓操做系統本身決定何時執行

     no-appendfsync-on-rewrite no

     auto-aof-rewrite-percentage 100  當aof文件比上次重寫以後體積大了至少100%，進行重寫

     auto-aof-rewrite-min-size 64mb     當體積島嶼64M的時候重寫

     上面這兩個條件同時符合的時候才重寫。

     dir /opt/redis-2.8.13/dmp/  持久化文件保存的路徑

     3，AOF文件重寫

     AOF文件因爲會不斷的追加寫入命令，所以體積會愈來愈大，這時向redis發送bgrewriteaof命令，能夠重寫aof，將其中的冗餘命令刪除掉，減少體積，也是主進程fork出一個子進程來處理。針對這個命令也能夠配置一下讓redis本身維護執行。

3，數據恢復

     當redis服務器掛掉時，重啓時將按照如下優先級恢復數據到內存：

     若是隻配置AOF,重啓時加載AOF文件恢復數據；（將rdb的配置信息都註釋掉就關閉了rdb，只要不主動發送bgsave命令就不持久化了）

     若是同時 配置了RBD和AOF,啓動是隻加載AOF文件恢復數據;

     若是隻配置RBD,啓動是講加載dump文件恢復數據。