redis學習3---持久化

1、默認持久化

表示在900s存一個對象，300s存10個對象，60s存10000個對象時就會自動觸發RDB的持久化

save 900 1

save 300 10

save 60 10000

快照文件名，可自定義

dbfilename dump.rdb

快照文件保存目錄

dir ./

如果bgsave出現錯誤,是否停止寫入，一般都配置為yes

stop-writes-on-bgsave-error yes

開啟壓縮rdb

rdbcompression yes?

檢驗和

rdbchecksum yes

如果想要關閉快照持久化，做下面修改：

注釋快照持久化規則

#save 900 1

#save 300 10

#save 60 10000

設置為空

save ""

之后重啟redis

備份 save 說明：

可以使用 SAVE 和 BGSAVE 命令手動備份，兩者有區別 ： SAVE命令表示使用主進程將當前數據庫快照到dump文件 ， BGSAVE命令表示，主進程會fork一個子進程來進行快照備份。前者會阻塞主進程，而后者不會，所以一般使用BGSAVE進行手動備份。

可以使用命令關閉db，不需要重啟服務

config set save ""

查看是否生效

config get save

2、如果想使用aof方式做持久化

開啟appendonlylog，開啟的話每次寫操作會記一條log。相當于mysql的binlog；不同的是，每次redis啟動都會讀此文件構建完整數據。即使刪除rdb文件，數據也是安全的

appendonly no

>>

appendonly yes?

aof文件保存目錄和文件名可以自定義

dir ./

appendfilename "appendonly.aof"

aof策略，每秒鐘強制寫入磁盤一次

appendfsync everysec

在重寫時是否不需要append,這個配置需要根據實際權衡，因為在重寫的同時進行append會有性能開銷，當然如果不append也可能會丟失少量數據，以性能為優先的時候關閉append

no-appendfsync-on-rewrite no

>>

no-appendfsync-on-rewrite yes

使用命令關閉aof

config set appendfsync no?

查看是否生效

config get appendfsync

3、RDB和AOF方式持久化比較

RDB觸發機制：

save(同步)

執行一條save命令,就會生成一個RDB文件

阻塞（保存是阻塞主進程，客戶端無法連接redis，等SAVE完成后，主進程才開始工作，客戶端可以連接）

bgsave(異步)

執行bgsave命令

fork()一個子進程在后臺去創建RDB文件

不影響主進程，客戶端可以正常鏈接redis，等子進程fork執行save完成后，通知主進程，子進程關閉。

RDB持久化是指在指定的時間間隔內將內存中的數據和操作通過快照的方式保存到dump.rdb文件，RDB 是一個非常緊湊（compact）的文件，本身文件比較小， 這種文件非常適合用于進行備份。恢復直接載入到內存即可，所以恢復數據比較快。但是如果服務器在非備份時間跨度內發生了故障，無法做到對當前狀態的實時保存，導致數據丟失，另外遇到宕機等情況的時候快照的數據可能會不完整。每次保存 RDB文件時，save會阻塞Redis， bgsave不會阻塞Redis，但是需要 fork()出一個子進程，由子進程來執行具體的持久化工作，在數據集比較龐大時，fork()可能會非常耗時，造成服務器在某某毫秒內停止處理客戶端，對CPU資源消耗較大，甚至可能使得這種停止時間長達整整一秒。

AOF持久化是在每次接受到的寫命令通過 write函數追加到appendonly.aof文件，使用策略可以最大限度的保證意外情況下的數據完整性，每秒鐘一次 fsync ，或者每次執行寫入命令時 fsync。AOF 的默認策略為每秒鐘 fsync 一次，在這種配置下，Redis 仍然可以保持良好的性能，并且就算發生故障停機，也最多只會丟失一秒鐘的數據，（ fsync 會在后臺線程執行，所以主線程可以繼續努力地處理命令請求）。因為 AOF 的運作方式是不斷地將命令追加到文件的末尾，恢復數據就是逐條的執行命令，所以隨著寫入命令的不斷增加， AOF 文件的體積也會變得越來越大，也會使得恢復過程變得漫長。

兩種方式恢復數據：

RDB：

制定策略，自動定時的把dump.rdb文件備份到備機上，恢復過程就是把備機的文件拷貝到redis服務器快照文件存放目錄下，命名為dump.rdb，然后啟動redis服務即可。

AOF：

假如當不小心執行了 flushall 清除了所有的數據后，打開 appendonly.aof 的文件，刪除末尾的命令 flushall ，最好利用 redis-check-aof這個工具來檢測一下你修改過后的 aof 文件是否正常，以防啟動恢復數據的時候出錯，顯示 AOF is valid aof 說明文件是有效的，那么可以重啟 redis 恢復數據了。

兩種方式選擇：

只做緩存，如果希望數據在服務器運行的時候存在，可以不使用任何持久化。

如果可以忍受一段時間的數據丟失可以使用RDB方式

如果要求數據實時備份，就需要選擇AOF方式

建議同時開啟兩種持久化：

在這種情況下,當redis重啟的時候會優先載入AOF文件來恢復原始的數據

不建議只使用AOF，因為AOF持久化存在潛在的BUG

RDB文件用作后備用途，建議只保留 save 900 1 這條規則

應該盡量減少AOF rewrite的頻率，AOF重寫的基礎大小默認值64M太小，可以設到5G以上。默認超過原大小100%大小時重寫可以改到適當的數值。

4、解決redis aof文件過大的問題

執行BGREWRITEAOF命令對redis的AOF進行重寫

redis-cli BGREWRITEAOF

AOF重寫：

(1) 隨著AOF文件越來越大，里面會有大部分是重復命令或者可以合并的命令（100次incr = set key 100）

(2) 重寫的好處：減少AOF日志尺寸，減少內存占用，加快數據庫恢復時間。

執行一個 AOF文件重寫操作，重寫會創建一個當前 AOF 文件的體積優化版本。

即使 BGREWRITEAOF 執行失敗，也不會有任何數據丟失，因為舊的 AOF 文件在 BGREWRITEAOF 成功之前不會被修改。

默認自動觸發重寫規則

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

percentage是指，當redis當前的aof文件大小相對于上一次進行rewriteaof操作時的大小增長率大于100%時，就會進行rewrite。

但是，當增長率大于了100%，實際上aof文件其實很小，這樣rewrite就沒有必要了，所以，還需要設置一個min-size，當redis的增長率大于100%，并且min-size的大于64mb時，就會執行rewriteaof操作。

5、RDB和AOF其他

5.1、重寫

如果想關閉rewriteaof操作，可以將percentage設置為0。

redis會在以下三個時候進行rewrite操作

Redis接收到客戶端發送的bgrewriteaof命令

Redis aof文件增長率和增長大小達到auto-aof-rewrite

Redis接收到客戶端發送的”CONFIG SET appendonly yes”命令

5.2、 數據恢復順序

當redis重啟時，會按照以下優先級進行啟動：

如果只配置AOF,重啟時加載AOF文件恢復數據；

如果同時 配置了RBD和AOF,啟動是只加載AOF文件恢復數據;

如果只配置RBD,啟動時將加載dump文件恢復數據。

5.3、AOF配置文件損壞修復方法

對于錯誤格式的AOF文件，先進行備份，然后采用redis-check-aof--fix命令進行修復，修復后使用diff-u對比數據的差異，找出丟失的數據，有些可以人工修改補全。AOF文件可能存在結尾不完整的情況，比如機器突然掉電導致AOF尾部文件命令寫入不全。Redis為我們提供了aof-load-truncated配置來兼容這種情況，默認開啟。加載AOF時，當遇到此問題時會忽略并繼續啟動。