共計 1668 個字符，預計需要花費 5 分鐘才能閱讀完成。

自動寫代碼機器人，免費開通

丸趣 TV 小編給大家分享一下如何查看 redis 是否持久化，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

                                                           info 查看持久化信息

redis-cli info persistence#

loading：服務器是否正在載入持久化文件

rdb_changes_since_last_save：離最近一次成功生成 rdb 文件，寫入命令的個數，即有多少個寫入命令沒有持久化

rdb_bgsave_in_progress：服務器是否正在創(chuàng)建 rdb 文件

rdb_last_save_time：離最近一次成功創(chuàng)建 rdb 文件的時間戳。當前時間戳 – rdb_last_save_time= 多少秒未成功生成 rdb 文件

rdb_last_bgsave_status：最近一次 rdb 持久化是否成功

rdb_last_bgsave_time_sec：最近一次成功生成 rdb 文件耗時秒數

rdb_current_bgsave_time_sec：如果服務器正在創(chuàng)建 rdb 文件，那么這個域記錄的就是當前的創(chuàng)建操作已經耗費的秒數

rdb_last_cow_size：RDB 過程中父進程與子進程相比執(zhí)行了多少修改 (包括讀緩沖區(qū)，寫緩沖區(qū)，數據修改等)。

aof_enabled：是否開啟了 aof

aof_rewrite_in_progress：標識 aof 的 rewrite 操作是否在進行中

aof_rewrite_scheduled：rewrite 任務計劃，當客戶端發(fā)送 bgrewriteaof 指令，如果當前 rewrite 子進程正在執(zhí)行，那么將客戶端請求的 bgrewriteaof 變?yōu)橛媱澣蝿眨?aof 子進程結束后執(zhí)行 rewrite

aof_last_rewrite_time_sec：最近一次 aof rewrite 耗費的時長

aof_current_rewrite_time_sec：如果 rewrite 操作正在進行，則記錄所使用的時間，單位秒

aof_last_bgrewrite_status：上次 bgrewriteaof 操作的狀態(tài)

aof_last_write_status：上次 aof 寫入狀態(tài)

aof_last_cow_size：AOF 過程中父進程與子進程相比執(zhí)行了多少修改 (包括讀緩沖區(qū)，寫緩沖區(qū)，數據修改等)。

appendfsync 有三個選項：always、everysec 和 no：

1、選擇 always 的時候服務器會在每執(zhí)行一個事件就把 AOF 緩沖區(qū)的內容強制性的寫入硬盤上的 AOF 文件里，可以看成你每執(zhí)行一個 redis 寫入命令就往 AOF 文件里記錄這條命令，這保證了數據持久化的完整性，但效率是最慢的，卻也是最安全的；

2、配置成 everysec 的話服務端每執(zhí)行一次寫操作（如 set、sadd、rpush）也會把該條命令追加到一個單獨的 AOF 緩沖區(qū)的末尾，并將 AOF 緩沖區(qū)寫入 AOF 文件，然后每隔一秒才會進行一次文件同步把內存緩沖區(qū)里的 AOF 緩存數據真正寫入 AOF 文件里，這個模式兼顧了效率的同時也保證了數據的完整性，即使在服務器宕機也只會丟失一秒內對 redis 數據庫做的修改；

3、將 appendfsync 配置成 no 則意味 redis 數據庫里的數據就算丟失你也可以接受，它也會把每條寫命令追加到 AOF 緩沖區(qū)的末尾，然后寫入文件，但什么時候進行文件同步真正把數據寫入 AOF 文件里則由系統自身決定，即當內存緩沖區(qū)的空間被填滿或者是超過了設定的時限后系統自動同步。這種模式下效率是最快的，但對數據來說也是最不安全的，如果 redis 里的數據都是從后臺數據庫如 mysql 中取出來的，屬于隨時可以找回或者不重要的數據，那么可以考慮設置成這種模式。

以上是如何查看 redis 是否持久化的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注丸趣 TV 行業(yè)資訊頻道！

向 AI 問一下細節(jié)

丸趣 TV 網 – 提供最優(yōu)質的資源集合！