“Redis备份与恢复”的版本间的差异
| 第1行： | 第1行： | ||
=redis-dump= | =redis-dump= | ||
| − | == == | + | == redis-dump ins== |
| + | [[How to Install Ruby2.3 on centos7]] | ||
| + | |||
== == | == == | ||
2019年11月2日 (六) 05:44的版本
目录
redis-dump
redis-dump ins
How to Install Ruby2.3 on centos7
备份
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命令将其设置成新的主数据库的从数据库，即可将数据同步回来。
