Redis持久化和数据恢复的坑

redis提供了rdbaof两种持久化机制,rdb默认开启,aof默认关闭。
当两种持久化机制都开启时,redis重启恢复数据时加载aof持久化的appendonly.aof文件,而rdb持久化的dump.rdb文件不会被加载到内存中。

  • 情景:开启rdb,关闭aof
    通过redis-cli SHUTDOWN这种方式停掉redis,这是一种安全的退出方式,redis会在退出的时候将内存中的数据立即生成一份完整的rdb快照。
    通过kill -9杀死redis进程,这种方式会导致redis异常退出,从而导致内存中的数据没有到达save指定的检查点,进而丢失内存中的数据。

  • 情景:开启rdb,关闭aof,待dump.rdb有数据后,再开启aof
    redis持久化dump.rdb后,启用aof持久化,再重启redisredis只会加载aof持久化的appendonly.aof文件,如果它不存在,那会创建一个新的空的文件,从而导致内存中丢失dump.rdb的数据。

    解决方式:停止redis,关闭aof,重启redis,确保dump.rdb数据恢复在内存中,使用命令行热修改redis配置的方式打开aof,此时redis就会以aof持久化的形式将内存中的数据写入appendonly.aof文件,然后停止redis,修改配置文件将aof手动打开。

    Redis持久化和数据恢复的坑_第1张图片
    这里写图片描述

  • 情景:主从架构的master关闭rdbaof持久化,slave作为master的数据热备
    在采用master-slave的水平扩展架构的时候,格外的需要注意:master必须要开启持久化,不建议用slave节点作为master节点的数据热备。
    我们知道主从复制的架构中,所有的写操作交由master负责,slave分担读的操作,slave中的数据是从master同步过来的。假如masterrdbaof都关闭了,数据全部在内存中,那么master宕机重启时,发现本地没有可以恢复的数据,导致master内存数据为空,然后master将空的数据集同步到slave节点,导致slave的数据全部清空。因此master必须要开启持久化!
    即使我们采用高可用机制的哨兵模式,即master宕机时,slave节点通过选举转变为master节点,在这种情况下,可能哨兵模式还没检测到master节点宕机,master节点就自动重启了,因此还是可能导致所有slave节点数据清空。

你可能感兴趣的:(redis)