参考资料:
Redis Persistence http://redis.io/topics/persistence
Google Groups https://groups.google.com/forum/?fromgroups=#!forum/redis-db
一、对Redis持久化的探讨与理解
目前Redis持久化的方式有两种: RDB 和 AOF
首先,我们应该明确持久化的数据有什么用,答案是用于重启后的数据恢复。
Redis是一个内存数据库,无论是RDB还是AOF,都只是其保证数据恢复的措施。
所以Redis在利用RDB和AOF进行恢复的时候,都会读取RDB或AOF文件,重新加载到内存中。
RDB就是Snapshot快照存储,是默认的持久化方式。
可理解为半持久化模式,即按照一定的策略周期性的将数据保存到磁盘。
对应产生的数据文件为dump.rdb,通过配置文件中的save参数来定义快照的周期。
下面是默认的快照设置:
save 900 1 #当有一条Keys数据被改变时,900秒刷新到Disk一次 save 300 10 #当有10条Keys数据被改变时,300秒刷新到Disk一次 save 60 10000 #当有10000条Keys数据被改变时,60秒刷新到Disk一次
Redis的RDB文件不会坏掉,因为其写操作是在一个新进程中进行的。
当生成一个新的RDB文件时,Redis生成的子进程会先将数据写到一个临时文件中,然后通过原子性rename系统调用将临时文件重命名为RDB文件。
这样在任何时候出现故障,Redis的RDB文件都总是可用的。
同时,Redis的RDB文件也是Redis主从同步内部实现中的一环。
第一次Slave向Master同步的实现是:
Slave向Master发出同步请求,Master先dump出rdb文件,然后将rdb文件全量传输给slave,然后Master把缓存的命令转发给Slave,初次同步完成。
第二次以及以后的同步实现是:
Master将变量的快照直接实时依次发送给各个Slave。
但不管什么原因导致Slave和Master断开重连都会重复以上两个步骤的过程。
Redis的主从复制是建立在内存快照的持久化基础上的,只要有Slave就一定会有内存快照发生。
可以很明显的看到,RDB有它的不足,就是一旦数据库出现问题,那么我们的RDB文件中保存的数据并不是全新的。
从上次RDB文件生成到Redis停机这段时间的数据全部丢掉了。
AOF(Append-Only File)比RDB方式有更好的持久化性。
由于在使用AOF持久化方式时,Redis会将每一个收到的写命令都通过Write函数追加到文件中,类似于MySQL的binlog。
当Redis重启是会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。
对应的设置参数为:
$ vim /opt/redis/etc/redis_6379.conf
appendonly yes #启用AOF持久化方式 appendfilename appendonly.aof #AOF文件的名称,默认为appendonly.aof # appendfsync always #每次收到写命令就立即强制写入磁盘,是最有保证的完全的持久化,但速度也是最慢的,一般不推荐使用。 appendfsync everysec #每秒钟强制写入磁盘一次,在性能和持久化方面做了很好的折中,是受推荐的方式。 # appendfsync no #完全依赖OS的写入,一般为30秒左右一次,性能最好但是持久化最没有保证,不被推荐。
AOF的完全持久化方式同时也带来了另一个问题,持久化文件会变得越来越大。
比如我们调用INCR test命令100次,文件中就必须保存全部的100条命令,但其实99条都是多余的。
因为要恢复数据库的状态其实文件中保存一条SET test 100就够了。
为了压缩AOF的持久化文件,Redis提供了bgrewriteaof命令。
收到此命令后Redis将使用与快照类似的方式将内存中的数据以命令的方式保存到临时文件中,最后替换原来的文件,以此来实现控制AOF文件的增长。
由于是模拟快照的过程,因此在重写AOF文件时并没有读取旧的AOF文件,而是将整个内存中的数据库内容用命令的方式重写了一个新的AOF文件。
对应的设置参数为:
$ vim /opt/redis/etc/redis_6379.conf
no-appendfsync-on-rewrite yes #在日志重写时,不进行命令追加操作,而只是将其放在缓冲区里,避免与命令的追加造成DISK IO上的冲突。 auto-aof-rewrite-percentage 100 #当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时,自动启动新的日志重写过程。 auto-aof-rewrite-min-size 64mb #当前AOF文件启动新的日志重写过程的最小值,避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。
到底选择什么呢?下面是来自官方的建议:
通常,如果你要想提供很高的数据保障性,那么建议你同时使用两种持久化方式。
如果你可以接受灾难带来的几分钟的数据丢失,那么你可以仅使用RDB。
很多用户仅使用了AOF,但是我们建议,既然RDB可以时不时的给数据做个完整的快照,并且提供更快的重启,所以最好还是也使用RDB。
因此,我们希望可以在未来(长远计划)统一AOF和RDB成一种持久化模式。
在数据恢复方面:
RDB的启动时间会更短,原因有两个:
一是RDB文件中每一条数据只有一条记录,不会像AOF日志那样可能有一条数据的多次操作记录。所以每条数据只需要写一次就行了。
另一个原因是RDB文件的存储格式和Redis数据在内存中的编码格式是一致的,不需要再进行数据编码工作,所以在CPU消耗上要远小于AOF日志的加载。
二、灾难恢复模拟
既然持久化的数据的作用是用于重启后的数据恢复,那么我们就非常有必要进行一次这样的灾难恢复模拟了。
据称如果数据要做持久化又想保证稳定性,则建议留空一半的物理内存。因为在进行快照的时候,fork出来进行dump操作的子进程会占用与父进程一样的内存,真正的copy-on-write,对性能的影响和内存的耗用都是比较大的。
目前,通常的设计思路是利用Replication机制来弥补aof、snapshot性能上的不足,达到了数据可持久化。
即Master上Snapshot和AOF都不做,来保证Master的读写性能,而Slave上则同时开启Snapshot和AOF来进行持久化,保证数据的安全性。
首先,修改Master上的如下配置:
$ sudo vim /opt/redis/etc/redis_6379.conf
#save 900 1 #禁用Snapshot #save 300 10 #save 60 10000 appendonly no #禁用AOF
接着,修改Slave上的如下配置:
$ sudo vim /opt/redis/etc/redis_6379.conf
save 900 1 #启用Snapshot save 300 10 save 60 10000 appendonly yes #启用AOF appendfilename appendonly.aof #AOF文件的名称 # appendfsync always appendfsync everysec #每秒钟强制写入磁盘一次 # appendfsync no no-appendfsync-on-rewrite yes #在日志重写时,不进行命令追加操作 auto-aof-rewrite-percentage 100 #自动启动新的日志重写过程 auto-aof-rewrite-min-size 64mb #启动新的日志重写过程的最小值
分别启动Master与Slave
$ /etc/init.d/redis start
启动完成后在Master中确认未启动Snapshot参数
redis 127.0.0.1:6379> CONFIG GET save
1) "save"
2) ""
然后通过以下脚本在Master中生成25万条数据:
dongguo@redis:/opt/redis/data/6379$ cat redis-cli-generate.temp.sh
#!/bin/bash REDISCLI="redis-cli -a slavepass -n 1 SET" ID=1 while(($ID<50001)) do INSTANCE_NAME="i-2-$ID-VM" UUID=`cat /proc/sys/kernel/random/uuid` PRIVATE_IP_ADDRESS=10.`echo "$RANDOM % 255 + 1" | bc`.`echo "$RANDOM % 255 + 1" | bc`.`echo "$RANDOM % 255 + 1" | bc`\ CREATED=`date "+%Y-%m-%d %H:%M:%S"` $REDISCLI vm_instance:$ID:instance_name "$INSTANCE_NAME" $REDISCLI vm_instance:$ID:uuid "$UUID" $REDISCLI vm_instance:$ID:private_ip_address "$PRIVATE_IP_ADDRESS" $REDISCLI vm_instance:$ID:created "$CREATED" $REDISCLI vm_instance:$INSTANCE_NAME:id "$ID" ID=$(($ID+1)) done
dongguo@redis:/opt/redis/data/6379$ ./redis-cli-generate.temp.sh
在数据的生成过程中,可以很清楚的看到Master上仅在第一次做Slave同步时创建了dump.rdb文件,之后就通过增量传输命令的方式给Slave了。
dump.rdb文件没有再增大。
dongguo@redis:/opt/redis/data/6379$ ls -lh
total 4.0K
-rw-r--r-- 1 root root 10 Sep 27 00:40 dump.rdb
而Slave上则可以看到dump.rdb文件和AOF文件在不断的增大,并且AOF文件的增长速度明显大于dump.rdb文件。
dongguo@redis-slave:/opt/redis/data/6379$ ls -lh
total 24M
-rw-r--r-- 1 root root 15M Sep 27 12:06 appendonly.aof
-rw-r--r-- 1 root root 9.2M Sep 27 12:06 dump.rdb
等待数据插入完成以后,首先确认当前的数据量。
redis 127.0.0.1:6379> info
redis_version:2.4.17 redis_git_sha1:00000000 redis_git_dirty:0 arch_bits:64 multiplexing_api:epoll gcc_version:4.4.5 process_id:27623 run_id:e00757f7b2d6885fa9811540df9dfed39430b642 uptime_in_seconds:1541 uptime_in_days:0 lru_clock:650187 used_cpu_sys:69.28 used_cpu_user:7.67 used_cpu_sys_children:0.00 used_cpu_user_children:0.00 connected_clients:1 connected_slaves:1 client_longest_output_list:0 client_biggest_input_buf:0 blocked_clients:0 used_memory:33055824 used_memory_human:31.52M used_memory_rss:34717696 used_memory_peak:33055800 used_memory_peak_human:31.52M mem_fragmentation_ratio:1.05 mem_allocator:jemalloc-3.0.0 loading:0 aof_enabled:0 changes_since_last_save:250000 bgsave_in_progress:0 last_save_time:1348677645 bgrewriteaof_in_progress:0 total_connections_received:250007 total_commands_processed:750019 expired_keys:0 evicted_keys:0 keyspace_hits:0 keyspace_misses:0 pubsub_channels:0 pubsub_patterns:0 latest_fork_usec:246 vm_enabled:0 role:master slave0:10.6.1.144,6379,online db1:keys=250000,expires=0
当前的数据量为25万条key,占用内存31.52M。
然后我们直接Kill掉Master的Redis进程,模拟灾难。
dongguo@redis:/opt/redis/data/6379$ sudo killall -9 redis-server
我们到Slave中查看状态:
redis 127.0.0.1:6379> info
redis_version:2.4.17 redis_git_sha1:00000000 redis_git_dirty:0 arch_bits:64 multiplexing_api:epoll gcc_version:4.4.5 process_id:13003 run_id:9b8b398fc63a26d160bf58df90cf437acce1d364 uptime_in_seconds:1627 uptime_in_days:0 lru_clock:654181 used_cpu_sys:29.69 used_cpu_user:1.21 used_cpu_sys_children:1.70 used_cpu_user_children:1.23 connected_clients:1 connected_slaves:0 client_longest_output_list:0 client_biggest_input_buf:0 blocked_clients:0 used_memory:33047696 used_memory_human:31.52M used_memory_rss:34775040 used_memory_peak:33064400 used_memory_peak_human:31.53M mem_fragmentation_ratio:1.05 mem_allocator:jemalloc-3.0.0 loading:0 aof_enabled:1 changes_since_last_save:3308 bgsave_in_progress:0 last_save_time:1348718951 bgrewriteaof_in_progress:0 total_connections_received:4 total_commands_processed:250308 expired_keys:0 evicted_keys:0 keyspace_hits:0 keyspace_misses:0 pubsub_channels:0 pubsub_patterns:0 latest_fork_usec:694 vm_enabled:0 role:slave aof_current_size:17908619 aof_base_size:16787337 aof_pending_rewrite:0 aof_buffer_length:0 aof_pending_bio_fsync:0 master_host:10.6.1.143 master_port:6379 master_link_status:down master_last_io_seconds_ago:-1 master_sync_in_progress:0 master_link_down_since_seconds:25 slave_priority:100 db1:keys=250000,expires=0
可以看到master_link_status的状态已经是down了,Master已经不可访问了。
而此时,Slave依然运行良好,并且保留有AOF与RDB文件。
下面我们将通过Slave上保存好的AOF与RDB文件来恢复Master上的数据。
首先,将Slave上的同步状态取消,避免主库在未完成数据恢复前就重启,进而直接覆盖掉从库上的数据,导致所有的数据丢失。
redis 127.0.0.1:6379> SLAVEOF NO ONE
OK
确认一下已经没有了master相关的配置信息:
redis 127.0.0.1:6379> INFO
redis_version:2.4.17 redis_git_sha1:00000000 redis_git_dirty:0 arch_bits:64 multiplexing_api:epoll gcc_version:4.4.5 process_id:13003 run_id:9b8b398fc63a26d160bf58df90cf437acce1d364 uptime_in_seconds:1961 uptime_in_days:0 lru_clock:654215 used_cpu_sys:29.98 used_cpu_user:1.22 used_cpu_sys_children:1.76 used_cpu_user_children:1.42 connected_clients:1 connected_slaves:0 client_longest_output_list:0 client_biggest_input_buf:0 blocked_clients:0 used_memory:33047696 used_memory_human:31.52M used_memory_rss:34779136 used_memory_peak:33064400 used_memory_peak_human:31.53M mem_fragmentation_ratio:1.05 mem_allocator:jemalloc-3.0.0 loading:0 aof_enabled:1 changes_since_last_save:0 bgsave_in_progress:0 last_save_time:1348719252 bgrewriteaof_in_progress:0 total_connections_received:4 total_commands_processed:250311 expired_keys:0 evicted_keys:0 keyspace_hits:0 keyspace_misses:0 pubsub_channels:0 pubsub_patterns:0 latest_fork_usec:1119 vm_enabled:0 role:master aof_current_size:17908619 aof_base_size:16787337 aof_pending_rewrite:0 aof_buffer_length:0 aof_pending_bio_fsync:0 db1:keys=250000,expires=0
在Slave上复制数据文件:
dongguo@redis-slave:/opt/redis/data/6379$ tar cvf /home/dongguo/data.tar *
appendonly.aof
dump.rdb
将data.tar上传到Master上,尝试恢复数据:
可以看到Master目录下有一个初始化Slave的数据文件,很小,将其删除。
dongguo@redis:/opt/redis/data/6379$ ls -l
total 4
-rw-r--r-- 1 root root 10 Sep 27 00:40 dump.rdb
dongguo@redis:/opt/redis/data/6379$ sudo rm -f dump.rdb
然后解压缩数据文件:
dongguo@redis:/opt/redis/data/6379$ sudo tar xf /home/dongguo/data.tar
dongguo@redis:/opt/redis/data/6379$ ls -lh
total 29M
-rw-r--r-- 1 root root 18M Sep 27 01:22 appendonly.aof
-rw-r--r-- 1 root root 12M Sep 27 01:22 dump.rdb
启动Master上的Redis;
dongguo@redis:/opt/redis/data/6379$ sudo /etc/init.d/redis start
Starting Redis server...
查看数据是否恢复:
redis 127.0.0.1:6379> INFO
redis_version:2.4.17 redis_git_sha1:00000000 redis_git_dirty:0 arch_bits:64 multiplexing_api:epoll gcc_version:4.4.5 process_id:16959 run_id:6e5ba6c053583414e75353b283597ea404494926 uptime_in_seconds:22 uptime_in_days:0 lru_clock:650292 used_cpu_sys:0.18 used_cpu_user:0.20 used_cpu_sys_children:0.00 used_cpu_user_children:0.00 connected_clients:1 connected_slaves:0 client_longest_output_list:0 client_biggest_input_buf:0 blocked_clients:0 used_memory:33047216 used_memory_human:31.52M used_memory_rss:34623488 used_memory_peak:33047192 used_memory_peak_human:31.52M mem_fragmentation_ratio:1.05 mem_allocator:jemalloc-3.0.0 loading:0 aof_enabled:0 changes_since_last_save:0 bgsave_in_progress:0 last_save_time:1348680180 bgrewriteaof_in_progress:0 total_connections_received:1 total_commands_processed:1 expired_keys:0 evicted_keys:0 keyspace_hits:0 keyspace_misses:0 pubsub_channels:0 pubsub_patterns:0 latest_fork_usec:0 vm_enabled:0 role:master db1:keys=250000,expires=0
可以看到25万条数据已经完整恢复到了Master上。
此时,可以放心的恢复Slave的同步设置了。
redis 127.0.0.1:6379> SLAVEOF 10.6.1.143 6379
OK
查看同步状态:
redis 127.0.0.1:6379> INFO
redis_version:2.4.17 redis_git_sha1:00000000 redis_git_dirty:0 arch_bits:64 multiplexing_api:epoll gcc_version:4.4.5 process_id:13003 run_id:9b8b398fc63a26d160bf58df90cf437acce1d364 uptime_in_seconds:2652 uptime_in_days:0 lru_clock:654284 used_cpu_sys:30.01 used_cpu_user:2.12 used_cpu_sys_children:1.76 used_cpu_user_children:1.42 connected_clients:2 connected_slaves:0 client_longest_output_list:0 client_biggest_input_buf:0 blocked_clients:0 used_memory:33056288 used_memory_human:31.52M used_memory_rss:34766848 used_memory_peak:33064400 used_memory_peak_human:31.53M mem_fragmentation_ratio:1.05 mem_allocator:jemalloc-3.0.0 loading:0 aof_enabled:1 changes_since_last_save:0 bgsave_in_progress:0 last_save_time:1348719252 bgrewriteaof_in_progress:1 total_connections_received:6 total_commands_processed:250313 expired_keys:0 evicted_keys:0 keyspace_hits:0 keyspace_misses:0 pubsub_channels:0 pubsub_patterns:0 latest_fork_usec:12217 vm_enabled:0 role:slave aof_current_size:17908619 aof_base_size:16787337 aof_pending_rewrite:0 aof_buffer_length:0 aof_pending_bio_fsync:0 master_host:10.6.1.143 master_port:6379 master_link_status:up master_last_io_seconds_ago:0 master_sync_in_progress:0 slave_priority:100 db1:keys=250000,expires=0
master_link_status显示为up,同步状态正常。
在此次恢复的过程中,我们同时复制了AOF与RDB文件,那么到底是哪一个文件完成了数据的恢复呢?
实际上,当Redis服务器挂掉时,重启时将按照以下优先级恢复数据到内存:
1. 如果只配置AOF,重启时加载AOF文件恢复数据;
2. 如果同时 配置了RDB和AOF,启动是只加载AOF文件恢复数据;
3. 如果只配置RDB,启动是将加载dump文件恢复数据。
也就是说,AOF的优先级要高于RDB,这也很好理解,因为AOF本身对数据的完整性保障要高于RDB。
在此次的案例中,我们通过在Slave上启用了AOF与RDB来保障了数据,并恢复了Master。
但在我们目前的线上环境中,由于数据都设置有过期时间,采用AOF的方式会不太实用,过于频繁的写操作会使AOF文件增长到异常的庞大,大大超过了我们实际的数据量,这也会导致在进行数据恢复时耗用大量的时间。
因此,可以在Slave上仅开启Snapshot来进行本地化,同时可以考虑将save中的频率调高一些或者调用一个计划任务来进行定期bgsave的快照存储,来尽可能的保障本地化数据的完整性。
在这样的架构下,如果仅仅是Master挂掉,Slave完整,数据恢复可达到100%。
如果Master与Slave同时挂掉的话,数据的恢复也可以达到一个可接受的程度。
转自 http://blog.csdn.net/gzh0222/article/details/8482525
相关推荐
redis数据淘汰机制.avi
测试代码会创建各种场景,模拟不同的操作,比如设置键值、读取键值、处理列表、集合等数据结构,以及检查错误处理机制。测试是确保软件质量的关键环节,对于C++与Redis的集成尤其重要,因为网络通信和数据序列化/反...
Redis是Remote Dictionary Server的缩写,它使用字典结构存储数据,并允许其他应用通过TCP协议读写字典中的内容。同大多数脚本语言中的字典一样,Redis字典中的键值除了可以是字符串,还可以是其他数据类型。Redis ...
2. **读取Redis数据**: - 要读取键值对,使用`Get`或`ExecuteCommand`方法(具体取决于所选客户端库)发送`GET`命令,传入键名。 - 回应通常会是字符串形式,可能需要进一步转换为所需的类型,如整数、浮点数或...
Redis是一款高性能的键值存储系统,它以其丰富的数据结构、高效的数据操作以及强大的持久化机制在现代互联网架构中扮演着重要角色。本篇文章主要探讨Redis的核心数据结构和核心原理,以及如何利用IO多路复用技术处理...
Redis的数据持久化机制包括RDB(定期快照)和AOF(Append Only File,追加日志文件),以确保即使在系统崩溃或硬件故障后也能恢复数据。此外,Redis还支持主从复制,可以创建多个副本以提高可用性和数据安全性。 ...
Redis Cluster 通过引入一系列的技术创新,如 Master-slave 架构、异步复制、客户端智能路由以及 hashtags 机制等,实现了高性能、可扩展且具有一定数据安全性的分布式存储解决方案。虽然在某些情况下可能存在数据...
Java面试题79:redis数据淘汰机制.mp4
Redis是一款高性能的...总之,Java开发中的Redis数据导入与导出涉及多方面的技术,包括选择合适的客户端、优化批量操作、实施备份策略以及处理异常。在实际应用中,需要根据业务需求和系统性能进行合理的设计和实现。
Redis是一种高性能的键值存储系统,广泛用于数据缓存、消息队列以及实时数据处理等领域。Qt则是一个跨平台的应用程序开发框架,尤其适合创建图形用户界面。 首先,我们要理解Redis的订阅发布(Pub/Sub)模式。在这...
Redis数据缓存** Redis是一个高性能的键值对存储系统,常用于缓存。它支持多种数据结构如字符串、哈希、列表、集合和有序集合,这使得Redis能适应各种缓存场景。通过将热点数据存储在内存中,Redis能够提供极快的...
7. Redis 的 expiration 机制:Redis 提供了 expiration 机制,可以实现自动删除过期的数据。 8. Redis 的 Script 机制:Redis 提供了 Script 机制,可以实现自定义的命令。 9. Redis 的 Cluster 机制:Redis 提供...
使用场景及目标:①掌握Redis持久化机制的实现细节,提升Redis数据管理能力;②根据业务需求选择合适的持久化策略,确保数据不丢失;③了解如何配置和优化持久化性能。 其他说明:文章详细介绍了RDB和AOF两种持久化...
总结来说,Redis是一个强大且灵活的内存数据存储系统,其高效的内部实现机制、丰富的数据结构和多种持久化策略使其成为现代Web应用中不可或缺的部分。通过理解其工作原理和最佳实践,我们可以充分利用Redis的优势,...
- **虚拟内存的实现**:Redis的虚拟内存实现采用了一种类似于操作系统的机制,即通过将冷数据交换到磁盘上来释放内存空间。然而,与操作系统不同的是,Redis选择了自行实现这一机制,而不是利用操作系统的虚拟内存...
标题 "memcached数据完整迁移到redis" 描述的是一个数据迁移的过程,从使用 memcached 存储的数据转换到使用 redis 存储。这个过程在 IT 领域中是常见的,因为不同的缓存系统有不同的特性和优势。让我们深入探讨这个...
RDB是在特定时间点生成的快照文件,而AOF记录了所有写操作的日志,提供了一种持久化机制来保证数据安全。 - 接着,Redis会监听配置的端口,等待客户端连接。 - 最后,服务启动成功,可以接受命令并执行。 2. **...
2. **持久化**:尽管 Redis 是一个内存数据库,但它提供了持久化机制,可以将内存中的数据保存到磁盘,防止数据丢失。 3. **支持事务**:Redis 支持简单的事务功能,可以保证操作的原子性。 4. **丰富的数据类型**:...
在IT行业中,Redis是一个非常流行的开源键值存储系统,它以其高效、高性能和丰富的数据结构而受到广大开发者的青睐。本教程将详细讲解如何在C#环境中利用Redis的发布订阅(Publish-Subscribe,简称Pub/Sub)机制实现...
4. 错误处理:在进行Redis操作时,可能会遇到网络问题或Redis服务器错误,类模块应有适当的错误处理机制,如捕获异常并返回错误信息。 压缩包中的其他文件包括: 1. `redis测试.exe`:这是VB6编译后的可执行文件,...