redis开启rdb和aof后文件正确恢复

1.服务器环境:

3主3从,192.168.24.16,192.168.24.17,192.168.24.18,每一台服务器上2个节点,分别为主节点和从节点

 2.备份

开启的备份策略是默认的rdb,aof没有打开

使用 Redis Desktop Manager连接,数据库中有3条数据

现在我需要同时开启aof和rdb两个持久化策略,假如我们直接关闭redis,并且打开aof的开关,我们看看保存的数据还在不在。

更改配置之后重启redis发现数据没了

 

### Redis RDB AOF 持久化机制对比及优缺点 #### 1. RDB 持久化 RDBRedis Database)是一种快照式的持久化方式,通过将内存中的数据定期保存到磁盘上的二进制文件中来实现数据的持久化。 - **优点**: - 高性能:RDB 文件是一个紧凑压缩的二进制文件,占用空间小,恢复速度非常快[^4]。 - 适合备份:由于其紧凑性,RDB 文件非常适合用于全量备份或远程存储,例如每 6 小时执行一次 `bgsave` 并将文件复制到远程机器或分布式文件系统中[^4]。 - 数据加载速度快:Redis 在启动时加载 RDB 文件恢复数据的速度远远快于 AOF 的方式[^4]。 - **缺点**: - 数据丢失风险:RDB 是基于时间间隔的快照机制,因此在两次快照之间发生的数据修改可能会因为服务器宕机而丢失[^5]。 - 不支持实时持久化:RDB 方式无法做到实时或秒级持久化,因为每次运行 `bgsave` 都需要执行 fork 创建子进程,属于重量级操作,频繁执行成本过高[^4]。 - 兼容性问题:RDB 文件使用特定的二进制格式保存,随着 Redis 版本的演进,不同版本之间的 RDB 文件可能存在兼容性问题[^4]。 #### 2. AOF 持久化 AOF(Append Only File)是一种日志记录式的持久化方式,通过记录每个写操作命令的方式,将这些命令追加到文件中,从而实现数据的持久化。 - **优点**: - 数据安全性高:AOF 能够提供更高的数据安全性,因为它几乎可以做到实时持久化。每次写操作都会被追加到 AOF 文件中,即使服务器意外宕机,数据丢失也非常少[^5]。 - 支持多种同步策略:AOF 提供了三种不同的同步策略(`always`、`everysec`、`no`),用户可以根据需求选择合适的同步频率[^3]。 - 易于修复:AOF 文件是纯文本形式,便于进行人工检查修复[^3]。 - **缺点**: - 文件体积大:由于 AOF 记录的是所有写操作的命令,因此文件体积通常比 RDB 文件大得多。 - 恢复速度慢:相比 RDBAOF 文件恢复速度较慢,因为它需要逐条重新执行写命令[^4]。 - 需要重写机制:为了防止 AOF 文件过大,Redis 提供了 AOF 重写功能,该功能会生成一个新的更小的 AOF 文件,但此过程也会消耗一定的资源。 #### 3. 使用场景 - **RDB 适用场景**: - 对数据完整性要求较低的场景,能够容忍一定程度的数据丢失。 - 需要快速恢复数据的场景,例如频繁重启或迁移 Redis 实例。 - 数据备份或灾难恢复的场景,RDB 文件适合用作远程备份或存档。 - **AOF 适用场景**: - 对数据完整性要求较高的场景,不能容忍数据丢失[^5]。 - 需要实时或接近实时持久化的场景,例如金融交易系统或关键业务数据存储[^3]。 - 需要手动检查或修复数据的场景,AOF 文件的可读性更强。 #### 4. 混合持久化 Redis 还提供了混合持久化的机制,结合了 RDB AOF 的优势。在这种模式下,Redis 会在 AOF 文件中以 RDB 格式保存一个完整的快照,随后再追加增量的写操作。这种方式既能保证数据的安全性,又能减少 AOF 文件的体积。 ```python # 示例:配置 Redis 的持久化方式 # 在 redis.conf 中设置 RDB AOF 的相关参数 save 900 1 # 每 900 秒至少有 1 次修改时触发 bgsave appendonly yes # 开启 AOF 持久化 ``` ###
评论 5
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值