Redis持久化

RDB

1.RDB介紹

  在指定的時間間隔內將內存中的數據集快照寫入磁盤，也就是行話講的Snapshot快照，它恢復時是將快照文件直接讀到內存裏。

  Redis會單首創建（fork）一個子進程來進行持久化，會先將數據寫入到一個臨時文件中，待持久化過程都結束了，再用這個臨時文件替換上次持久化好的文件。整個過程當中，主進程是不進行任何IO操做的，這就確保了極高的性能若是須要進行大規模數據的恢復，且對於數據恢復的完整性不是很是敏感，那RDB方式要比AOF方式更加的高效。RDB的缺點是最後一次持久化後的數據可能丟失。

  Fork的做用是複製一個與當前進程同樣的進程。新進程的全部數據（變量、環境變量、程序計數器等）數值都和原進程一致，可是是一個全新的進程，並做爲原進程的子進程。

[root@pluto bin]# redis-server /myredis/redis.conf [root@pluto bin]# redis-cli -p 6379 127.0.0.1:6379> set k1 v1 OK 127.0.0.1:6379> set k2 v2 OK 127.0.0.1:6379> set k3 v3 OK 127.0.0.1:6379> set k4 v4 OK 127.0.0.1:6379> set k5 v5 OK 127.0.0.1:6379> set k6 v6 OK 127.0.0.1:6379> set k7 v7 OK 127.0.0.1:6379> set k8 v8 OK 127.0.0.1:6379> set k9 v9 OK 127.0.0.1:6379> set k10 v10 OK 127.0.0.1:6379> set k11 v11 OK 127.0.0.1:6379>

[root@pluto bin]# ls -l 總用量 15456 -rwxr-xr-x. 1 root root 4589115 7月  17 19:20 redis-benchmark -rwxr-xr-x. 1 root root   22177 7月  17 19:20 redis-check-aof -rwxr-xr-x. 1 root root   45387 7月  17 19:20 redis-check-dump -rwxr-xr-x. 1 root root 4693066 7月  17 19:20 redis-cli lrwxrwxrwx. 1 root root      12 7月  17 19:20 redis-sentinel -> redis-server -rwxr-xr-x. 1 root root 6466469 7月  17 19:20 redis-server [root@pluto bin]# ls -l 總用量 15460 -rw-r--r--. 1 root root     101 7月  19 16:19 dump.rdb -rwxr-xr-x. 1 root root 4589115 7月  17 19:20 redis-benchmark -rwxr-xr-x. 1 root root   22177 7月  17 19:20 redis-check-aof -rwxr-xr-x. 1 root root   45387 7月  17 19:20 redis-check-dump -rwxr-xr-x. 1 root root 4693066 7月  17 19:20 redis-cli lrwxrwxrwx. 1 root root      12 7月  17 19:20 redis-sentinel -> redis-server -rwxr-xr-x. 1 root root 6466469 7月  17 19:20 redis-server [root@pluto bin]#

 

[root@pluto bin]# redis-server /myredis/redis.conf [root@pluto bin]# redis-cli -p 6379 127.0.0.1:6379> keys *  1) "k4"  2) "k5"  3) "k3"  4) "k7"  5) "k9"  6) "k6"  7) "k2"  8) "k8"  9) "k10" 10) "k11" 11) "k1"

[root@pluto bin]# rm -f dump.rdb [root@pluto bin]# cp dump_bk.rdb dump.rdb

 

2觸發RDB快照

 

3如何恢復

 

3)優劣勢

 

4如何中止

動態全部中止RDB保存規則的方法：redis-cli config set save ""

5總結

 

  AOF

1.AOF簡介

  以日誌的形式來記錄每一個寫操做，將Redis執行過的全部寫指令記錄下來(讀操做不記錄)，只許追加文件但不能夠改寫文件，redis啓動之初會讀取該文件從新構建數據，換言之，redis重啓的話就根據日誌文件的內容將寫指令從前到後執行一次以完成數據的恢復工做。

2. 開啓AOF

 

[root@pluto bin]# redis-server /myredis/redis_aof.conf [root@pluto bin]# redis-cli -p 6379 127.0.0.1:6379> set k1 v1 OK 127.0.0.1:6379> set k2 v2 OK 127.0.0.1:6379> set k3 v3 OK 127.0.0.1:6379> set k4 v4 OK 127.0.0.1:6379> FLUSHALL OK 127.0.0.1:6379> SHUTDOWN not connected> exit   [root@pluto bin]# redis-server /myredis/redis_aof.conf [root@pluto bin]# redis-cli -p 6379 127.0.0.1:6379> keys * (empty list or set) 127.0.0.1:6379>   #若是想要獲取上一次的k1 k2 k3 k4只須要編輯appendonly.aof移到末尾刪除FLUSHALL便可

[root@pluto bin]# ll

3.修復

[root@pluto bin]# redis-server /myredis/redis_aof.conf [root@pluto bin]# redis-cli -p 6379 Could not connect to Redis at 127.0.0.1:6379: Connection refused not connected> exit [root@pluto bin]# redis-check-aof --fix appendonly.aof 0x              b4: Expected prefix 'a', got: '*' AOF analyzed: size=236, ok_up_to=180, diff=56 This will shrink the AOF from 236 bytes, with 56 bytes, to 180 bytes Continue? [y/N]: y Successfully truncated AOF [root@pluto bin]# redis-server /myredis/redis_aof.conf [root@pluto bin]# redis-cli -p 6379

4.Rewrite

 

5.優劣勢

 

6.總結

 

總結

 

由於RDB文件只用做後備用途，建議只在Slave上持久化RDB文件，並且只要15分鐘備份一次就夠了，只保留save 900 1這條規則。   若是Enalbe AOF，好處是在最惡劣狀況下也只會丟失不超過兩秒數據，啓動腳本較簡單隻load本身的AOF文件就能夠了。代價一是帶來了持續的IO，二是AOF rewrite的最後將rewrite過程當中產生的新數據寫到新文件形成的阻塞幾乎是不可避免的。只要硬盤許可，應該儘可能減小AOF rewrite的頻率，AOF重寫的基礎大小默認值64M過小了，能夠設到5G以上。默認超過原大小100%大小時重寫能夠改到適當的數值。   若是不Enable AOF ，僅靠Master-Slave Replication 實現高可用性也能夠。能省掉一大筆IO也減小了rewrite時帶來的系統波動。代價是若是Master/Slave同時倒掉，會丟失十幾分鐘的數據，啓動腳本也要比較兩個Master/Slave中的RDB文件，載入較新的那個。新浪微博就選用了這種架構