默认情况下60秒刷新到disk一次[save 60 10000 当有1w条keys数据被改变时],Redis的数据集保存在叫dump.rdb一个二进制文件,这种策略被称为快照。
也可以手动调用Save或BGSAVE命令的:
RDB快照保存有两种方式,save和bgsave。
相同点:
都会调用rdbSave函数来进行快照保存。
不同点:
(1) SAVE 直接调用rdbSave ,阻塞Redis 主进程,直到保存完成为止。在主进程阻塞期间,服务器不能处理客户端的任何请求。
(2)BGSAVE 则fork 出一个子进程,子进程负责调用rdbSave ,并在保存完成之后向主进程发送信号,通知保存已完成。因为rdbSave 在子进程被调用,所以Redis 服务器在
BGSAVE 执行期间仍然可以继续处理客户端的请求。
下面是bgsave的被应用场景:
1. redis的配置文件可配置开启rdb方式,在m秒时间内发生n次变更则要进行rdb文件保存。
redis服务器启动后主要是通过时间事件来运行serverCron函数进行条件检查,若满足条件则进行rdb文件保存。
- /* If there is not a background saving/rewrite in progress check if
- * we have to save/rewrite now */
- // 如果有需要,开始 RDB 文件的保存
- for (j = 0; j < server.saveparamslen; j++) {
- struct saveparam *sp = server.saveparams+j;
- if (server.dirty >= sp->changes &&
- server.unixtime-server.lastsave > sp->seconds) {
- redisLog(REDIS_NOTICE,"%d changes in %d seconds. Saving...",
- sp->changes, sp->seconds);
- <span style="color:#ff0000;"> rdbSaveBackground(server.rdb_filename);</span>
- break;
- }
- }
2. redis的主从复制模式也是采用的bgsave方式,将rdb快照发给从服务器来进行备份。
快照易恢复,文件也小,但是如果遇到宕机等情况的时候快照的数据可能会不完整。此时可能需要启用另一种持久化方式AOF,在配置文件中打开[appendonly yes]。
AOF刷新日志到disk的规则:
appendfsync always #always 表示每次有写操作都进行同步,非常慢,非常安全。
appendfsync everysec #everysec表示对写操作进行累积,每秒同步一次
官方的建议的everysec,安全,就是速度不够快,如果是机器出现问题可能会丢失1秒的数据。
也可以手动执行bgrewriteaof进行AOF备份:
我们现在的做法是一主(Master)多从(Slave),主库不开启AOF持久化,只是每天备份一下RDB[官方给的建议是每小时备份RDB文件,看你的策略了],而在从库上开启AOF备份,并且会用脚本将相应的备份文件推送到备份服务器。
当redis服务器挂掉时,重启时将按照以下优先级恢复数据到内存:
- 如果只配置AOF,重启时加载AOF文件恢复数据;
- 如果同时 配置了RBD和AOF,启动是只加载AOF文件恢复数据;
- 如果只配置RBD,启动是讲加载dump文件恢复数据。
恢复时需要注意,要是主库挂了不能直接重启主库,否则会直接覆盖掉从库的AOF文件,一定要确保要恢复的文件都正确才能启动,否则会冲掉原来的文件。
源自: http://haili.me/archives/335
http://blog.csdn.net/enjoyinwind/article/details/16370975