前言

緩存由于其高并發(fā)和高性能的特性，已經(jīng)在項(xiàng)目中被廣泛使用。在讀取持久化，數(shù)據(jù)備份，數(shù)據(jù)的故障恢復(fù)方面你究竟了解多少呢?

1.redis持久化的意義----redis故障恢復(fù)

在實(shí)際的生產(chǎn)環(huán)境中，很可能會(huì)遇到redis突然掛掉的情況，比如redis的進(jìn)程死掉了、電纜被施工隊(duì)挖了(支付寶例子)等等，總之一定會(huì)遇到各種奇葩的現(xiàn)象導(dǎo)致redis死掉，這時(shí)候放在redis內(nèi)存中的數(shù)據(jù)就會(huì)全部丟失，這些數(shù)據(jù)可能服務(wù)很多的系統(tǒng)或者服務(wù)，當(dāng)然，我們可以重新啟動(dòng)redis，重啟之后，如果redis沒有持久化，redis中的數(shù)據(jù)就會(huì)全部丟失。

[[252437]]

如果通過持久化將數(shù)據(jù)搞一份到磁盤，然后定期的同步和備份到云存儲(chǔ)服務(wù)上去，那么就可以保證數(shù)據(jù)不會(huì)全部丟失，還是可以恢復(fù)一部分?jǐn)?shù)據(jù)的。

2.持久化的兩大機(jī)制(RDB和AOF)

RDB：對redis數(shù)據(jù)執(zhí)行周期性的持久化

AOF:將每條命令寫入日志，以append-only的模式寫入一個(gè)日志文件中，在redis重啟的時(shí)候，可以通過回放AOF的寫入指令來重新構(gòu)建整個(gè)數(shù)據(jù)集

是否實(shí)用持久化要看具體的業(yè)務(wù)場景：

如果只是想讓redis僅僅作為純內(nèi)存的緩存，那么可以禁止RDB和AOF。

故障恢復(fù)大致思路：

通過RDB或AOF，都可以將redis內(nèi)存中的數(shù)據(jù)持久化到磁盤上來，然后可以將數(shù)據(jù)備份到阿里云，如果redis掛了，服務(wù)器中內(nèi)存和磁盤的數(shù)據(jù)就都丟了，這時(shí)候可以將阿里云中的備份文件拷貝至指定目錄下，然后重啟redis，redis就會(huì)自動(dòng)根據(jù)持久化數(shù)據(jù)文件去恢復(fù)內(nèi)存中的數(shù)據(jù)，繼續(xù)對外提供服務(wù)。如果同時(shí)室友了RDB和AOF兩種持久化機(jī)制，那么在重啟的時(shí)間建議使用AOF的方式重新構(gòu)建數(shù)據(jù)，因?yàn)锳OF中的數(shù)據(jù)更加完整。

3.剖析RDB和AOF

RDB：早上7點(diǎn)，這個(gè)時(shí)候redis 中有500條數(shù)據(jù)，這個(gè)時(shí)候redis會(huì)在一定周期內(nèi)生成一個(gè)RDB快照文件，等到了9點(diǎn)的時(shí)候redis中有8000條數(shù)據(jù)，這個(gè)時(shí)候又在一定的周期內(nèi)生成了另一個(gè)RDB快照文件，這就是RDB持久化機(jī)制。

AOF：redis 中每寫入一條指令，就會(huì)把這條指令更新到磁盤中的文件中。然而在現(xiàn)代操作系統(tǒng)中，寫文件不是直接寫磁盤，會(huì)先寫進(jìn)os cache，然后在一定時(shí)間內(nèi)再從os cache刷入disk file，對于AOF來說每隔一秒(可配置)調(diào)用一次操作系統(tǒng)餓fsync操作強(qiáng)制將os cache中的數(shù)據(jù)刷入磁盤文件中。但是redis內(nèi)存中的數(shù)據(jù)也不是***增長的，它是定期的根據(jù)LRU算法清理一些不常用的數(shù)據(jù)，這樣才能保證AOF不會(huì)***增長，但是如果LRU的清理速度比不上AOF的膨脹速度的時(shí)候，這時(shí)候當(dāng)AOF大到一定程度就會(huì)進(jìn)行AOF rewrite操作。AOF rewrite操作就會(huì)基于當(dāng)時(shí)redis內(nèi)存中的數(shù)據(jù)來重新構(gòu)造一個(gè)更小的AOF文件，然后將舊的AOF文件刪除。

簡單的說，假設(shè)redis限定了只能存放10G數(shù)據(jù)，這時(shí)候不斷的在redis中寫入數(shù)據(jù)，當(dāng)達(dá)到了10G的數(shù)據(jù)量的時(shí)候，這時(shí)候根據(jù)LRU清理了一些不常用的數(shù)據(jù)，清理了5G，這時(shí)候又寫了5G，這時(shí)候AOF文件記錄了15G的數(shù)據(jù)相關(guān)的寫入指令，假如這個(gè)時(shí)候AOF已經(jīng)膨脹了，這個(gè)時(shí)候redis進(jìn)行AOF rewrite操作，重新生成了一個(gè)新的10G的數(shù)據(jù)指令的AOF文件，這個(gè)時(shí)候?qū)⒗^續(xù)寫入新的AOF文件，將老的AOF文件刪除。

4.RDB和AOF優(yōu)缺點(diǎn)

RDB優(yōu)點(diǎn)

(1).RDB會(huì)生成多個(gè)數(shù)據(jù)文件，每個(gè)數(shù)據(jù)文件都代表了某一個(gè)時(shí)刻中redis的數(shù)據(jù)，這種多個(gè)數(shù)據(jù)文件的方式，非常適合做冷備，可以將這種完整的數(shù)據(jù)文件發(fā)送到一些遠(yuǎn)程的安全存儲(chǔ)上去，比如阿里云的ODPS分布式存儲(chǔ)上，以預(yù)定好的備份策略來定期備份redis中的數(shù)據(jù)。

RDB做冷備，生成多個(gè)文件，每個(gè)文件都代表了某一個(gè)時(shí)刻的完整的數(shù)據(jù)快照

AOF也可以做冷備，只有一個(gè)文件，但是你可以，每隔一定時(shí)間，去copy一份這個(gè)文件出來

但是RDB更適合做冷備，它的優(yōu)勢是由redis去控制固定時(shí)長生成快照文件的事情，比較方便; AOF，還需要自己寫一些腳本去做這個(gè)事情，需要自己寫定時(shí)腳本，而且RDB數(shù)據(jù)做冷備，在最壞的情況下，提供數(shù)據(jù)恢復(fù)的時(shí)候，速度比AOF快

(2).RDB對redis對外提供的讀寫服務(wù)，影響非常小，可以讓redis保持高性能，因?yàn)閞edis主進(jìn)程只需要fork一個(gè)子進(jìn)程，讓子進(jìn)程執(zhí)行磁盤IO操作來進(jìn)行RDB持久化即可

RDB，每次寫，都是直接寫redis內(nèi)存，只是在一定的時(shí)候，才會(huì)將數(shù)據(jù)寫入磁盤中

AOF，每次都是要寫文件的，雖然可以快速寫入os cache中，但是還是有一定的時(shí)間開銷的,速度肯定比RDB略慢一些

(3).相對于AOF持久化機(jī)制來說，直接基于RDB數(shù)據(jù)文件來重啟和恢復(fù)redis進(jìn)程，更加快速

RDB缺點(diǎn)

(1).如果想要在redis故障時(shí)，盡可能少的丟失數(shù)據(jù)，那么RDB沒有AOF好。一般來說，RDB數(shù)據(jù)快照文件，都是每隔5分鐘，或者更長時(shí)間生成一次，這個(gè)時(shí)候就得接受一旦redis進(jìn)程宕機(jī)，那么會(huì)丟失最近5分鐘的數(shù)據(jù)，這也是rdb***的缺點(diǎn)，就是不適合做***優(yōu)先的恢復(fù)方案，如果你依賴RDB做***優(yōu)先恢復(fù)方案，會(huì)導(dǎo)致數(shù)據(jù)丟失的比較多。

(2).RDB每次在fork子進(jìn)程來執(zhí)行RDB快照數(shù)據(jù)文件生成的時(shí)候，如果數(shù)據(jù)文件特別大，可能會(huì)導(dǎo)致對客戶端提供的服務(wù)暫停數(shù)毫秒，或者甚至數(shù)秒，所以一般不要讓RDB的間隔太長，否則每次生成的RDB文件太大了，對redis本身的性能可能會(huì)有影響的

AOF優(yōu)點(diǎn)

(1).AOF可以更好的保護(hù)數(shù)據(jù)不丟失，一般AOF會(huì)每隔1秒，通過一個(gè)后臺線程執(zhí)行一次fsync操作，最多丟失1秒鐘的數(shù)據(jù),每隔1秒，就執(zhí)行一次fsync操作，保證os cache中的數(shù)據(jù)寫入磁盤中，redis進(jìn)程掛了，最多丟掉1秒鐘的數(shù)據(jù)。

(2).AOF日志文件以append-only模式寫入，所以沒有任何磁盤尋址的開銷，寫入性能非常高，而且文件不容易破損，即使文件尾部破損，也很容易修復(fù)。

(3).AOF日志文件即使過大的時(shí)候，出現(xiàn)后臺重寫操作，也不會(huì)影響客戶端的讀寫。因?yàn)樵趓ewrite log的時(shí)候，會(huì)對其中的內(nèi)容進(jìn)行壓縮，創(chuàng)建出一份需要恢復(fù)數(shù)據(jù)的最小日志出來。再創(chuàng)建新日志文件的時(shí)候，老的日志文件還是照常寫入。當(dāng)新的merge后的日志文件ready的時(shí)候，再交換新老日志文件即可。

(4).AOF日志文件的命令通過可讀的方式進(jìn)行記錄，這個(gè)特性非常適合做災(zāi)難性的誤刪除的緊急恢復(fù)。比如某人不小心用flushall命令清空了所有數(shù)據(jù)，只要這個(gè)時(shí)候后臺rewrite還沒有發(fā)生，那么就可以立即拷貝AOF文件，將***一條flushall命令給刪了，然后再將該AOF文件放回去，就可以通過恢復(fù)機(jī)制，自動(dòng)恢復(fù)所有數(shù)據(jù)

AOF缺點(diǎn)

(1).對于同一份數(shù)據(jù)來說，AOF日志文件通常比RDB數(shù)據(jù)快照文件更大

(2).AOF開啟后，支持的寫QPS會(huì)比RDB支持的寫QPS低，因?yàn)锳OF一般會(huì)配置成每秒fsync一次日志文件，當(dāng)然，每秒一次fsync，性能也還是很高的，如果你要保證一條數(shù)據(jù)都不丟，也是可以的，AOF的fsync設(shè)置成沒寫入一條數(shù)據(jù)，fsync一次，那就完蛋了，redis的QPS大降。

(3).以前AOF發(fā)生過bug，就是通過AOF記錄的日志，進(jìn)行數(shù)據(jù)恢復(fù)的時(shí)候，沒有恢復(fù)一模一樣的數(shù)據(jù)出來。所以說，類似AOF這種較為復(fù)雜的基于命令日志/merge/回放的方式，比基于RDB每次持久化一份完整的數(shù)據(jù)快照文件的方式，更加脆弱一些，容易有bug。不過AOF就是為了避免rewrite過程導(dǎo)致的bug，因此每次rewrite并不是基于舊的指令日志進(jìn)行merge的，而是基于當(dāng)時(shí)內(nèi)存中的數(shù)據(jù)進(jìn)行指令的重新構(gòu)建，這樣健壯性會(huì)好很多。

(4).唯一的比較大的缺點(diǎn)，其實(shí)就是做數(shù)據(jù)恢復(fù)的時(shí)候，會(huì)比較慢，還有做冷備，定期的備份，不太方便，可能要自己手寫復(fù)雜的腳本去做，做冷備不太合適

AOF和RDB數(shù)據(jù)恢復(fù)機(jī)制

AOF，存放的指令日志，做數(shù)據(jù)恢復(fù)的時(shí)候，其實(shí)是要回放和執(zhí)行所有的指令日志，來恢復(fù)出來內(nèi)存中的所有數(shù)據(jù)的

RDB，就是一份數(shù)據(jù)文件，恢復(fù)的時(shí)候，直接加載到內(nèi)存中即可

無論是AOF和RDB，在redis中都以一個(gè)文件的形式存在!!!

5.RDB和AOF如何選擇

(1).不要僅僅使用RDB，因?yàn)槟菢訒?huì)導(dǎo)致你丟失很多數(shù)據(jù)

(2).也不要僅僅使用AOF，因?yàn)槟菢佑袃蓚€(gè)問題，***，你通過AOF做冷備，沒有RDB做冷備，來的恢復(fù)速度更快; 第二，RDB每次簡單粗暴生成數(shù)據(jù)快照，更加健壯，可以避免AOF這種復(fù)雜的備份和恢復(fù)機(jī)制的bug

(3).綜合使用AOF和RDB兩種持久化機(jī)制，用AOF來保證數(shù)據(jù)不丟失，作為數(shù)據(jù)恢復(fù)的***選擇; 用RDB來做不同程度的冷備，在AOF文件都丟失或損壞不可用的時(shí)候，還可以使用RDB來進(jìn)行快速的數(shù)據(jù)恢復(fù)

6.如何配置RDB持久化

(1).redis.conf文件，也就是/etc/redis/6379.conf，去配置持久化

例如：save 60 1000

(每隔60s，如果有超過1000個(gè)key發(fā)生了變更，那么就生成一個(gè)新的dump.rdb文件，就是當(dāng)前redis內(nèi)存中完整的數(shù)據(jù)快照，這個(gè)操作也被稱之為snapshotting，快照

也可以手動(dòng)調(diào)用save或者bgsave命令，同步或異步執(zhí)行rdb快照生成)

(2).save可以設(shè)置多個(gè)，就是多個(gè)snapshotting檢查點(diǎn)，每到一個(gè)檢查點(diǎn)，就會(huì)去check一下，是否有指定的key數(shù)量發(fā)生了變更，如果有，就生成一個(gè)新的dump.rdb文件

7.RDB持久化機(jī)制的工作流程

(1).redis根據(jù)配置自己嘗試去生成rdb快照文件，fork一個(gè)子進(jìn)程出來，子進(jìn)程嘗試將數(shù)據(jù)dump到臨時(shí)的rdb快照文件中，完成rdb快照文件的生成之后，就替換之前的舊的快照文件，dump.rdb，每次生成一個(gè)新的快照，都會(huì)覆蓋之前的老快照。

8.基于RDB持久化機(jī)制的數(shù)據(jù)恢復(fù)實(shí)驗(yàn)

(1).在redis中保存幾條數(shù)據(jù)，立即停掉redis進(jìn)程，然后重啟redis，看看剛才插入的數(shù)據(jù)還在不在

(2).在redis中再保存幾條新的數(shù)據(jù)，用kill -9粗暴殺死redis進(jìn)程，模擬redis故障異常退出，導(dǎo)致內(nèi)存數(shù)據(jù)丟失的場景

注意：通過redis-cli SHUTDOWN這種方式去停掉redis，其實(shí)是一種安全退出的模式，redis在退出的時(shí)候會(huì)將內(nèi)存中的數(shù)據(jù)立即生成一份完整的rdb快照

9.如何配置AOF持久化

(1).AOF持久化，默認(rèn)是關(guān)閉的，默認(rèn)是打開RDB持久化

(2).appendonly yes，可以打開AOF持久化機(jī)制，在生產(chǎn)環(huán)境里面，一般來說AOF都是要打開的，除非你說隨便丟個(gè)幾分鐘的數(shù)據(jù)也無所謂，打開AOF持久化機(jī)制之后，redis每次接收到一條寫命令，就會(huì)寫入日志文件中，當(dāng)然是先寫入os cache的，然后每隔一定時(shí)間再fsync一下，而且即使AOF和RDB都開啟了，redis重啟的時(shí)候，也是優(yōu)先通過AOF進(jìn)行數(shù)據(jù)恢復(fù)的，因?yàn)閍of數(shù)據(jù)比較完整

(3).可以配置AOF的fsync策略，有三種策略可以選擇，一種是每次寫入一條數(shù)據(jù)就執(zhí)行一次fsync; 一種是每隔一秒執(zhí)行一次fsync; 一種是不主動(dòng)執(zhí)行fsync

always: 每次寫入一條數(shù)據(jù)，立即將這個(gè)數(shù)據(jù)對應(yīng)的寫日志fsync到磁盤上去，性能非常非常差，吞吐量很低; 確保說redis里的數(shù)據(jù)一條都不丟，那就只能這樣了

everysec: 每秒將os cache中的數(shù)據(jù)fsync到磁盤，這個(gè)最常用的，生產(chǎn)環(huán)境一般都這么配置，性能很高，QPS還是可以上萬的

no: 僅僅redis負(fù)責(zé)將數(shù)據(jù)寫入os cache就撒手不管了，然后后面os自己會(huì)時(shí)不時(shí)有自己的策略將數(shù)據(jù)刷入磁盤，不可控了

10.AOF持久化的數(shù)據(jù)恢復(fù)實(shí)驗(yàn)

(1).先僅僅打開RDB，寫入一些數(shù)據(jù)，然后kill -9殺掉redis進(jìn)程，接著重啟redis，發(fā)現(xiàn)數(shù)據(jù)沒了，因?yàn)镽DB快照還沒生成

(2).打開AOF的開關(guān)，啟用AOF持久化

(3).寫入一些數(shù)據(jù)，觀察AOF文件中的日志內(nèi)容

(4).kill -9殺掉redis進(jìn)程，重新啟動(dòng)redis進(jìn)程，發(fā)現(xiàn)數(shù)據(jù)被恢復(fù)回來了，就是從AOF文件中恢復(fù)回來的(redis進(jìn)程啟動(dòng)的時(shí)候，直接就會(huì)從appendonly.aof中加載所有的日志，把內(nèi)存中的數(shù)據(jù)恢復(fù)回來)

注意：在appendonly.aof文件中，可以看到剛寫的日志，它們其實(shí)就是先寫入os cache的，然后1秒后才fsync到磁盤中，只有fsync到磁盤中了，才是安全的，要不然光是在os cache中，機(jī)器只要重啟，就什么都沒了

11.AOF rewrite

AOF工作原理

(1).redis fork一個(gè)子進(jìn)程

(2).子進(jìn)程基于當(dāng)前內(nèi)存中的數(shù)據(jù)，構(gòu)建日志，開始往一個(gè)新的臨時(shí)的AOF文件中寫入日志

(3).redis主進(jìn)程，接收到client新的寫操作之后，在內(nèi)存中的數(shù)據(jù)繼續(xù)寫入新日志到AOF文件中，同時(shí)新的數(shù)據(jù)也繼續(xù)寫入舊的AOF文件

(4).redis主進(jìn)程將內(nèi)存中的新寫進(jìn)去的日志再次追加到新的AOF文件中

(5).用新的日志文件替換掉舊的日志文件

redis中的數(shù)據(jù)其實(shí)有限的，很多數(shù)據(jù)可能會(huì)自動(dòng)過期，可能會(huì)被用戶刪除，可能會(huì)被redis用緩存清除的算法清理掉，redis中的數(shù)據(jù)會(huì)不斷淘汰掉舊的，就一部分常用的數(shù)據(jù)會(huì)被自動(dòng)保留在redis內(nèi)存中，所以可能很多之前的已經(jīng)被清理掉的數(shù)據(jù)，對應(yīng)的寫日志還停留在AOF中，AOF日志文件就一個(gè)，會(huì)不斷的膨脹，到很大很大，所以AOF會(huì)自動(dòng)在后臺每隔一定時(shí)間做rewrite操作，比如日志里已經(jīng)存放了針對100w數(shù)據(jù)的寫日志了; redis內(nèi)存只剩下10萬; 基于內(nèi)存中當(dāng)前的10萬數(shù)據(jù)構(gòu)建一套***的日志，到AOF中; 覆蓋之前的老日志; 確保AOF日志文件不會(huì)過大，保持跟redis內(nèi)存數(shù)據(jù)量一致

redis 2.4之前，還需要手動(dòng)，開發(fā)一些腳本，crontab，通過BGREWRITEAOF命令去執(zhí)行AOF rewrite，但是redis 2.4之后，會(huì)自動(dòng)進(jìn)行rewrite操作

注意：

在redis.conf中，可以配置rewrite策略

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

比如說上一次AOF rewrite之后，是128mb，然后就會(huì)接著128mb繼續(xù)寫AOF的日志，如果發(fā)現(xiàn)增長的比例，超過了之前的100%，也就是256mb，就可能會(huì)去觸發(fā)一次rewrite，但是此時(shí)還要去跟min-size，64mb去比較，256mb > 64mb，才會(huì)去觸發(fā)rewrite

12.AOF破損文件的修復(fù)

如果redis在append數(shù)據(jù)到AOF文件時(shí)，機(jī)器宕機(jī)了，可能會(huì)導(dǎo)致AOF文件破損，用redis-check-aof --fix命令來修復(fù)破損的AOF文件。

13.AOF和RDB同時(shí)工作

(1).如果RDB在執(zhí)行snapshotting操作，那么redis不會(huì)執(zhí)行AOF rewrite; 如果redis再執(zhí)行AOF rewrite，那么就不會(huì)執(zhí)行RDB snapshotting

(2).如果RDB在執(zhí)行snapshotting，此時(shí)用戶執(zhí)行BGREWRITEAOF命令，那么等RDB快照生成之后，才會(huì)去執(zhí)行AOF rewrite

(3).同時(shí)有RDB snapshot文件和AOF日志文件，那么redis重啟的時(shí)候，會(huì)優(yōu)先使用AOF進(jìn)行數(shù)據(jù)恢復(fù)，因?yàn)槠渲械娜罩靖暾?/p>

14.企業(yè)級的持久化的配置策略

企業(yè)中，RDB的生成策略，用默認(rèn)的也差不多

save 60 10000：如果你希望盡可能確保說，RDB最多丟1分鐘的數(shù)據(jù)，那么盡量就是每隔1分鐘都生成一個(gè)快照，低峰期，數(shù)據(jù)量很少，也沒必要

AOF一定要打開，fsync，everysec

auto-aof-rewrite-percentage 100: 就是當(dāng)前AOF大小膨脹到超過上次100%，上次的兩倍

auto-aof-rewrite-min-size 64mb: 根據(jù)你的數(shù)據(jù)量來定，16mb，32mb

15.企業(yè)級的數(shù)據(jù)備份方案

(1).寫crontab定時(shí)調(diào)度腳本去做數(shù)據(jù)備份

(2).每小時(shí)都copy一份rdb的備份，到一個(gè)目錄中去，僅僅保留最近48小時(shí)的備份

(3).每天都保留一份當(dāng)日的rdb的備份，到一個(gè)目錄中去，僅僅保留最近1個(gè)月的備份

(4).每次copy備份的時(shí)候，都把太舊的備份給刪了

(5).每天晚上將當(dāng)前服務(wù)器上所有的數(shù)據(jù)備份，發(fā)送一份到遠(yuǎn)程的云服務(wù)上去

按小時(shí)和按天同時(shí)備份

每小時(shí)copy一次備份，刪除48小時(shí)前的數(shù)據(jù)

crontab -e 
　　0 * * * * sh /usr/local/redis/copy/redis_rdb_copy_hourly.sh 
　　redis_rdb_copy_hourly.sh 
 
　　#!/bin/sh  
　　cur_date=`date +%Y%m%d%k` 
　　rm -rf /usr/local/redis/snapshotting/$cur_date 
　　mkdir /usr/local/redis/snapshotting/$cur_date 
　　cp /var/redis/6379/dump.rdb /usr/local/redis/snapshotting/$cur_date 
 
　　del_date=`date -d -48hour +%Y%m%d%k` 
　　rm -rf /usr/local/redis/snapshotting/$del_date 
 
　　每天copy一次備份 
　　crontab -e 
　　0 0 * * * sh /usr/local/redis/copy/redis_rdb_copy_daily.sh 
　　redis_rdb_copy_daily.sh 
 
　　#!/bin/sh  
　　cur_date=`date +%Y%m%d` 
　　rm -rf /usr/local/redis/snapshotting/$cur_date 
　　mkdir /usr/local/redis/snapshotting/$cur_date 
　　cp /var/redis/6379/dump.rdb /usr/local/redis/snapshotting/$cur_date 
　　del_date=`date -d -1month +%Y%m%d` 
　　rm -rf /usr/local/redis/snapshotting/$del_date 

每天一次將所有數(shù)據(jù)上傳一次到遠(yuǎn)程的云服務(wù)器上去

16.企業(yè)級數(shù)據(jù)恢復(fù)方案

(1).如果是redis進(jìn)程掛掉，那么重啟redis進(jìn)程即可，直接基于AOF日志文件恢復(fù)數(shù)據(jù)

(2).如果是redis進(jìn)程所在機(jī)器掛掉，那么重啟機(jī)器后，嘗試重啟redis進(jìn)程，嘗試直接基于AOF日志文件進(jìn)行數(shù)據(jù)恢復(fù)，前提是AOF沒有破損，AOF append-only，順序?qū)懭?，如果AOF文件破損，那么用redis-check-aof fix修復(fù)。

(3).如果redis當(dāng)前***的AOF和RDB文件出現(xiàn)了丟失/損壞，那么可以嘗試基于該機(jī)器上當(dāng)前的某個(gè)***的RDB數(shù)據(jù)副本進(jìn)行數(shù)據(jù)恢復(fù)，當(dāng)前***的AOF和RDB文件都出現(xiàn)了丟失/損壞到無法恢復(fù)，一般不是機(jī)器的故障，而是人為。

17.容災(zāi)演練

appendonly.aof + dump.rdb，優(yōu)先用appendonly.aof去恢復(fù)數(shù)據(jù)。

(1).如果關(guān)閉AOF持久化機(jī)制，并且dump.rdb是有數(shù)據(jù)的，這時(shí)候重啟redis，發(fā)現(xiàn)內(nèi)存中明顯沒有恢復(fù)數(shù)據(jù)。

原因：redis啟動(dòng)的時(shí)候，自動(dòng)重新基于內(nèi)存的數(shù)據(jù)，生成了一份***的rdb快照，直接用空的數(shù)據(jù)，覆蓋掉了我們有數(shù)據(jù)的dump.rdb

(2).如果打開AOF，停止redis之后，先刪除appendonly.aof，然后將我們的dump.rdb拷貝過去，然后再重啟redis，發(fā)現(xiàn)依然沒有恢復(fù)數(shù)據(jù)

原因：雖然你刪除了appendonly.aof，但是因?yàn)榇蜷_了aof持久化，redis就一定會(huì)優(yōu)先基于aof去恢復(fù)，即使文件不在，那就創(chuàng)建一個(gè)新的空的aof文件

(3).停止redis，暫時(shí)在配置中關(guān)閉aof，然后拷貝一份rdb過來，再重啟redis，這時(shí)候內(nèi)存中的數(shù)據(jù)恢復(fù)成功;假如不小心，再關(guān)掉redis，手動(dòng)修改配置文件，打開aof，再重啟redis，數(shù)據(jù)又沒了，因?yàn)槭强盏腶of文件，所以所有數(shù)據(jù)又沒了。

在數(shù)據(jù)安全丟失的情況下，基于rdb冷備，如何***的恢復(fù)數(shù)據(jù)，同時(shí)還保持aof和rdb的雙開?

(4).停止redis，關(guān)閉aof，拷貝rdb備份，重啟redis，確認(rèn)數(shù)據(jù)恢復(fù)，直接在命令行熱修改redis配置，打開aof，這個(gè)redis就會(huì)將內(nèi)存中的數(shù)據(jù)對應(yīng)的日志，寫入aof文件中，此時(shí)aof和rdb兩份數(shù)據(jù)文件的數(shù)據(jù)就同步了。

注意：redis config set熱修改配置參數(shù)，可能配置文件中的實(shí)際的參數(shù)沒有被持久化的修改，再次停止redis，手動(dòng)修改配置文件，打開aof的命令，再次重啟redis

(5).如果當(dāng)前機(jī)器上的所有RDB文件全部損壞，那么從遠(yuǎn)程的云服務(wù)上拉取***的RDB快照回來恢復(fù)數(shù)據(jù)

(6).如果是發(fā)現(xiàn)有重大的數(shù)據(jù)錯(cuò)誤，比如某個(gè)小時(shí)上線的程序一下子將數(shù)據(jù)全部污染了，數(shù)據(jù)全錯(cuò)了，那么可以選擇某個(gè)更早的時(shí)間點(diǎn)，對數(shù)據(jù)進(jìn)行恢復(fù)

舉個(gè)例子，12點(diǎn)上線了代碼，發(fā)現(xiàn)代碼有bug，導(dǎo)致代碼生成的所有的緩存數(shù)據(jù)，寫入redis，全部錯(cuò)了，找到一份11點(diǎn)的rdb的冷備，然后按照上面的步驟，去恢復(fù)到11點(diǎn)的數(shù)據(jù)。