“Redis备份与恢复”的版本间的差异
() |
|||
第14行: | 第14行: | ||
</pre> | </pre> | ||
− | == == | + | == usage== |
+ | <pre> | ||
+ | #导出 | ||
+ | redis-dump -u :[email protected]:6379 > redis.json | ||
+ | |||
+ | #导入 | ||
+ | cat redis.json | redis-load -u :youpasswor127.0.0.1:6379 | ||
+ | cat 127.0.0.1.json | redis-load -u :[email protected]:6379 | ||
+ | |||
+ | </pre> | ||
== == | == == |
2019年11月3日 (日) 13:46的最新版本
目录
redis-dump
redis-dump ins
How to Install Ruby2.3 on centos7
ins by gem
如果是国内 # 移除gem自带源 gem sources --remove https://rubygems.org/ # 添加淘宝源 gem sources -a https://ruby.taobao.org/ #ins gem install redis-dump -V
usage
#导出 redis-dump -u :[email protected]:6379 > redis.json #导入 cat redis.json | redis-load -u :youpasswor127.0.0.1:6379 cat 127.0.0.1.json | redis-load -u :[email protected]:6379
redis-shake
自带功能
备份
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