RDB備份方式保存數據 · sql

[TOC] # 什么是redis的持久化官網介紹：英文：https://redis.io/topics/persistence 中文：http://www.redis.cn/topics/persistence.html # Redis的RDB是什么在指定的時間間隔內將內存中的數據集快照寫入磁盤，也就是行話講的Snapshot快照，它恢復時是將快照文件直接讀到內存里，Redis會單獨創建（fork）一個子進程來進行持久化，會先將數據寫入到。一個臨時文件中，待持久化過程都結束了，再用這個臨時文件替換上次持久化好的文件。整個過程中，主進程是不進行任何IO操作的，這就確保了極高的性能。如果需要進行大規模數據的恢復，且對于數據恢復的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺點是最后一次持久化后的數據可能丟失。備注解釋： --fork的作用是復制一個與當前進程一樣的進程。新進程的所有數據（變量、環境變量、程序計數器等）數值都和原進程一致，但是是一個全新的進程，并作為原進程的子進程 # Redis配置文件redis.conf中關于RDB的相關配置首先貼出來配置信息 ~~~ ################################ SNAPSHOTTING ################################ # # Save the DB on disk: # # save <seconds> <changes> # # Will save the DB if both the given number of seconds and the given # number of write operations against the DB occurred. # # In the example below the behaviour will be to save: # after 900 sec (15 min) if at least 1 key changed # after 300 sec (5 min) if at least 10 keys changed # after 60 sec if at least 10000 keys changed # # Note: you can disable saving completely by commenting out all "save" lines. # # It is also possible to remove all the previously configured save # points by adding a save directive with a single empty string argument # like in the following example: # # save "" save 900 1 save 300 10 save 60 10000 # By default Redis will stop accepting writes if RDB snapshots are enabled # (at least one save point) and the latest background save failed. # This will make the user aware (in a hard way) that data is not persisting # on disk properly, otherwise chances are that no one will notice and some # disaster will happen. # # If the background saving process will start working again Redis will # automatically allow writes again. # # However if you have setup your proper monitoring of the Redis server # and persistence, you may want to disable this feature so that Redis will # continue to work as usual even if there are problems with disk, # permissions, and so forth. stop-writes-on-bgsave-error yes # Compress string objects using LZF when dump .rdb databases? # For default that's set to 'yes' as it's almost always a win. # If you want to save some CPU in the saving child set it to 'no' but # the dataset will likely be bigger if you have compressible values or keys. rdbcompression yes # Since version 5 of RDB a CRC64 checksum is placed at the end of the file. # This makes the format more resistant to corruption but there is a performance # hit to pay (around 10%) when saving and loading RDB files, so you can disable it # for maximum performances. # # RDB files created with checksum disabled have a checksum of zero that will # tell the loading code to skip the check. rdbchecksum yes # The filename where to dump the DB dbfilename dump.rdb # The working directory. # # The DB will be written inside this directory, with the filename specified # above using the 'dbfilename' configuration directive. # # The Append Only File will also be created inside this directory. # # Note that you must specify a directory here, not a file name. dir ./ ~~~ ## 如何觸發RDB快照 - 配置文件中默認的快照配置 ~~~ save 900 1 save 300 10 save 60 10000 ~~~ save 900 1 #刷新快照到硬盤中，必須滿足兩者要求才會觸發，即900秒之后至少1個關鍵字發生變化。 save 300 10 #必須是300秒之后至少10個關鍵字發生變化。 save 60 10000 #必須是60秒之后至少10000個關鍵字發生變化。（以上3個選項都屏蔽，則rdb禁用） ~~~ stop-writes-on-bgsave-error yes #后臺存儲錯誤停止寫。 rdbcompression yes #使用LZF壓縮rdb文件。 rdbchecksum yes #存儲和加載rdb文件時校驗。 dbfilename dump.rdb #設置rdb文件名。 dir ./ #設置工作目錄，rdb文件會寫入該目錄。 ~~~ 命令save或者是bgsave SAVE：save時只管保存，其它不管，全部阻塞 BGSAVE：Redis會在后臺異步進行快照操作，快照同時還可以響應客戶端請求。可以通過lastsave 命令獲取最后一次成功執行快照的時間 **注：執行flushall命令，也會產生dump.rdb文件，但里面是空的，無意義** ## 默認RDB方式保存的是dump.rdb文件，恢復也是識別的是dump.rdb # 配置位置，以及快照恢復查看目錄 CONFIG GET dir獲取目錄 **將備份文件 (dump.rdb) 移動到 redis 安裝目錄并啟動服務即可或者就在當前目錄啟動** 舉例：我的redis啟動服務的目錄是 /usr/local/bin 下面我啟動redis的目錄是/root 下面，然后生成的的dump.rdb 文件也是在/root 目錄下，假如redis服務器出現問題，掛掉了。那么想要根據rdb恢復數據（1）將備份文件 (dump.rdb) 移動到 redis 安裝目錄并啟動服務（2）當前目錄啟動如果我的dump.rdb 在/root下面，而我到/usr/local/bin這個目錄下去啟動了redis，那么數據是無法恢復的。只能從 /root 下面啟動才能看到之前保存的數據。如下操作： ~~~ 127.0.0.1:6379> CONFIG GET dir #獲取當前操作的目錄 1) "dir" 2) "/root" 127.0.0.1:6379> KEYS * #redis中存在的key 1) "myhash" 2) "k3" 3) "mylist" 4) "b1" 5) "du1" 6) "k1" 7) "b4" 8) "key1" 9) "d" 10) "myset" 11) "du11" 12) "list" 13) "b3" 14) "du" 15) "b2" 16) "skey" 17) "k2" 127.0.0.1:6379> ~~~ 下面我關閉redis，假設redis服務掛掉！ ~~~ 127.0.0.1:6379> SHUTDOWN #關閉服務器 [root@localhost ~]# pwd #當前目錄是/root /root [root@localhost ~]# ll #下面有dump.rdb這個文件總用量 52 -rw-------. 1 root root 1208 6月 14 08:10 anaconda-ks.cfg drwxr-xr-x. 3 root root 4096 6月 17 04:35 dufy -rw-r--r--. 1 root root 283 6月 19 00:13 dump.rdb -rw-r--r--. 1 root root 24772 6月 14 08:10 install.log -rw-r--r--. 1 root root 7690 6月 14 08:09 install.log.syslog ~~~ 那么當我進入/usr/local/bin 目錄下啟動重新啟動redis，看數據是否恢復 ~~~ [root@localhost ~]# cd /usr/local/bin/ [root@localhost bin]# pwd /usr/local/bin [root@localhost bin]# redis-server /root/dufy/redis/redis-3.0.4/redis.conf [root@localhost bin]# redis-cli 127.0.0.1:6379> KEYS * # 這里啟動后，查看key沒有恢復 (empty list or set) 127.0.0.1:6379> ~~~ 那么我再次關閉服務，從/root下啟動redis看數據是否恢復 ~~~ 127.0.0.1:6379> SHUTDOWN not connected> exit [root@localhost bin]# cd /root/ [root@localhost ~]# pwd /root [root@localhost ~]# redis-server /root/dufy/redis/redis-3.0.4/redis.conf [root@localhost ~]# redis-cli 127.0.0.1:6379> KEYS * #重啟后，查看key，發現恢復成功了！ 1) "k1" 2) "b1" 3) "key1" 4) "list" 5) "du11" 6) "du1" 7) "b4" 8) "k3" 9) "myhash" 10) "b3" 11) "d" 12) "skey" 13) "mylist" 14) "du" 15) "k2" 16) "b2" 17) "myset" 127.0.0.1:6379> ~~~ 相信我這些操作，也講明白快照恢復，上面說的這一句：將備份文件 (dump.rdb) 移動到 redis 安裝目錄并啟動服務即可或者就在當前目錄啟動。 # Redis優點適合大規模的數據恢復對數據完整性和一致性要求不高 # Redis缺點在一定間隔時間做一次備份，所以如果redis意外down掉的話，就會丟失最后一次快照后的所有修改 fork的時候，內存中的數據被克隆了一份，大致2倍的膨脹性需要考慮 # 如何停止RDB ## 配置文件注釋掉 ~~~ save 900 1 save 300 10 save 60 10000 ~~~ 啟動 # save “”，去掉 #。保存后重啟 ## 動態停止RDB命令在redis-cli中執行： ~~~ config set save "" ~~~ # 大總結內存中的數據對象 --->rdbsave --> 磁盤中的rdb文件內存中的數據對象 <---rdload <-- 磁盤中的rdb文件 * RDB是一個非常緊湊的文件 * RDB在保存RDB文件時父進程唯一需要做的就是foker出一個子進程，接下來工作全部交給子進程來做，父進程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能 * 與AOF相比，在恢復大的數據時候，RDB方式更快一些 * 數據丟失風險大 * RDB需要經常folk子進程來保存數據集到磁盤，當數據集比較大額時候，folk的過程是比較耗時的，可能會導致redis在一些毫秒級不能響應客服端請