Redis持久化--Redis宕機或者出現意外刪庫致使數據丟失--解決方案

轉發來源:https://www.cnblogs.com/xlecho/p/11834011.html

echo編輯整理，歡迎轉載，轉載請聲明文章來源。歡迎添加echo微信(微信號：t2421499075)交流學習。 百戰不敗，依不自稱常勝，百敗不頹，依能奮力前行。——這纔是真正的堪稱強大！！！

---

Redis持久化的方案實際上是不少人接觸的比較少的，由於相對應的數據故障不會不少，一次初始化的設置就能保證後續故障的所有順利解決。本文講述一下該機制的主要設置方法和持久化方案的對比，同時也會講述一些持久化的原理。若是對於Redis持久化比較熟悉的但願可以給到你幫助，若是不熟悉的，你大可參考本文對你的Redis進行設置。

什麼是Redis的持久化？

可能不少人不多接觸這個詞，總覺的咱們Redis的全部數據都是所有可以永久存儲的。然而你可能不知道的是，Redis的數據都是在內存當中的，若是沒有持久化策略，你關閉Redis或者以後，你的數據有可能所有都丟失了。咱們每再一次登陸Redis訪問上一次數據的時候，咱們都看到了原來的數據，就是得益於Redis的持久化。Redis的持久化簡單說就是，將Redis存在內存中的值存儲到能夠永久存儲的地方（磁盤等）

Redis的持久化方案

• RDB Redis DataBase
• AOF Append Only File

RDB [Redis DataBase]

RDB 是 Redis 默認的持久化方案。當知足必定條件的時候，會把當前內存中的數據寫入磁盤，生成一個快照文件 dump.rdb。Redis 重啓會經過加載 dump.rdb 文件恢復數據。dump.rdb是咱們redis文件當中的一個，位置以下圖：

RDB是怎麼實現持久化的

RDB是按照規則來觸發持久化存儲的，在咱們的redis.conf中咱們能夠看到以下的幾個配置：

save 900 1 # 900 秒內至少有一個 key 被修改（包括添加） save 300 10 # 300 秒內至少有 10 個 key 被修改 save 60 10000 # 60 秒內至少有 10000 個 key 被修改

這幾個配置是不衝突的，只要知足任意一個都會觸發。

• RDB方式的優勢
• • RDB 是一個緊湊的單一文件,很方便傳送到另外一個遠端數據中心，很是適用於災難恢復。
• • 與AOF相比,在恢復大的數據集的時候，RDB 方式會更快一些。
• RDB方式的缺點
• • RDB 方式數據沒辦法作到實時持久化/秒級持久化。由於 bgsave 每次運行都要
    執行 fork 操做建立子進程，頻繁執行成本太高。
• • 在必定間隔時間作一次備份，因此若是 redis 意外 down 掉的話，就會丟失最後
    一次快照以後的全部修改（數據有丟失）。若是數據相對來講比較重要，但願將損失降到最小，則可使用 AOF 方式進行持久化。

RDB持久化的演示

若是咱們都按照正常程序走的話，咱們是很難看到沒有持久化，或者出現持久化問題的故障現場的。因此咱們要學會持久化操做，或者只管看到持久化就須要手動觸發持久化問題。這裏主要演示兩種狀況，一種是數據正常備份，一種是數據丟失，咱們恢復備份數據。

注意

這兩個操做都算是危險操做，咱們須要在操做以前進行一下設置一下Redis快照，Redis
提供了兩條命令：

• save: 在生成快照的時候會阻塞當前 Redis 服務器， Redis 不能處理其餘命令。若是
  內存中的數據比較多，會形成Redis長時間的阻塞。生產環境不建議使用這個命令。爲了解決這個問題，Redis 提供了第二種方式。
• bgsave:執行 bgsave 時，Redis 會在後臺異步進行快照操做，快照同時還能夠響應客戶端請
  求。具體操做是 Redis 進程執行fork操做建立子進程（copy-on-write），RDB持久化過程由子進程負責，完成後自動結束。它不會記錄fork以後後續的命令。阻塞只發生在fork階段，通常時間很短。用 lastsave 命令能夠查看最近一次成功生成快照的時間。

使用shutdown 持久化

咱們先在Redis庫中設置以下幾個值

set k1 1 set k2 2 set k3 3 set k4 4 set k5 5 # 操做完成上面的步驟以後咱們中止服務器，觸發RDB的自動保存save shutdown # 而後再次啓動Redis服務 redis-server redis.conf # 啓動完成，查看咱們那些剛剛保存的數據是否被持久化了 keys *

執行完上面的步驟以後，咱們能夠看到咱們的數據都在，就說明咱們的觸發備份是成功的。

使用flushall模擬數據丟失

該操做有必定的風險性，若是是演示練習按照操做來基本不會出現問題，可是生產上慎重操做。咱們作該操做以前，必定要注意先備份RDB對應的持久化問題dump.rdb

# 先備份dump.rdb cp dump.rdb dump.rdb.bak  # 備份完成以後咱們肯定備份成功在進行下一步操做---清空庫 flushall  # 清空以後咱們中止服務器 shutdown  # 再次啓動服務器，查看以前存儲的kye keys * 

再次啓動查看的時候，咱們發現咱們的數據丟失了

恢復丟失的數據

# 停服務器 shutdown  # 刪除咱們現有dump.rdb rm -rf ./dump.rdb  # 刪除成功以後，將咱們的備份的dump.rdb.bak從新命名成爲dump.rdb mv dump.rdb.bak dump.rdb  # 肯定以後咱們再次啓動redis服務 redis-server redis.conf  # 檢查咱們以前丟失的數據是否存在 keys * 

完成以後咱們查看的數據就出現啦！

AOF [Append Only File]

AOF：Redis 默認不開啓。AOF採用日誌的形式來記錄每一個寫操做，並追加到文件中。開啓後，執行更改 Redis 數據的命令時，就會把命令寫入到AOF文件中。Redis重啓時會根據日誌文件的內容把寫指令從前到後執行一次以完成數據的恢復工做。

該方式默認關閉，須要使用咱們須要修改以下配置

# 開關 Redis 默認只開啓 RDB 持久化，開啓 AOF 須要修改成 yes appendonly no # 文件名 路徑也是經過 dir 參數配置 config get dir appendfilename "appendonly.aof"

數據都是實時持久化到磁盤嗎？

因爲操做系統的緩存機制，AOF數據並無真正地寫入硬盤，而是進入了系統的硬盤緩存。何時把緩衝區的內容寫入到 AOF 文件？

AOF的保存規則有三種

AOF 持久化策略（硬盤緩存到磁盤），默認 everysec

• no 表示不執行 fsync，由操做系統保證數據同步到磁盤，速度最快，可是不太安全；
• always 表示每次寫入都執行 fsync，以保證數據同步到磁盤，效率很低；
• everysec 表示每秒執行一次 fsync，可能會致使丟失這 1s 數據。一般選擇 everysec ，
  兼顧安全性和效率。

文件愈來愈大，怎麼辦？

因爲 AOF 持久化是 Redis 不斷將寫命令記錄到 AOF 文件中，隨着 Redis 不斷的進行，AOF 的文件會愈來愈大，文件越大，佔用服務器內存越大以及 AOF恢復要求時間越長。
可使用命令 bgrewriteaof來重寫。AOF文件重寫並非對原文件進行從新整理，而是直接讀取服務器現有的鍵值對，而後用一條命令去代替以前記錄這個鍵值對的多條命令，生成一個新的文件後去替換原來的 AOF 文件。

AOF指定大小開始重寫

• auto-aof-rewrite-percentage:默認值爲100。aof自動重寫配置，當目前aof文件大小超過上一次重寫的aof文件大小的百分之多少進行重寫，即當aof文件增加到必定大小的時候，Redis可以調用bgrewriteaof對日誌文件進行重寫。當前AOF文件大小是上第二天志重寫獲得AOF文件大小的二倍（設置爲100）時，自動啓動新的日誌重寫過程。

• auto-aof-rewrite-min-size:默認64M。設置容許重寫的最小aof文件大小，避免了達到約定百分比但尺寸仍然很小的狀況還要重寫。

• AOF方式的優勢
• • AOF 持久化的方法提供了多種的同步頻率，即便使用默認的同步頻率每秒同步一次，Redis最多也就丟失 1 秒的數據而已。
• AOF方式的缺點
• • 對於具備相同數據的的Redis，AOF文件一般會比RDF文件體積更大（RDB存的是數據快照）。
• • 雖然 AOF 提供了多種同步的頻率，默認狀況下，每秒同步一次的頻率也具備較高的性能。在高併發的狀況下，RDB 比 AOF 具好更好的性能保證。

兩種方案比較

那麼對於AOF和RDB兩種持久化方式，咱們應該如何選擇呢？若是能夠忍受一小段時間內數據的丟失，毫無疑問使用 RDB 是最好的，定時生成RDB 快照（snapshot）很是便於進行數據庫備份， 而且 RDB 恢復數據集的速度也要比 AOF 恢復的速度要快。不然就使用AOF重寫。可是通常狀況下建議不要單獨使用某一種持久化機制，而是應該兩種一塊兒用，在這種狀況下,當 redis 重啓的時候會優先載入 AOF文件來恢復原始的數據，由於在一般狀況下 AOF 文件保存的數據集要比 RDB 文件保存的數據集要完整。---作一個有底線的博客主