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

12345 # 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

1 no-appendfsync-on-2 auto-aof-rewrite-percentage 1003 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

1 #save 900 12 #save 300 10 3 #save 60 10000 4 5 appendonly no #禁用AOF

接着,修改Slave上的如下配置:$ sudo vim /opt/redis/etc/redis_6379.conf

01 save 900 102 save 300 10 03 save 60 10000 04 050607080910 11 no-appendfsync-on-12 auto-aof-rewrite-percentage 10013 auto-aof-rewrite-min-size 64mb #启动新的日志重写过程的最小值

分别启动Master与Slave$ /etc/init.d/redis start

启动完成后在Master中确认未启动Snapshot参数redis 127.0.0.1:6379> CONFIG GET save1) "save"2) ""

然后通过以下脚本在Master中生成25万条数据:dongguo@redis:/opt/redis/data/6379$ cat redis-cli-generate.temp.sh

01 #!/bin/02 03 REDISCLI="redis-cli -a slavepass -n 1 SET" 04 ID=1 05 06 (($ID<5000107 08 INSTANCE_NAME="i-2-$ID-VM" 09 UUID=`cat /proc/sys/kernel/random/10 PRIVATE_IP_ADDRESS=10.`echo "$RANDOM % 255 + 1" | bc`.`echo "$RANDOM % 255 + 1" |bc`.`echo "$RANDOM % 255 + 1" |11 CREATED=`date "+%Y-%m-%d %H:%M:%S"12 13 $REDISCLI vm_instance:$ID:instance_name "$INSTANCE_NAME" 14 $REDISCLI vm_instance:$ID:uuid "$UUID" 15 $REDISCLI vm_instance:$ID:private_ip_address "$PRIVATE_IP_ADDRESS" 16 $REDISCLI vm_instance:$ID:created "$CREATED" 17 18 $REDISCLI vm_instance:$INSTANCE_NAME:id "$ID" 19 20 ID=$(($ID+121 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 -lhtotal 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 -lhtotal 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

01 redis_version:2.4.17 02 redis_git_sha1:00000000 03 redis_git_dirty:0 04 arch_bits:64 0506 gcc_version:4.4.5 07 process_id:27623 0809 uptime_in_seconds:1541 10 uptime_in_days:0 11 lru_clock:650187 12 used_cpu_sys:69.28 13 used_cpu_user:7.67 14 used_cpu_sys_children:0.00 15 used_cpu_user_children:0.00 16 connected_clients:1 17 connected_slaves:1 18 client_longest_output_list:0 19 client_biggest_input_buf:0 20 blocked_clients:0 21 used_memory:33055824 22 used_memory_human:3123 used_memory_rss:34717696 24 used_memory_peak:33055800 25 used_memory_peak_human:3126 mem_fragmentation_ratio:1.05 27 mem_allocator:jemalloc-3.0.0 28 loading:0 29 aof_enabled:0 30 changes_since_last_save:250000 31 bgsave_in_progress:0 32 last_save_time:1348677645 33 bgrewriteaof_in_progress:0 34 total_connections_received:250007 35 total_commands_processed:750019 36 expired_keys:0 37 evicted_keys:0 38 keyspace_hits:0 39 keyspace_misses:0 40 pubsub_channels:0 41 pubsub_patterns:0 42 latest_fork_usec:246 43 vm_enabled:0 4445 slave0:10.6.1.144,637946 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

01 redis_version:2.4.17 02 redis_git_sha1:00000000 03 redis_git_dirty:0 04 arch_bits:64 0506 gcc_version:4.4.5 07 process_id:13003 0809 uptime_in_seconds:1627 10 uptime_in_days:0 11 lru_clock:654181 12 used_cpu_sys:29.69 13 used_cpu_user:1.21 14 used_cpu_sys_children:1.70 15 used_cpu_user_children:1.23 16 connected_clients:1 17 connected_slaves:0 18 client_longest_output_list:0 19 client_biggest_input_buf:0 20 blocked_clients:0 21 used_memory:33047696 22 used_memory_human:3123 used_memory_rss:34775040 24 used_memory_peak:33064400 25 used_memory_peak_human:3126 mem_fragmentation_ratio:1.05 27 mem_allocator:jemalloc-3.0.0 28 loading:0 29 aof_enabled:1 30 changes_since_last_save:3308 31 bgsave_in_progress:0 32 last_save_time:1348718951 33 bgrewriteaof_in_progress:0 34 total_connections_received:4 35 total_commands_processed:250308 36 expired_keys:0 37 evicted_keys:0 38 keyspace_hits:0 39 keyspace_misses:0 40 pubsub_channels:0 41 pubsub_patterns:0 42 latest_fork_usec:694 43 vm_enabled:0 4445 aof_current_size:17908619 46 aof_base_size:16787337 47 aof_pending_rewrite:0 48 aof_buffer_length:0 49 aof_pending_bio_fsync:0 50 master_host:10.6.1.143 51 master_port:6379 5253 master_last_io_seconds_ago:-1 54 master_sync_in_progress:0 55 master_link_down_since_seconds:25 56 slave_priority:100 57 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 ONEOK

确认一下已经没有了master相关的配置信息:redis 127.0.0.1:6379> INFO

01 redis_version:2.4.17 02 redis_git_sha1:00000000 03 redis_git_dirty:0 04 arch_bits:64 0506 gcc_version:4.4.5 07 process_id:13003 0809 uptime_in_seconds:1961 10 uptime_in_days:0 11 lru_clock:654215 12 used_cpu_sys:29.98 13 used_cpu_user:1.22 14 used_cpu_sys_children:1.76 15 used_cpu_user_children:1.42 16 connected_clients:1 17 connected_slaves:0 18 client_longest_output_list:0 19 client_biggest_input_buf:0 20 blocked_clients:0 21 used_memory:33047696 22 used_memory_human:3123 used_memory_rss:34779136 24 used_memory_peak:33064400 25 used_memory_peak_human:3126 mem_fragmentation_ratio:1.05 27 mem_allocator:jemalloc-3.0.0 28 loading:0 29 aof_enabled:1 30 changes_since_last_save:0 31 bgsave_in_progress:0 32 last_save_time:1348719252 33 bgrewriteaof_in_progress:0 34 total_connections_received:4 35 total_commands_processed:250311 36 expired_keys:0 37 evicted_keys:0 38 keyspace_hits:0 39 keyspace_misses:0 40 pubsub_channels:0 41 pubsub_patterns:0 42 latest_fork_usec:1119 43 vm_enabled:0 4445 aof_current_size:17908619 46 aof_base_size:16787337 47 aof_pending_rewrite:0 48 aof_buffer_length:0 49 aof_pending_bio_fsync:0 50 db1:keys=250000,expires=0

在Slave上复制数据文件:dongguo@redis-slave:/opt/redis/data/6379$ tar cvf /home/dongguo/data.tar *appendonly.aofdump.rdb

将data.tar上传到Master上,尝试恢复数据:可以看到Master目录下有一个初始化Slave的数据文件,很小,将其删除。dongguo@redis:/opt/redis/data/6379$ ls -ltotal 4-rw-r--r-- 1 root root 10 Sep 27 00:40 dump.rdbdongguo@redis:/opt/redis/data/6379$ sudo rm -f dump.rdb

然后解压缩数据文件:dongguo@redis:/opt/redis/data/6379$ sudo tar xf /home/dongguo/data.tardongguo@redis:/opt/redis/data/6379$ ls -lhtotal 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 startStarting Redis server...

查看数据是否恢复:redis 127.0.0.1:6379> INFO

01 redis_version:2.4.17 02 redis_git_sha1:00000000 03 redis_git_dirty:0 04 arch_bits:64 0506 gcc_version:4.4.5 07 process_id:16959 0809 uptime_in_seconds:22 10 uptime_in_days:0 11 lru_clock:650292 12 used_cpu_sys:0.18 13 used_cpu_user:0.20 14 used_cpu_sys_children:0.00 15 used_cpu_user_children:0.00 16 connected_clients:1 17 connected_slaves:0 18 client_longest_output_list:0 19 client_biggest_input_buf:0 20 blocked_clients:0 21 used_memory:33047216 22 used_memory_human:3123 used_memory_rss:34623488 24 used_memory_peak:33047192 25 used_memory_peak_human:3126 mem_fragmentation_ratio:1.05 27 mem_allocator:jemalloc-3.0.0 28 loading:0 29 aof_enabled:0 30 changes_since_last_save:0 31 bgsave_in_progress:0 32 last_save_time:1348680180 33 bgrewriteaof_in_progress:0 34 total_connections_received:1 35 total_commands_processed:1 36 expired_keys:0 37 evicted_keys:0 38 keyspace_hits:0 39 keyspace_misses:0 40 pubsub_channels:0 41 pubsub_patterns:0 42 latest_fork_usec:0 43 vm_enabled:0 4445 db1:keys=250000,expires=0

可以看到25万条数据已经完整恢复到了Master上。

此时,可以放心的恢复Slave的同步设置了。redis 127.0.0.1:6379> SLAVEOF 10.6.1.143 6379OK

查看同步状态:redis 127.0.0.1:6379> INFO

01 redis_version:2.4.17 02 redis_git_sha1:00000000 03 redis_git_dirty:0 04 arch_bits:64 0506 gcc_version:4.4.5 07 process_id:13003 0809 uptime_in_seconds:2652 10 uptime_in_days:0 11 lru_clock:654284 12 used_cpu_sys:30.01 13 used_cpu_user:2.12 14 used_cpu_sys_children:1.76 15 used_cpu_user_children:1.42 16 connected_clients:2 17 connected_slaves:0 18 client_longest_output_list:0 19 client_biggest_input_buf:0 20 blocked_clients:0 21 used_memory:33056288 22 used_memory_human:3123 used_memory_rss:34766848 24 used_memory_peak:33064400 25 used_memory_peak_human:3126 mem_fragmentation_ratio:1.05 27 mem_allocator:jemalloc-3.0.0 28 loading:0 29 aof_enabled:1 30 changes_since_last_save:0 31 bgsave_in_progress:0 32 last_save_time:1348719252 33 bgrewriteaof_in_progress:1 34 total_connections_received:6 35 total_commands_processed:250313 36 expired_keys:0 37 evicted_keys:0 38 keyspace_hits:0 39 keyspace_misses:0 40 pubsub_channels:0 41 pubsub_patterns:0 42 latest_fork_usec:12217 43 vm_enabled:0 4445 aof_current_size:17908619 46 aof_base_size:16787337 47 aof_pending_rewrite:0 48 aof_buffer_length:0 49 aof_pending_bio_fsync:0 50 master_host:10.6.1.143 51 master_port:6379 5253 master_last_io_seconds_ago:0 54 master_sync_in_progress:0 55 slave_priority:100 56 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同时挂掉的话,数据的恢复也可以达到一个可接受的程度。

相关文章

文章浏览阅读1.3k次。在 Redis 中,键(Keys)是非常重要的概...
文章浏览阅读3.3k次,点赞44次,收藏88次。本篇是对单节点的...
文章浏览阅读8.4k次,点赞8次,收藏18次。Spring Boot 整合R...
文章浏览阅读978次,点赞25次,收藏21次。在Centos上安装Red...
文章浏览阅读1.2k次,点赞21次,收藏22次。Docker-Compose部...
文章浏览阅读2.2k次,点赞59次,收藏38次。合理的JedisPool资...