關於redis持久化

来源:http://www.cnblogs.com/chenpingzhao/archive/2016/01/26/5158791.html
-Advertisement-
Play Games

Redis有兩種持久化的方式：快照（RDB文件）和追加式文件（AOF文件）RDB持久化方式是在一個特定的間隔保存某個時間點的一個數據快照。AOF（Append only file）持久化方式則會記錄每一個伺服器收到的寫操作。數據回覆時，這些記錄的操作會逐條執行從而重建出原來的數據。寫操作命令 記錄的...


Redis有兩種持久化的方式：快照（RDB文件）和追加式文件（AOF文件）

  • RDB持久化方式是在一個特定的間隔保存某個時間點的一個數據快照。

  • AOF（Append only file）持久化方式則會記錄每一個伺服器收到的寫操作。數據回覆時，這些記錄的操作會逐條執行從而重建出原來的數據。寫操作命令  記錄的格式跟Redis協議一致，以追加的方式進行保存。

Redis的持久化是可以禁用的，兩種方式的持久化是可以同時存在的，但是當Redis重啟時，AOF文件會被優先用於重建數據。

一、RDB

RDB就是Snapshot存儲，是預設的持久化方式。按照一定的策略周期性的將數據保存到磁碟。對應產生的數據文件為dump.rdb，通過配置文件中的save參數來定義快照的周期。Redis支持將當前數據的快照存成一個數據文件實現持久化。而一個持續寫入的資料庫如何生成快照呢。Redis藉助了fork命令的copy on write機制。在生成快照時，將當前進程fork出一個子進程，然後在子進程中迴圈所有的數據，將數據寫成為RDB文件。

Client 也可以使用save或者bgsave命令通知redis做一次快照持久化。save操作是在主線程中保存快照的，由於redis是用一個主線程來處理所有 client的請求，這種方式會阻塞所有client請求，所以不推薦使用。另一點需要註意的是，每次快照持久化都是將記憶體數據完整寫入到磁碟一次，並不 是增量的只同步臟數據。如果數據量大的話，而且寫操作比較多，必然會引起大量的磁碟io操作，可能會嚴重影響性能。 

Redis的RDB文件不會壞掉，因為其寫操作是在一個新進程中進行的。當生成一個新的RDB文件時，Redis生成的子進程會先將數據寫到一個臨時文件中，然後通過原子性rename系統調用將臨時文件重命名為RDB文件。這樣在任何時候出現故障，Redis的RDB文件都總是可用的。並且Redis的RDB文件也是Redis主從同步內部實現中的一環

主從同步

第一次Slave向Master同步的實現是：

Slave向Master發出同步請求，Master先dump出rdb文件，然後將rdb文件全量傳輸給slave，然後Master把緩存的命令轉發給Slave，初次同步完成。

第二次以及以後的同步實現是：

Master將變數的快照直接實時依次發送給各個Slave。但不管什麼原因導致Slave和Master斷開重連都會重覆以上兩個步驟的過程。

Redis的主從複製是建立在記憶體快照的持久化基礎上的，只要有Slave就一定會有記憶體快照發生。

工作原理

  • Redis調用fork()，產生一個子進程。

  • 父進程繼續處理client請求，子進程把記憶體數據寫到一個臨時的RDB文件。由於os的寫時複製機制（copy on write)父子進程會共用相同的物理頁面，當父進程處理寫請求時os會為父進程要修改的頁面創建副本，而不是寫共用的頁面。所以子進程的地址空間內的數據是fork時刻整個資料庫的一個快照。

  • 當子進程將快照寫入臨時文件完畢後，用臨時文件替換原來的快照文件，然後子進程退出

優點

  • RDB文件是一個很簡潔的單文件，它保存了某個時間點的Redis數據，很適合用於做備份。你可以設定一個時間點對RDB文件進行歸檔，這樣就能在需要的時候很輕易的把數據恢復到不同的版本。

  • RDB很適合用於災備。單文件很方便就能傳輸到遠程的伺服器上。

  • RDB的性能很好，需要進行持久化時，主進程會fork一個子進程出來，然後把持久化的工作交給子進程，自己不會有相關的I/O操作。

  • 比起AOF，在數據量比較大的情況下，RDB的啟動速度更快。

缺點

  • RDB容易造成數據的丟失。假設每5分鐘保存一次快照，如果Redis因為某些原因不能正常工作，那麼從上次產生快照到Redis出現問題這段時間的數據就會丟失了。

  • RDB使用fork()產生子進程進行數據的持久化，如果數據比較大的話可能就會花費點時間，造成Redis停止服務幾毫秒。如果數據量很大且CPU性能不是很好的時候，停止服務的時間甚至會到1秒。

文件路徑和名稱

預設Redis會把快照文件存儲為當前目錄下一個名為dump.rdb的文件。要修改文件的存儲路徑和名稱，可以通過修改配置文件redis.conf實現：

# RDB文件名，預設為dump.rdb。
dbfilename dump.rdb

# 文件存放的目錄，AOF文件同樣存放在此目錄下。預設為當前工作目錄。
dir ./

保存點（RDB的啟用和禁用）

你可以配置保存點，使Redis如果在每N秒後數據發生了M次改變就保存快照文件。例如下麵這個保存點配置表示每60秒，如果數據發生了1000次以上的變動，Redis就會自動保存快照文件：

save 60 1000

保存點可以設置多個，Redis的配置文件就預設設置了3個保存點：

# 格式為：save <seconds> <changes>
# 可以設置多個。
save 900 1 #900秒後至少1個key有變動
save 300 10 #300秒後至少10個key有變動
save 60 10000 #60秒後至少10000個key有變動

如果想禁用快照保存的功能，可以通過註釋掉所有"save"配置達到，或者在最後一條"save"配置後添加如下的配置：

save ""

錯誤處理

預設情況下，如果Redis在後臺生成快照的時候失敗，那麼就會停止接收數據，目的是讓用戶能知道數據沒有持久化成功。但是如果你有其他的方式可以監控到Redis及其持久化的狀態，那麼可以把這個功能禁止掉。

stop-writes-on-bgsave-error yes

數據壓縮

預設Redis會採用LZF對數據進行壓縮。如果你想節省點CPU的性能，你可以把壓縮功能禁用掉，但是數據集就會比沒壓縮的時候要打。

rdbcompression yes

數據校驗

從版本5的RDB的開始，一個CRC64的校驗碼會放在文件的末尾。這樣更能保證文件的完整性，但是在保存或者載入文件時會損失一定的性能（大概10%）。如果想追求更高的性能，可以把它禁用掉，這樣文件在寫入校驗碼時會用0替代，載入的時候看到0就會直接跳過校驗

rdbchecksum yes

手動生成快照

Redis提供了兩個命令用於手動生成快照。

SAVE

SAVE命令會使用同步的方式生成RDB快照文件，這意味著在這個過程中會阻塞所有其他客戶端的請求。因此不建議在生產環境使用這個命令，除非因為某種原因需要去阻止Redis使用子進程進行後臺生成快照（例如調用fork(2)出錯）。

BGSAVE

BGSAVE命令使用後臺的方式保存RDB文件，調用此命令後，會立刻返回OK返回碼。Redis會產生一個子進程進行處理並立刻恢復對客戶端的服務。在客戶端我們可以使用LASTSAVE命令查看操作是否成功。

127.0.0.1:6379> BGSAVE
Background saving started
127.0.0.1:6379> LASTSAVE
(integer) 1433936394

配置文件里禁用了快照生成功能不影響SAVE和BGSAVE命令的效果。

二、AOF

快照並不是很可靠。如果伺服器突然Crash了，那麼最新的數據就會丟失。而AOF文件則提供了一種更為可靠的持久化方式。每當Redis接受到會修改數據集的命令時，就會把命令追加到AOF文件里，當你重啟Redis時，AOF里的命令會被重新執行一次，重建數據

原理

  • redis調用fork ，現在有父子兩個進程

  • 子進程根據記憶體中的資料庫快照，往臨時文件中寫入重建資料庫狀態的命令

  • 父進程繼續處理client請求，除了把寫命令寫入到原來的aof文件中。同時把收到的寫命令緩存起來。這樣就能保證如果子進程重寫失敗的話並不會出問題

  • 當子進程把快照內容寫入已命令方式寫到臨時文件中後，子進程發信號通知父進程。然後父進程把緩存的寫命令也寫入到臨時文件

  • 現在父進程可以使用臨時文件替換老的aof文件，並重命名，後面收到的寫命令也開始往新的aof文件中追加

優點

  • 比RDB可靠。你可以制定不同的fsync策略：不進行fsync、每秒fsync一次和每次查詢進行fsync。預設是每秒fsync一次。這意味著你最多丟失一秒鐘的數據。

  • AOF日誌文件是一個純追加的文件。就算伺服器突然Crash，也不會出現日誌的定位或者損壞問題。甚至如果因為某些原因（例如磁碟滿了）命令只寫了一半到日誌文件里，我們也可以用redis-check-aof這個工具很簡單的進行修複。

  • 當AOF文件太大時，Redis會自動在後臺進行重寫。重寫很安全，因為重寫是在一個新的文件上進行，同時Redis會繼續往舊的文件追加數據。新文件上會寫入能重建當前數據集的最小操作命令的集合。當新文件重寫完，Redis會把新舊文件進行切換，然後開始把數據寫到新文件上。

  • AOF把操作命令以簡單易懂的格式一條接一條的保存在文件里，很容易導出來用於恢複數據。例如我們不小心用FLUSHALL命令把所有數據刷掉了，只要文件沒有被重寫，我們可以把服務停掉，把最後那條命令刪掉，然後重啟服務，這樣就能把被刷掉的數據恢復回來。

缺點

  • 在相同的數據集下，AOF文件的大小一般會比RDB文件大。

  • 在某些fsync策略下，AOF的速度會比RDB慢。通常fsync設置為每秒一次就能獲得比較高的性能，而在禁止fsync的情況下速度可以達到RDB的水平。

  • 在過去曾經發現一些很罕見的BUG導致使用AOF重建的數據跟原數據不一致的問題。

啟用AOF

把配置項appendonly設為yes：

appendonly yes

文件路徑和名稱

# 文件存放目錄，與RDB共用。預設為當前工作目錄。
dir ./

# 預設文件名為appendonly.aof
appendfilename "appendonly.aof"

可靠性

你可以配置Redis調用fsync的頻率，有三個選項：

  • 每當有新命令追加到AOF的時候調用fsync。速度最慢，但是最安全。

  • 每秒fsync一次。速度快（2.4版本跟快照方式速度差不多），安全性不錯（最多丟失1秒的數據）。

  • 從不fsync，交由系統去處理。這個方式速度最快，但是安全性沒有保證

推薦使用每秒fsync一次的方式（預設的方式），因為它速度快，安全性也不錯。相關配置如下：

# appendfsync always
appendfsync everysec
# appendfsync no

日誌重寫

隨著寫操作的不斷增加，AOF文件會越來越大。例如你遞增一個計數器100次，那麼最終結果就是數據集里的計數器的值為最終的遞增結果，但是AOF文件里卻會把這100次操作完整的記錄下來。而事實上要恢復這個記錄，只需要1個命令就行了，也就是說AOF文件里那100條命令其實可以精簡為1條。所以Redis支持這樣一個功能：在不中斷服務的情況下在後臺重建AOF文件。

工作原理如下：

  • Redis調用fork()，產生一個子進程。

  • 子進程把新的AOF寫到一個臨時文件里。

  • 主進程持續把新的變動寫到記憶體里的buffer，同時也會把這些新的變動寫到舊的AOF里，這樣即使重寫失敗也能保證數據的安全。

  • 當子進程完成文件的重寫後，主進程會獲得一個信號，然後把記憶體里的buffer追加到子進程生成的那個新AOF里。

我們可以通過配置設置日誌重寫的條件：

#在日誌重寫時，不進行命令追加操作，而只是將其放在緩衝區里，避免與命令的追加造成DISK IO上的衝突。
#設置為yes表示rewrite期間對新寫操作不fsync,暫時存在記憶體中,等rewrite完成後再寫入，預設為no，建議yes
no-appendfsync-on-rewrite yes 

# Redis會記住自從上一次重寫後AOF文件的大小（如果自Redis啟動後還沒重寫過，則記住啟動時使用的AOF文件的大小）。
# 如果當前的文件大小比起記住的那個大小超過指定的百分比，則會觸發重寫。
# 同時需要設置一個文件大小最小值，只有大於這個值文件才會重寫，以防文件很小，但是已經達到百分比的情況。

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

要禁用自動的日誌重寫功能，我們可以把百分比設置為0：

auto-aof-rewrite-percentage 0

Redis 2.4以上才可以自動進行日誌重寫，之前的版本需要手動運行BGREWRITEAOF這個命令。

數據損壞修複

如果因為某些原因（例如伺服器崩潰）AOF文件損壞了，導致Redis載入不了，可以通過以下方式進行修複：

  • 備份AOF文件。

  • 使用redis-check-aof命令修複原始的AOF文件：

    $ redis-check-aof --fix

  • 可以使用diff -u命令看下兩個文件的差異。

  • 使用修複過的文件重啟Redis服務。

從RDB切換到AOF

這裡只說Redis >= 2.2版本的方式：

  • 備份一個最新的dump.rdb的文件，並把備份文件放在一個安全的地方。

  • 運行以下兩條命令：

    $ redis-cli config set appendonly yes
$ redis-cli config set save ""

  • 確保數據跟切換前一致。

  • 確保數據正確的寫到AOF文件里。

第二條命令是用來禁用RDB的持久化方式，但是這不是必須的，因為你可以同時啟用兩種持久化方式。

記得對配置文件redis.conf進行編輯啟用AOF，因為命令行方式修改配置在重啟Redis後就會失效。

從上面看出，RDB和AOF操作都是順序IO操作，性能都很高。而同時在通過RDB文件或者AOF日誌進行資料庫恢復的時候，也是順序的讀取數據載入到記憶體中。所以也不會造成磁碟的隨機讀。

到底選擇什麼呢？下麵是來自官方的建議：

通常，如果你要想提供很高的數據保障性，那麼建議你同時使用兩種持久化方式。如果你可以接受災難帶來的幾分鐘的數據丟失，那麼你可以僅使用RDB。很多用戶僅使用了AOF，但是我們建議，既然RDB可以時不時的給數據做個完整的快照，並且提供更快的重啟，所以最好還是也使用RDB。

在數據恢復方面：RDB的啟動時間會更短，原因有兩個

  • 一是RDB文件中每一條數據只有一條記錄，不會像AOF日誌那樣可能有一條數據的多次操作記錄。所以每條數據只需要寫一次就行了。

  • 另一個原因是RDB文件的存儲格式和Redis數據在記憶體中的編碼格式是一致的，不需要再進行數據編碼工作，所以在CPU消耗上要遠小於AOF日誌的載入。 

註意：

上面說了RDB快照的持久化，需要註意：在進行快照的時候（save），fork出來進行dump操作的子進程會占用與父進程一樣的記憶體，真正的copy-on-write，對性能的影響和記憶體的耗用都是比較大的。比如機器8G記憶體，Redis已經使用了6G記憶體，這時save的話會再生成6G，變成12G，大於系統的8G。這時候會發生交換；要是虛擬記憶體不夠則會崩潰，導致數據丟失。所以在用redis的時候一定對系統記憶體做好容量規劃。

目前，通常的設計思路是利用Replication機制來彌補aof、snapshot性能上的不足，達到了數據可持久化。即Master上Snapshot和AOF都不做，來保證Master的讀寫性能，而Slave上則同時開啟Snapshot和AOF來進行持久化，保證數據的安全性。

三、對Redis持久化的測試

通過上面的理論對snapshot和aof有了一定的理解，下麵開始進行一些測試

1、redis.conf 開啟snapshot 關閉aof

save 900 1
save 300 10
save 60 10000

rdbcompression no
rdbchecksum no
dbfilename redis.rdb
dir /home/backup/redis

appendonly  no

測試

[root@localhost redis]# ./src/redis-cli 
127.0.0.1:6379> keys *
1) "a"
127.0.0.1:6379> set b 2
OK
127.0.0.1:6379> set c 3
OK
127.0.0.1:6379> set d 4
OK
127.0.0.1:6379> keys *
1) "c"
2) "a"
3) "aa"
4) "b"
5) "d"
127.0.0.1:6379> save
OK
#保存，進行持久化，每執行一次save，會在日至裡面記錄一條：" * DB saved on disk "

127.0.0.1:6379> lpush aa 1
(integer) 1
127.0.0.1:6379> lpush aa 2
(integer) 2

持久化驗證，重啟redis

127.0.0.1:6379> keys *
1) "c"
2) "a"
3) "aa"
4) "b"
5) "d"

lpush 操作在 save之後，但是重啟之後仍然有這個數據

什麼原因呢，我們可以查看一下日誌 

6720:signal-handler (1453738444) Received SIGTERM scheduling shutdown...
6720:M 26 Jan 00:14:04.896 # User requested shutdown...
6720:M 26 Jan 00:14:04.896 * Saving the final RDB snapshot before exiting.
6720:M 26 Jan 00:14:04.932 * DB saved on disk
6720:M 26 Jan 00:14:04.932 * Removing the pid file.
6720:M 26 Jan 00:14:04.932 # Redis is now ready to exit, bye bye...

從日誌裡面可以看到，正常關閉redis，在關閉前執行save命令。 用kill的效果和上面一樣，屬於正常關閉

那異常關閉呢？當以kill -9 的形式發送信號

127.0.0.1:6379> set ss 1
Could not connect to Redis at 127.0.0.1:6379: Connection refused
not connected> get ss
Could not connect to Redis at 127.0.0.1:6379: Connection refused
not connected> get ss
(nil)

通過測試，開啟RDB持久化，在滿足save條件、手動save、正常關閉的時候數據都會被持久化；而異常關閉終止的時候數據會丟失

2、redis.conf 關閉snapshot，關閉aof

#save 900 1
#save 300 10
#save 60 10000
rdbcompression no
rdbchecksum no
dbfilename redis.rdb
dir ./

appendonly  no

操作

redis 127.0.0.1:6379> keys * 
(empty list or set)
redis 127.0.0.1:6379> set name test
OK
redis 127.0.0.1:6379> save
OK
redis 127.0.0.1:6379> set aa 1
OK
redis 127.0.0.1:6379> 

#重啟redis

redis 127.0.0.1:6379> keys *                          #發現剛纔沒有被保存的key丟失了
1) "name"

從上面的結果看出，關閉持久化，只有在手動save的時候數據都會被持久化，正常關閉的時候數據丟失。如果從一開始到關閉寫入數據的期間沒有手動save，則數據全部丟失，既然能手動save間接的說明瞭快照一直都存在，所以不能說是禁止snapshot，應該是禁止自動snapshot功能。

3、redis.conf 關閉snapshot，開啟aof

appendonly  yes
appendfilename redis.aof
# appendfsync always
appendfsync everysec
# appendfsync no

no-appendfsync-on-rewrite no
auto-aof-rewrite-min-size 64mb

 操作

redis 127.0.0.1:6379> keys *
1) "name"

#修改開啟AOF參數，重啟資料庫：

redis 127.0.0.1:6379> keys *
(empty list or set)
redis 127.0.0.1:6379> 

#資料庫裡面沒有記錄
#查看日誌：
#* DB loaded from append only file: 0.000 seconds
#發現是從0位元組的aof文件裡面同步數據，為什麼不同步rdb的數據？原來redis代碼裡面寫好了優先順序，AOF>RDB

查看源代碼 redis.c   grep 'DB loaded from' ./ -R

void loadDataFromDisk(void) {
    long long start = ustime();
    if (server.aof_state == REDIS_AOF_ON) {
        if (loadAppendOnlyFile(server.aof_filename) == REDIS_OK)
            redisLog(REDIS_NOTICE,"DB loaded from append only file: %.3f seconds",(float)(ustime()-start)/1000000);
    } else {
        if (rdbLoad(server.rdb_filename) == REDIS_OK) {
            redisLog(REDIS_NOTICE,"DB loaded from disk: %.3f seconds",
                (float)(ustime()-start)/1000000);
        } else if (errno != ENOENT) {
            redisLog(REDIS_WARNING,"Fatal error loading the DB: %s. Exiting.",strerror(errno));
            exit(1);
        }    
    }
}

這裡需要註意的是:當中途開啟AOF，重啟讓生效的時候，不能第2次正常重啟了

因為第一次重啟讓aof生效的時候，啟動redis已經讀取這個文件了，導致此時的redis數據為空的（優先順序）。第二次重啟，則會把這個空的數據save到RDB文件，這樣導致RDB原有的數據被替換，導致數據丟失。所以一定要小心，為了避免悲劇的發生，當要重啟redis的時候最好都備份下RDB文件。

redis 127.0.0.1:6379> keys *
(empty list or set)
redis 127.0.0.1:6379> set name tt
OK
redis 127.0.0.1:6379> save
OK

#開啟aof參數
#第一次重啟
redis 127.0.0.1:6379> keys *   #如上面所說的優先順序原因:aof > rdb，結果為空
(empty list or set)


#第2次正常重啟，把上面空的結果save到了RDB，數據丟失。此時的db是空的，日誌記錄 "* DB saved on disk"
redis 127.0.0.1:6379> keys *
(empty list or set)

#數據已經被初始化了，數據丟失

這裡就有一個問題，比如在用redis的時候，剛開始只開啟RDB的持久方式，AOF沒有開啟，在跑一段時間之後想開啟AOF，那如何把RDB的數據直接寫到AOF文件呢？有2種方法

a、在開啟AOF之前，先執行bgrewriteaof，再重啟

redis 127.0.0.1:6379> keys *                   #查看是否有數據
(empty list or set)
redis 127.0.0.1:6379> set name ttd
OK
redis 127.0.0.1:6379> keys *
1) "name"

redis 127.0.0.1:6379> bgsave                   #保存數據
Background saving started
redis 127.0.0.1:6379> keys *
1) "name"

#只有一個RDB文件，沒有AOF文件

redis 127.0.0.1:6379> bgrewriteaof             #執行合併重寫功能，生成AOF文件
Background append only file rewriting started

#這時候去打開redis.conf 文件中的aof參數（appendonly yes），重啟生效。
#日誌裡面出現：* DB loaded from append only file: 0.000 seconds

redis 127.0.0.1:6379> keys *                    #數據還在
1) "name"


#查看文件
[root@localhost data]# od -c redis.aof 
0000000   *   2  \r  \n   $   6  \r  \n   S   E   L   E   C   T  \r  \n
0000020   $   1  \r  \n   0  \r  \n   *   3  \r  \n   $   3  \r  \n   S
0000040   E   T  \r  \n   $   4  \r  \n   n   a   m   e  \r  \n   $   4
0000060  \r  \n   j   a   c   k  \r  \n
0000070　

b、利用CONFIG GET/SET 的方法動態修改配置文件

redis 127.0.0.1:6379> BGSAVE
Background saving started
#此時，只有rdb文件

#動態修改參數，把aof功能開啟：appendonly yes
redis 127.0.0.1:6379> CONFIG SET appendonly yes        #動態修改參數
OK
redis 127.0.0.1:6379> CONFIG GET append*
1) "appendonly"
2) "yes"
3) "appendfsync"
4) "everysec"
redis 127.0.0.1:6379>

#aof文件已經生成，並且有數據（同步rdb）

#日誌裡面的信息：* Background append only file rewriting started by pid 3165
#因為參數是動態修改的，在重啟之後會失效，所以在維護的時候修改redis.conf文件的參數即可

從上面的結果看出，redis重啟載入數據的時候，讀取aof的文件要先於rdb文件，所以儘量一開始開啟aof選項，不要在中途開啟。

通過日誌可以很清楚的知道redis通過那個文件來取數據的：

RDB:   * DB loaded from disk: 0.000 seconds
AOF： * DB loaded from append only file: 0.000 seconds

保存數據則是

RDB：* DB saved on disk
AOF:  * Calling fsync() on the AOF file

4、redis.conf 開啟snapshot，開啟aof

save 900 1
save 300 10
save 60 10000

appendonly  yes
appendfilename zhoujy.aof
# appendfsync always
appendfsync everysec
# appendfsync no

no-appendfsync-on-rewrite no
auto-aof-rewrite-min-size 64mb

通過上面的這些測試，已經說明RDB和AOF他們的操作方式，以及如重啟時的載入，重啟時將按照以下優先順序恢複數據到記憶體：

  • 如果只配置AOF,重啟時載入AOF文件恢複數據

  • 如果同時 配置了RBD和AOF,啟動是只載入AOF文件恢複數據

  • 如果只配置RDB,啟動時候載入dump文件恢複數據

四、Redis數據備份

備份很簡單，只需要把RDB，AOF的文件複製備份起來就可以了

#redisA: A上生成測試數據
redis 127.0.0.1:6379> set name test
7.0.0.1:6379> set age 17
OK
redis 127.0.0.1:6379> keys *
1) "age"

redis 127.0.0.1:6379> bgsave
Background saving started

#redisB: B上沒有數據
redis 127.0.0.1:6380> keys *
(empty list or set)

#複製A的文件到B（rdb和aof文件）
cp redis/* redis2/  
#修改許可權
chown -R redis.redis *
#重啟B 還原
redis 127.0.0.1:6380> keys *
1) "sex"

 

參考

http://redis.io/topics/persistence
http://www.cnblogs.com/zhoujinyi/archive/2013/05/26/3098508.html
http://heylinux.com/archives/1932.html
http://database.51cto.com/art/201203/322144.htm


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • springmvc mybatis（oracle 和 mysql資料庫）
    獲取【下載地址】 QQ: 313596790 【免費支持更新】A 代碼生成器(開發利器); 增刪改查的處理類，service層，mybatis的xml，SQL( mysql 和oracle)腳本, jsp頁面 都生成 就不用寫搬磚的代碼了,生成的放到項目里，可以直接運行B 阿裡巴巴資料庫連接池dr....
  • redis的簡單安裝配置
    一、簡介Redis是一種高級key-value資料庫，數據可以持久化，支持的數據類型很豐富，有字元串，哈希，鏈表，集合和有序集合5種數據類型Redis支持在伺服器端計算集合的並，交和補集(difference)等，還支持多種排序功能，所以Redis也可以被看成是一個數據結構伺服器Redis的所有數據...
  • centos7安裝chrome的歷程
    安裝首先是下載，地址奉上：http://www.google.cn/chrome/browser/desktop/index.html，選擇64 bit .rpm （適用於 Fedora/openSUSE） ，當然如果你是32位系統那麼你可以選擇32 bit .rpm （適用於 Fedora/ope...
  • Beaglebone Black–用 UART 連接 ESP8266 （ESP-01 版）
    這是一塊便宜 （￥12.5）的 WiFi 模塊，3.3V ，晶元是樂鑫科技（Espressif）出品。它本身是很多玩法，比如這個 NodeMCU （淘寶有套件焊接好一整套的帶 USB 介面的，搜 esp8266 nodemcu）。 我這是沒多久之前買的。要買的話，多幾塊錢可以有更完整引腳的版本，樂鑫...
  • 基於tiny4412的Linux內核移植 -- eMMC驅動移植（六）
  • 【linux】free命令中cached和buffers的區別
    一、命令[root@localhost ~]# free -m total used free shared buffers cachedMem: 7869 7651 218 ...
  • 守護進程
    為什麼要引入守護進程： 因為它生存期長，它獨立於控制終端、會話周期（下文有解釋）執行任務: 由於在linux中，每一個系統與用戶進行交流的界面稱為終端，每一個從此終端開始運行的進程都會依賴這個終端，這個終端就稱為這些進程的控制終端。當控制終端被關閉時，相應的進程都會自動關閉。但是守護進程卻能...
  • LVM基本概念、管理
    一、傳統磁碟管理的問題當分區大小不夠用時無法擴展其大小，只能通過添加磁碟、創建新的分區來擴充空間，但是新添加進來的硬碟是作為獨立文件系統存在的，原有的文件系統並未得到擴充，上層應用很多時候只能訪問一個文件系統。只能讓現有磁碟下線，換上新的磁碟之後，再將原始數據導入。二、LVM邏輯捲的基本概念LVM（...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類