共計(jì) 7095 個(gè)字符，預(yù)計(jì)需要花費(fèi) 18 分鐘才能閱讀完成。

這篇文章主要介紹“什么是 RDB 和 AOF”，在日常操作中，相信很多人在什么是 RDB 和 AOF 問(wèn)題上存在疑惑，丸趣 TV 小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”什么是 RDB 和 AOF”的疑惑有所幫助！接下來(lái)，請(qǐng)跟著丸趣 TV 小編一起來(lái)學(xué)習(xí)吧！

Redis 持久化

Redis 提供了不同級(jí)別的持久化選項(xiàng):

RDB 模式, Redis 數(shù)據(jù)庫(kù)備份文件 (Redis Database Backup) 持久化方式, 提供周期性基于時(shí)間點(diǎn)的數(shù)據(jù)集快照備份,   比如每小時(shí)生成一個(gè)快照備份.

AOF 模式, 僅追加到文件 (AppendOnlyFile) 持久化方式, 在每次數(shù)據(jù)庫(kù)服務(wù)收到寫(xiě)操作時(shí)記錄日志文件, 當(dāng)服務(wù)重啟時(shí),   自動(dòng)回放該日志來(lái)重建原始數(shù)據(jù)集. 日志中使用 Redis 自己的協(xié)議, 并按照統(tǒng)一的格式, 采用只追加的方法記錄. 當(dāng)日志文件太大時(shí),  Redis 可以在后臺(tái)重寫(xiě)該日志, 生成一個(gè)最小化版本的日志文件.

你也可以完全禁用持久化, 比如只要保證服務(wù)在運(yùn)行中有數(shù)據(jù)或可以自動(dòng)生成緩存數(shù)據(jù)即可.

你還可以在同一個(gè) Redis 實(shí)例上結(jié)合 AOF 和 RDB 兩種持久化方式. 請(qǐng)注意: 這種方式在 Redis 重啟時(shí), AOF 文件會(huì)被用來(lái)重建原始數(shù)據(jù)集, 因?yàn)?   相對(duì) RDB 周期快照的方式, AOF 被認(rèn)為是更完整的數(shù)據(jù)備份, 比如它可以做到準(zhǔn)實(shí)時(shí)備份(只丟失 1 秒的數(shù)據(jù)).

接下來(lái), 讓我們來(lái)對(duì)比 RDB 和 AOF 的優(yōu)缺點(diǎn):

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

RDB 采用一個(gè)壓縮單文件來(lái)表示基于時(shí)間點(diǎn)的 Redis 數(shù)據(jù), RDB 文件是完美的備份. 例如, 你可以保留過(guò)去 24 小時(shí)的每小時(shí)的快照備份,   并且保存過(guò)去 30 天, 每天的快照備份, 當(dāng)數(shù)據(jù)遇到丟失時(shí), 你可以很方便的從不同的備份粒度 (版本) 來(lái)恢復(fù)數(shù)據(jù)集.

RDB 用來(lái)做災(zāi)備恢復(fù)非常好, 因?yàn)榫o湊的單文件非常便于在遠(yuǎn)端數(shù)據(jù)中心或者亞馬遜 S3(對(duì)象存儲(chǔ), 可以加密)間傳輸.

RDB 使 Redis 性能最大化, 因?yàn)?Redis 父進(jìn)程只需要啟動(dòng)一個(gè)子進(jìn)程完成快照備份即可, 父進(jìn)程不執(zhí)行由備份引起的磁盤(pán) I /O

與 AOF 模式相比, RDB 在大數(shù)據(jù)集的情況下, 數(shù)據(jù)恢復(fù)時(shí), 服務(wù)重啟速度更快.

RDB 缺點(diǎn)

如果你想要在 Redis 意外停止工作時(shí)(比如斷電), 最小可能的丟失數(shù)據(jù), RDB 不是一個(gè)好的方案. 你可以在 RDB 生成的地方,   配置不同的保存點(diǎn)(比如每 5 分鐘, 對(duì)數(shù)據(jù)集產(chǎn)生至少 100 次寫(xiě)操作時(shí), 創(chuàng)建一個(gè)保存點(diǎn), 你也可以配置多個(gè)保存點(diǎn)策略). 然而,   這樣你通常會(huì)在每 5 分鐘甚至更長(zhǎng)時(shí)間間隔才創(chuàng)建 RDB 快照, 所以當(dāng) Redis 異常停止工作時(shí), 你會(huì)丟失最后產(chǎn)生快照時(shí)間點(diǎn)到現(xiàn)在的數(shù)據(jù).

RDB 會(huì)調(diào)用系統(tǒng) fork()方法派生一個(gè)子進(jìn)程來(lái)完成數(shù)據(jù)持久化到硬盤(pán). 如果數(shù)據(jù)集比較大, Fork()方法會(huì)非常耗時(shí), 造成 Redis 停止為客戶(hù)端服務(wù),   停止時(shí)間可能是上微秒, 如果數(shù)據(jù)集非常大并且 CPU 性能不是很好, 停止時(shí)間可以達(dá)到 1 秒鐘或更多. 在持久化時(shí), AOF 也會(huì)調(diào)用 fork()方法,   但是你可以不帶任何協(xié)商(trade-off), 調(diào)整重寫(xiě)日志的頻率.

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

使用 AOF 持久化程度更高: 你可以配置不同的 fsync 策略:

不帶 fsync

每秒鐘一次 fsync

每次查詢(xún)的時(shí)候 fsync

注: fsync(https://man7.org/linux/man-pages/man2/fsync.2.html)是系統(tǒng)方法,   用于將內(nèi)核態(tài)的緩存數(shù)據(jù)持久化到存儲(chǔ)設(shè)備, 比如將內(nèi)存數(shù)據(jù)寫(xiě)入硬盤(pán)

默認(rèn)使用每秒執(zhí)行一次 fsync 的策略, 這種場(chǎng)景下, Redis 的寫(xiě)性能也能非常好, 因?yàn)?fsync 運(yùn)行在一個(gè)后臺(tái)線程, 而主線程會(huì)盡力完成寫(xiě)操作.   所以你最多丟失 1 秒鐘的數(shù)據(jù).

AOF 日志是一個(gè)只能追加的文件, 所以在斷電后, 該文件不會(huì)出現(xiàn)查找 (seek) 或損壞的問(wèn)題. 即使由于磁盤(pán)滿或其他原因?qū)е氯罩局写嬖谥粚?xiě)了一半的命令,   也可以使用 redis-check-aof 工具輕松修復(fù).

Redis 會(huì)在 AOF 文件太大的時(shí)候, 自動(dòng)在后臺(tái)重寫(xiě)日志. 重寫(xiě)十分安全, 重寫(xiě)時(shí),  Redis 派生一個(gè)子進(jìn)程將大的 AOF 文件重寫(xiě)為最小可用的數(shù)據(jù)集日志文件, 此時(shí)有寫(xiě)操作時(shí),  Redis 繼續(xù)追加到舊的 AOF 文件的同時(shí)也追加到 AOF 重寫(xiě)緩沖區(qū) aof_rewrite_buf, 重寫(xiě)完成時(shí), 新的小 AOF 文件將合并緩沖區(qū)中的新數(shù)據(jù),   最后將新的 AOF 文件重命名為老的 AOF 文件完成替換操作, 以后的數(shù)據(jù)將寫(xiě)入新的 AOF 文件.

AOF 日志文件以一種容易理解和解析的格式依次記錄了所有的操作. 導(dǎo)出一個(gè) AOF 文件非常容易.   甚至在失誤執(zhí)行了清除命令 FLUSHALL(https://redis.io/commands/flushall) , 如果這時(shí)候重寫(xiě)操作沒(méi)有被執(zhí)行,   你仍然可以通過(guò)關(guān)閉服務(wù), 刪除文件最后的錯(cuò)誤命令, 重啟 Redis 完成數(shù)據(jù)恢復(fù).

AOF 缺點(diǎn)

對(duì)于相同的數(shù)據(jù)集, AOF 文件一般比 RDB 文件大.

根據(jù)具體的 fsync 策略, AOF 可能比 RDB 速度慢. 通常默認(rèn)的每秒 fsync 策略下, Reids 性能也非常高, 如果禁用 fsync,   即使在高負(fù)載的情況下, AOF 的速度應(yīng)該和 RDB 一樣快. 盡管如此, 在巨大寫(xiě)負(fù)載的情況下, RDB 提供了更多最大延遲的保證.

在過(guò)去,   當(dāng)執(zhí)行一些特殊的命令時(shí)(比如這里有一個(gè)涉及到阻塞的命令 BRPOPLPUSH:https://redis.io/commands/brpoplpush),  Redis 遇到了一些罕見(jiàn)的 BUG, 它會(huì)導(dǎo)致 AOF 重建數(shù)據(jù)時(shí), 數(shù)據(jù)出現(xiàn)不一致. 這些問(wèn)題非常罕見(jiàn), 我們進(jìn)行了單元測(cè)試,   自動(dòng)創(chuàng)建隨機(jī)復(fù)雜的數(shù)據(jù)集來(lái)執(zhí)行重建測(cè)試, 沒(méi)有出現(xiàn)這些問(wèn)題. 但是如果使用 RDB 持久化, 幾乎不可能出現(xiàn)這類(lèi)問(wèn)題. 為了清楚的說(shuō)明這一點(diǎn):  AOF 類(lèi)似 MySQL 或者 MongoDB, 采用增量更新現(xiàn)有狀態(tài)的工作機(jī)制, 但是 RDB 快照是每次從頭開(kāi)始創(chuàng)建, 從概念上來(lái)說(shuō), RDB 更具有魯棒性(健壯).   但是有以下兩點(diǎn)值得注意:

鴻蒙官方戰(zhàn)略合作共建——HarmonyOS 技術(shù)社區(qū)

每次 AOF 被 Redis 重寫(xiě)的時(shí)候，它會(huì)從包含在數(shù)據(jù)集中的實(shí)際數(shù)據(jù)中從頭開(kāi)始重新創(chuàng)建，使新 AOF 文件對(duì) bug 的抵抗力比不重寫(xiě)的, ,   一直追加的 AOF 文件更強(qiáng).

在實(shí)際使用中, 我們重來(lái)沒(méi)有收到過(guò)一個(gè)關(guān)于 AOF 文件出錯(cuò)的用戶(hù)報(bào)告.

那我該使用哪個(gè)?

通常, 如果你想獲得像 PostgreSQL 那樣的數(shù)據(jù)安全性, 你應(yīng)該結(jié)合 RDB 和 AOF.

如果你非常關(guān)心你的數(shù)據(jù), 但是允許丟失幾分鐘的數(shù)據(jù), 你可以只使用 RDB 持久化.

有很多用戶(hù)只使用 AOF, 但是我們不建議那樣做, 因?yàn)?RDB 的基于時(shí)間點(diǎn)的快照在做數(shù)據(jù)庫(kù)備份, 快速重啟, 或 AOF 引擎出現(xiàn)問(wèn)題時(shí), 非常有用.

注意: 基于這些原因, 在將來(lái)(長(zhǎng)期計(jì)劃), 我們最終會(huì)統(tǒng)一 AOF 和 RDB 為一個(gè)持久化模型方案.

下面幾節(jié), 我們來(lái)舉例說(shuō)明更多, 關(guān)于 RDB 和 AOF 的細(xì)節(jié).

快照

Redis 默認(rèn)保存快照到硬盤(pán)上的 dump.rdb 文件. 你可以配置, 每 N 分鐘, 至少出現(xiàn)了 M 次數(shù)據(jù)集改變執(zhí)行一次快照, 或者手動(dòng)執(zhí)行保存 SAVE   或后臺(tái)保存 BGSAVE 命令.

save 60 1000

它是如何工作的?

每當(dāng) Redis 需要保存數(shù)據(jù)集到磁盤(pán), 會(huì)執(zhí)行下面的任務(wù):

Redis forks 派生子進(jìn)程, 這時(shí)候會(huì)存在一個(gè)父進(jìn)程和一個(gè)子進(jìn)程.

子進(jìn)程開(kāi)始將數(shù)據(jù)集寫(xiě)到 RDB 臨時(shí)文件.

當(dāng)子進(jìn)程完成新 RDB 文件寫(xiě)入后, 會(huì)將原來(lái)的舊 RDB 文件替換.

這種方法就是 Redis 的寫(xiě)即拷語(yǔ)義(copy-on-write)

AOF 僅追加文件

快照不是很持久, 如果 Redis 服務(wù)異常停止, 掉電停止, 或者意外執(zhí)行了 kill - 9 殺掉 Redis 服務(wù)進(jìn)程, 最后的數(shù)據(jù)寫(xiě)入將會(huì)丟失.   雖然對(duì)于有些應(yīng)用來(lái)說(shuō)這是個(gè)小問(wèn)題, 但對(duì)于要求完全持久化的場(chǎng)景, RDB 不是一個(gè)很好的選擇.

appendonly yes

從現(xiàn)在開(kāi)始, 每當(dāng) Redis 收到一個(gè)改變數(shù)據(jù)集的命令(比如 SET), 該操作將追加到 AOF 文件, 當(dāng)你重啟 Redis 時(shí),   會(huì)基于 AOF 文件重建數(shù)據(jù)集.

日志重寫(xiě)

AOF 文件大小隨著操作的增加而增加. 舉個(gè)例子, 如果你想遞增計(jì)數(shù) 100 次, 最終數(shù)據(jù)集中只包含一個(gè)鍵值就是最終的結(jié)果,   但是在 AOF 文件中有 100 條記錄, 實(shí)際上在重建數(shù)據(jù)集時(shí), 不需要剩余的 99 次記錄.

所以 Redis 支持這個(gè)有趣的功能: 在不中斷 Redis 服務(wù)的情況下, 后臺(tái)進(jìn)行 AOF 文件重寫(xiě). 當(dāng)執(zhí)行后臺(tái)重寫(xiě)命令 BGREWRITEAOF 時(shí),  Reids 會(huì)將當(dāng)前內(nèi)存中的數(shù)據(jù)集以最短的有序命令集寫(xiě)下來(lái). 如果你使用 Redis2.2, 你需要定時(shí)執(zhí)行  BGREWRITEAOF(https://redis.io/commands/bgrewriteaof) , 從 Redis2.4 開(kāi)始,   它可以自動(dòng)觸發(fā)日志重寫(xiě)(更多信息可以查看 2.4 的配置示例, 不同版本的配置(https://redis.io/topics/config)).

AOF 怎么持久化?

你可以配置時(shí)間間隔, Redis 來(lái)執(zhí)行 fsync 到磁盤(pán). 這里有三個(gè)策略:

appendfsync always: 每個(gè)新的命令追加到 AOF 文件時(shí)執(zhí)行 fsync. 非常慢, 但是非常安全. 注意,   如果追加的命令來(lái)自多個(gè)客戶(hù)端或管道的批量命令, 在發(fā)送響應(yīng)之前, 這會(huì)被當(dāng)做一次寫(xiě)操作, 只會(huì)執(zhí)行一次 fsync.

appendfsync everysec: 每秒執(zhí)行一次 fsync. 速度足夠快(在 Redis2.4 版本中, 與 RDB 快照的速度一樣快), 如果出現(xiàn)意外,   你最多丟失 1 秒的數(shù)據(jù).

appendfsync no: 從不執(zhí)行 fsync, 只把數(shù)據(jù)交給操作系統(tǒng). 這雖然更快, 但是更不安全. 這種配置,   通常 Linux 會(huì)每 30 秒刷新一次數(shù)據(jù)到硬盤(pán), 但實(shí)際時(shí)間可以通過(guò)內(nèi)核配置調(diào)優(yōu).

每秒執(zhí)行一次 fsync 是建議并且是默認(rèn)的方式. 它既快又安全. appendfsync always 策略在實(shí)踐中非常慢, 但是支持組提交,   所以可以將多個(gè)并行寫(xiě)操作合并, 執(zhí)行一次 fsync 即可.

如果 AOF 文件被截?cái)嗔藨?yīng)該怎么做?

在寫(xiě) AOF 文件時(shí), 服務(wù)器出現(xiàn) crash 或磁盤(pán)空間滿了, 這時(shí)候 AOF 依然包含一致的數(shù)據(jù),   代表了給定時(shí)間點(diǎn)版本的數(shù)據(jù)集(默認(rèn) fsync 策略可能會(huì)丟失 1 秒的數(shù)據(jù)), 但是最后的命令在 AOF 記錄中會(huì)被截?cái)?   最新的 Redis 主干版本依然會(huì)導(dǎo)入所有的 AOF 文件內(nèi)容, 但是會(huì)忽略最后的不完整的命令, 這時(shí)候, 服務(wù)器會(huì)發(fā)出警告日志:

* Reading RDB preamble from AOF file... * Reading the remaining AOF tail... # !!! Warning: short read while loading the AOF file !!! # !!! Truncating the AOF at offset 439 !!! # AOF loaded anyway because aof-load-truncated is enabled

你可以改變默認(rèn)配置來(lái)強(qiáng)制停止這種事情發(fā)生, 但是默認(rèn)配置會(huì)忽略最后這個(gè)不完整的命令, 為了保證服務(wù)重啟后可用.

老版本的 Redis 不會(huì)自動(dòng)恢復(fù), 需要做以下步驟來(lái)恢復(fù):

對(duì) AOF 文件進(jìn)行備份.

使用 Redis 提供的工具 redis-check-aof 修復(fù)該 AOF 文件:

$ redis-check-aof –fix

可以執(zhí)行 diff -u 檢查兩個(gè) AOF 文件的差異, 確認(rèn)錯(cuò)誤被修復(fù).

用修復(fù)后的 AOF 文件重啟 Redis 服務(wù), 重建數(shù)據(jù)集.

AOF 文件被損壞了怎么辦?

如果 AOF 文件不僅被截?cái)嗔? 中間還被插入了無(wú)效的字節(jié), 事情將變得更加復(fù)雜, Redis 在啟動(dòng)的時(shí)候會(huì)中斷并提示:

* Reading the remaining AOF tail... # Bad file format reading the append only file: make a backup of your AOF file, then use ./redis-check-aof --fix  filename

最好是用 redis-check-aof 工具修復(fù), 首先不適用 –fix 選項(xiàng), 找到問(wèn)題, 跳過(guò)該文件的錯(cuò)誤位置, 查看是否可以手動(dòng)修復(fù)該文件,  AOF 使用與 Reids 一致的協(xié)議格式, 所以非常便于手動(dòng)修復(fù), 否則就使用工具修復(fù)該文件, 這種情況, 從無(wú)效的位置到文件結(jié)束的數(shù)據(jù)都可能被丟失,   如果損壞位置發(fā)生在開(kāi)頭的位置, 則相當(dāng)于丟失整個(gè)數(shù)據(jù)集.

它是怎樣工作的?

日志重寫(xiě)使用了與快照一致的拷貝即寫(xiě) (copy-on-write) 的方式, 步驟如下:

Redis 執(zhí)行 forks 派生, 這樣就有一個(gè)主進(jìn)程和一個(gè)子進(jìn)程.

子進(jìn)程開(kāi)始寫(xiě)入一個(gè)新的 AOF 到零時(shí)文件中.

Redis 繼續(xù)追加到舊的 AOF 文件的同時(shí)也追加到 AOF 重寫(xiě)緩沖區(qū) aof_rewrite_buf, 所以即使重新失敗, 也是數(shù)據(jù)安全的.

當(dāng)子進(jìn)程完成了 AOF 文件重寫(xiě), 父進(jìn)程收到一個(gè)完成信號(hào), 將緩存中的數(shù)據(jù)追加到新的 AOF 文件.

最后將新的 AOF 文件重命名為老的 AOF 文件完成替換操作, 以后的數(shù)據(jù)將寫(xiě)入新的 AOF 文件.

怎樣從 dump.rdb 快照切換到 AOF

在 Redis2.0 和 Redis2.2 用不同的步驟來(lái)切換到 AOF, 而且 Redis2.2 切換到 AOF 更簡(jiǎn)單, 不需要重啟.

Redis = 2.2

將最近的 dump.rdb 文件備份.

將備份文件傳輸?shù)桨踩牡胤?

執(zhí)行以下兩個(gè)命令:

鴻蒙官方戰(zhàn)略合作共建——HarmonyOS 技術(shù)社區(qū)

redis-cli config set save #取消 RDB

redis-cli config set appendonly yes #開(kāi)啟 AOF

檢查確認(rèn)數(shù)據(jù)庫(kù)中的鍵個(gè)數(shù)沒(méi)有丟失.

檢查寫(xiě)操作都正確的追加進(jìn)了 AOF 文件.

第一個(gè)配置命令表示啟用 AOF 功能. 這樣 Redis 會(huì)阻塞來(lái)生成初始的備份, 然后打開(kāi)新文件來(lái)寫(xiě)入操作記錄,   后面的寫(xiě)操作將會(huì)持續(xù)追加到該 AOF 文件中.

第二個(gè)配置命令用來(lái)關(guān)閉 RDB 快照持久化. 這是可選的, 如果保留 save 表示同時(shí)使用 RDB 和 AOF 持久化.

重要: 記住同時(shí)修改 redis.conf 配置文件來(lái)打開(kāi) AOF, 否則服務(wù)重啟時(shí)將使用原來(lái)的配置.

Redis 2.0

將最近的 dump.rdb 文件備份.

將備份文件傳輸?shù)桨踩牡胤?

停止所有寫(xiě)操作.

執(zhí)行后臺(tái)重寫(xiě) AOF 命令 redis-cli BGREWRITEAOF. 該操作會(huì)創(chuàng)建 AOF 文件.

當(dāng) AOF 備份完成后, 停止 Redis 服務(wù).

編輯 redis.conf, 啟用 AOF 功能.

重啟服務(wù)

檢查確認(rèn)數(shù)據(jù)庫(kù)中的鍵個(gè)數(shù)沒(méi)有丟失.

檢查寫(xiě)操作都正確的追加進(jìn)了 AOF 文件.

在 AOF 和 RDB 之間交互

Redis = 2.4 會(huì)保證當(dāng) RDB 快照在運(yùn)行時(shí), 避免觸發(fā)一個(gè) AOF 重寫(xiě)進(jìn)程, 或者當(dāng) AOF 重寫(xiě)已經(jīng)運(yùn)行時(shí), 不允許后臺(tái)保存快照 BGSAVE.   這可以防止兩個(gè)后臺(tái)進(jìn)程同時(shí)產(chǎn)生高負(fù)載的磁盤(pán) I /O.

備份 Redis 數(shù)據(jù)

開(kāi)始本節(jié)內(nèi)容前, 請(qǐng)確認(rèn)已經(jīng)對(duì)數(shù)據(jù)庫(kù)進(jìn)行備份, 如果磁盤(pán)損壞, 云實(shí)例消失等, 沒(méi)有備份意味著數(shù)據(jù)面臨著巨大風(fēng)險(xiǎn), 會(huì)消失在 黑洞  /dev/null 中.

Redis 對(duì)于數(shù)據(jù)備份非常友好, 即使數(shù)據(jù)庫(kù)數(shù)據(jù)庫(kù)運(yùn)行中也允許你對(duì)數(shù)據(jù)進(jìn)行拷貝備份: RDB 文件產(chǎn)生時(shí)就不會(huì)被修改, 快照備份期間, 它會(huì)生成零時(shí)的文件,   當(dāng)快照最終備份完成后采用重命名替換原來(lái)的 RDB 文件.

這意味著服務(wù)在運(yùn)行時(shí), 拷貝 RDB 文件是非常安全的, 下面是我們的建議:

在服務(wù)器上, 創(chuàng)建定時(shí)任務(wù) CronJob, 每小時(shí)執(zhí)行一次 RDB 快照, 保存到一個(gè)目錄, 并且在另外一個(gè)目錄下保存每日快照.

每次定時(shí)任務(wù)執(zhí)行時(shí), 確認(rèn)使用 find 命令查找最舊的快照, 將它們刪除, 對(duì)于每小時(shí)快照, 你可以保留最近 48 小時(shí), 對(duì)于每天快照,   你可以保留 1~2 個(gè)月. 并確包快照名包含時(shí)間信息.

每天至少做一次數(shù)據(jù)轉(zhuǎn)存, 比如將 RDB 快照轉(zhuǎn)存到其他數(shù)據(jù)中心, 或者至少?gòu)漠?dāng)前 Redis 服務(wù)物理機(jī)轉(zhuǎn)存到其他地方.

如果你使用 ROF 持久化方式, 仍然可以拷貝 AOF 文件來(lái)做備份. 這個(gè) AOF 文件即使丟失最后一小段數(shù)據(jù),  Redis 也可以重建它們(請(qǐng)參考上面的截?cái)?AOF 文件處理方式)

災(zāi)難恢復(fù)

災(zāi)難恢復(fù)和備份基本是一致的, 加上可以在許多不同的數(shù)據(jù)中心間轉(zhuǎn)存這些備份數(shù)據(jù). 這種情況下, 即使影響到最主要的數(shù)據(jù)中心,   其他地方的備份也是安全并且可以恢復(fù)的.

針對(duì)剛起步, 沒(méi)有太多的資金來(lái)做大型備份, 這里也提供了一些不需要太大開(kāi)銷(xiāo)的災(zāi)備恢復(fù)技術(shù):

AmazonS3 對(duì)象存儲(chǔ)或其他類(lèi)似服務(wù)是一個(gè)實(shí)現(xiàn)災(zāi)備恢復(fù)系統(tǒng)的好方法. 只需將每小時(shí)或每日的 RDB 快照加密后傳輸?shù)?S3 即可, 你可以使用 gpg  -c(使用對(duì)稱(chēng)加密模式)對(duì)數(shù)據(jù)加密. 請(qǐng)確認(rèn)將密碼保存到不同的安全的地方(比如拷貝一份交給最重要的人來(lái)管理). 建議使用多種存儲(chǔ)服務(wù)來(lái)提高數(shù)據(jù)安全性.

使用 SCP(SSH 的一部分)命令來(lái)將數(shù)據(jù)轉(zhuǎn)存到其他服務(wù)器. 這是一個(gè)簡(jiǎn)單而且安全的方法: 在云端,   獲取遠(yuǎn)離當(dāng)前 Redis 服務(wù)的一個(gè)小型虛擬專(zhuān)用服務(wù)器 VPS, 在數(shù)據(jù)端, 安裝 ssh, 生成不帶密碼的 ssh 客戶(hù)端密鑰,   將它添加到 VPS 的 authorized_keys 文件, 這樣就可以繼續(xù)實(shí)現(xiàn)自動(dòng)免密轉(zhuǎn)存?zhèn)浞輸?shù)據(jù)到 VPS, 為了提高數(shù)據(jù)安全, 可以使用不同運(yùn)營(yíng)商,   不同網(wǎng)絡(luò)區(qū)域的 VPS.

這種方式可能會(huì)導(dǎo)致文件傳輸失敗, 所以在傳輸完成后, 至少要增加文件完整性校驗(yàn), 比如校驗(yàn)文件大小, 如果使用 VPS, 甚至可以使用 SHA1 校驗(yàn).

你也需要部署獨(dú)立的監(jiān)控報(bào)警系統(tǒng), 對(duì)備份過(guò)程進(jìn)行監(jiān)控, 在備份失敗時(shí)能及時(shí)發(fā)現(xiàn)并修復(fù).

到此，關(guān)于“什么是 RDB 和 AOF”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注丸趣 TV 網(wǎng)站，丸趣 TV 小編會(huì)繼續(xù)努力為大家?guī)?lái)更多實(shí)用的文章！