Redis RDB、AOF持久化详解
生活随笔
收集整理的這篇文章主要介紹了
Redis RDB、AOF持久化详解
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
概述
Redis 提供了2種不同的持久化方式,分別為RDB和AOF
- RDB能夠定時地對數據進行快照存儲,因為是定時的,所以服務宕機時存在丟失數據的風險
- AOF能夠記錄每一次的寫操作,當服務重啟的時候會重新執行這些命令來恢復數據,恢復完整度高,但是比較耗時
- Redis服務啟動時,根據配置的持久化方式來決定加載RDB或者AOF恢復數據。如果2種持久化都開啟,則優先加載AOF
RDB
RDB 相關配置
# save <seconds> <changes> # 在900秒內保存1次、300秒內保存10次、60秒內保存10000次,這些條件符合其中一個就會觸發RDB快照保存 save 900 1 save 300 10 save 60 10000# RDB快照存儲失敗時,是否停止接收新的寫入操作 stop-writes-on-bgsave-error yes# 是否開啟RDS快照文件的壓縮存儲(不開啟會導致dump.rdb文件過大) rdbcompression yes# 對RDB格式進行校驗,但是在加載或保存RDB文件時有10%的性能損耗 rdbchecksum yes# RDB快照文件名 dbfilename dump.rdb# 存放RDB、AOF文件的目錄 dir /usr/local/redis-5.0.8/dataRDB 詳解
- 如果Redis服務是正常退出,會自動保存最新數據到rdb,然后再退出服務
- 如果Redis服務是異常中斷,例如kill命令直接終止,則不會觸發RDB快照保存
- 在保存RDB文件時,父進程會fork出一個子進程來處理,然后父進程不需要再做其他IO操作。
- 在恢復大的數據集時,RDB會比AOF更快
AOF
AOF 相關配置
# 是否開啟AOF持久化 appendonly no # AOF持久化文件名 appendfilename "appendonly.aof"# 持久化策略。 # always:每次寫入數據分別觸發持久化,并完成磁盤同步 # everysec:每秒持久化一次,并完成磁盤同步(推薦) # no:將數據交給操作系統處理,更快,也更不安全 appendfsync everysec# 當AOF文件正在rewrite時,是否停止appendfsync操作 # no:不停止,也就是追加操作照常進行 # yes:停止,不進行追加操作,而只是將其放在緩沖區 no-appendfsync-on-rewrite no# AOF文件增大一定的比例后(percentage),自動觸發重寫機制bgrewriteaof # 只有當文件超過一定的大小(min-size),bgrewriteaof才會執行,避免文件很小的時候一直反復的rewrite auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mbAOF 文件重寫機制
AOF的機制是不斷地將寫命令追加到文件末尾,隨著日積月累文件會變得越來越大,這時就需要一個重寫機制來處理。
例如:你對1個數值進行INCR遞增100次,AOF記錄了100次INCR命令,實際上只需要1條SET命令就能保存最新的值了。
為了處理這種情況,AOF重寫機制(bgrewriteaof)會創建1個新的AOF文件,包含了重建當前數據所需要的最少命令,創建完畢后直接替換掉原文件。
AOF 文件損壞處理
服務器宕機時可能導致AOF文件損壞,此時在Redis重啟時不會加載這個AOF文件。這種情況下,可以通過以下方式處理:
RDB切換到AOF
假設Redis當前使用的是RDB,并且有了一定的數據量,這時候想啟用AOF時,應該怎么操作呢?
方法一
直接修改redis.conf文件,把appendonly改成yes,然后重啟redis。
注意:這時原數據將被全部清空
注意:這時原數據將被全部清空
注意:這時原數據將被全部清空
方法二
通過redis-cli連接redis,執行命令進行設置,這時將直接啟用aof,并將當前的數據寫入到appendonly.aof文件。
CONFIG SET appendonly yes注意:redis.conf記得同步設置appendonly yes,否則下次重啟aof不會啟用
總結
以上是生活随笔為你收集整理的Redis RDB、AOF持久化详解的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Linux安装Redis完整步骤
- 下一篇: SpringBoot实现Redis分布式