Redis备份与恢复

来自linux中国网wiki
docker>Evan2019年4月27日 (六) 13:33的版本 →‎总结
(差异) ←上一版本 | 最后版本 (差异) | 下一版本→ (差异)
跳到导航 跳到搜索

备份

Redis的SAVE命令和BGSAVE命令用于将当前数据库备份

SAVE和BGSAVE命令的区别在于:SAVE命令是阻塞主进程,save操作完成之后,主进程才开始工作,客户端可以连接;BGSAVE命令是fork一个专门save的子进程,此操作不会影响主进程 注:SAVE只是将当前的数据库备份,备份文件名默认为dump.rdb,可通过配置文件修改备份文件名 dbfilename xxx.rdb(发现一个问题:如果要对多个数据库进行备份,那么最终只能备份最后一个数据库,因为dump.rdb文件会相互覆盖)

恢复

将备份的RDB文件,放在指定目录,重启Redis即可恢复数据


备份的RDB文件: 通过命令redis 127.0.0.1:6379> CONFIG GET dir查看执行SAVE命令之后,redis默认存放备份文件的目录;通过命令redis 127.0.0.1:6379> CONFIG GET dbfilename查看备份RDB文件的文件名称;

指定目录: 通过命令redis 127.0.0.1:6379> CONFIG GET dir,得出redis从哪个目录读取备份文件(一般只要直接重启Redis就能恢复数据,因为备份的默认目录和启动读取的目录是同一个,但是如果公司有特定的要求,备份文件统一放在其他目录,此时则需要将待还原的RDB文件mv到这个指定目录)

PS:在练习恢复数据时,碰到一个坑: 1.set一些数据 2. 执行save命令 3. del所有的key 4. 重启,发现数据没有恢复过来 原因:还记得上文提到过的Redis自动RDB备份吗?我在执行第三步操作时,改变了1个以上的key的值,并且这个时间正好是Redis自动备份900秒的最后一秒,所以此时Redis又自动备份了一次,dump.rdb覆盖了旧的rdb文件,还原回去,自然是del之后的数据了。(当然我这个不是凭空臆想的哈,是因为我在步骤2执行save时,看了一下dump.rdb文件的大小,98K,在准备重启之前,我又看了一下dump.rdb文件,73K,说



自动开启RDB持久化


修改配置文件
after 900 sec (15 min) if at least 1 key changed
900秒(15分钟)内至少1个key值改变(则进行数据库保存--持久化)
    
after 300 sec (5 min) if at least 10 keys changed
300秒(5分钟)内至少10个key值改变(则进行数据库保存--持久化)
    
after 60 sec if at least 10000 keys changed
60秒(1分钟)内至少10000个key值改变(则进行数据库保存--持久化) 

save 900 1
save 300 10
save 60 10000

备份文件的名称
dbfilename dump.rdb

备份文件存放路径
dir ./bak 

进行AOF备份

 

开启AOF功能

修改配置文件
#此选项为aof功能的开关,默认为“no”,通过“yes”来开启aof功能
appendonly yes  

#指定aof文件名称
appendfilename appendonly.aof

#备份文件存放路径(此参数同样适用于指定RDB备份文件存放路径)
dir ./


设置保存模式

AOF有3种方式将操作命令存入AOF文件
1. appendfsync no 不保存
只执行WHRITE操作,SAVE操作会被略过,只有在Redis被关闭、AOF功能被关闭、系统的写缓存被刷新(如缓存已被写满)这三种情况,SAVE操作会被执行,但是这三种情况都会引起Redis主进程阻塞
2. appendfsync everysec 每秒钟保存一次
这种模式中,SAVE原则上每隔一秒钟就会执行一次,具体的执行周期和文件写入、保存时,Redis所处的状态有关,此模式下SAVE操作由后台子线程调用,不会引起服务器主进程的阻塞
3. appendfsync always 每执行一个命令保存一次
在这种模式下,每执行一个命令,WRITE和SAVE都会被执行,且SAVE操作会阻塞主进程

总结

RDB持久化,性能更好(所有操作均由子进程处理,主进程不进行任何IO操作),数据一致性一般。AOF持久化,数据一致性更好,性能一般(记录操作日志,写入日志和执行日志恢复数据的时间都比RDB更长)

优点及应用场景

读写分离 通过复制可以实现读写分离以提高服务器的负载能力。在常见的场景中,读的频率大于写,当单机的Redis无法应付大量的读请求时(尤其是较耗资源的请求,比如SORT命令等)可以通过复制功能建立多个从数据库,主数据库只进行写操作,而从数据库负责读操作。

从数据库持久化 持久化通常相对比较耗时,为了提高性能,可以通过复制功能建立一个(或若干个)从数据库,并在从数据库中启用持久化,同时在主数据库禁用持久化。当从数据库崩溃时重启后主数据库会自动将数据同步过来,所以无需担心数据丢失。而当主数据库崩溃时,需要在从数据库中使用SLAVEOF NO ONE命令将从数据库提升成主数据库继续服务,并在原来的主数据库启动后使用SLAVEOF命令将其设置成新的主数据库的从数据库,即可将数据同步回来。

see also

初识Redis(三):Redis数据备份、恢复与持久化

Redis数据备份与恢复