redis學習三 redis持久化

標籤：重寫   min   用戶端   關係   優先   多個   刪除   redis伺服器   save   

 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檔案恢複資料。

redis學習三 redis持久化