参考资料：
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参数来定义快照的周期。
下面是默认的快照设置：
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
2 |
appendfilename appendonly.aof
|
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-rewrite yes
|
2 |
auto-aof-rewrite-percentage 100
|
3 |
auto-aof-rewrite-min-size 64mb
|
到底选择什么呢？下面是来自官方的建议：
通常，如果你要想提供很高的数据保障性，那么建议你同时使用两种持久化方式。
如果你可以接受灾难带来的几分钟的数据丢失，那么你可以仅使用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
接着，修改Slave上的如下配置：
$ sudo vim /opt/redis/etc/redis_6379.conf
06 |
appendfilename appendonly.aof
|
11 |
no-appendfsync-on-rewrite yes
|
12 |
auto-aof-rewrite-percentage 100
|
13 |
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
03 |
REDISCLI="redis-cli -a slavepass -n 1 SET"
|
08 |
INSTANCE_NAME="i-2-$ID-VM"
|
09 |
UUID=`cat /proc/sys/kernel/random/uuid`
|
10 |
PRIVATE_IP_ADDRESS=10.`echo "$RANDOM % 255 + 1" | bc`.`echo "$RANDOM % 255 + 1" |bc`.`echo "$RANDOM % 255 + 1" | bc`\
|
11 |
CREATED=`date "+%Y-%m-%d %H:%M:%S"`
|
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"
|
18 |
$REDISCLI vm_instance:$INSTANCE_NAME:id "$ID"
|
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
02 |
redis_git_sha1:00000000 |
05 |
multiplexing_api:epoll |
08 |
run_id:e00757f7b2d6885fa9811540df9dfed39430b642 |
09 |
uptime_in_seconds:1541 |
14 |
used_cpu_sys_children:0.00 |
15 |
used_cpu_user_children:0.00 |
18 |
client_longest_output_list:0 |
19 |
client_biggest_input_buf:0 |
22 |
used_memory_human:31.52M |
23 |
used_memory_rss:34717696 |
24 |
used_memory_peak:33055800 |
25 |
used_memory_peak_human:31.52M |
26 |
mem_fragmentation_ratio:1.05 |
27 |
mem_allocator:jemalloc-3.0.0 |
30 |
changes_since_last_save:250000 |
32 |
last_save_time:1348677645 |
33 |
bgrewriteaof_in_progress:0 |
34 |
total_connections_received:250007 |
35 |
total_commands_processed:750019 |
45 |
slave0:10.6.1.144,6379,online |
46 |
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
02 |
redis_git_sha1:00000000 |
05 |
multiplexing_api:epoll |
08 |
run_id:9b8b398fc63a26d160bf58df90cf437acce1d364 |
09 |
uptime_in_seconds:1627 |
14 |
used_cpu_sys_children:1.70 |
15 |
used_cpu_user_children:1.23 |
18 |
client_longest_output_list:0 |
19 |
client_biggest_input_buf:0 |
22 |
used_memory_human:31.52M |
23 |
used_memory_rss:34775040 |
24 |
used_memory_peak:33064400 |
25 |
used_memory_peak_human:31.53M |
26 |
mem_fragmentation_ratio:1.05 |
27 |
mem_allocator:jemalloc-3.0.0 |
30 |
changes_since_last_save:3308 |
32 |
last_save_time:1348718951 |
33 |
bgrewriteaof_in_progress:0 |
34 |
total_connections_received:4 |
35 |
total_commands_processed:250308 |
45 |
aof_current_size:17908619 |
46 |
aof_base_size:16787337 |
49 |
aof_pending_bio_fsync:0 |
50 |
master_host:10.6.1.143 |
52 |
master_link_status:down |
53 |
master_last_io_seconds_ago:-1 |
54 |
master_sync_in_progress:0 |
55 |
master_link_down_since_seconds:25 |
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 ONE
OK
确认一下已经没有了master相关的配置信息：
redis 127.0.0.1:6379> INFO
02 |
redis_git_sha1:00000000 |
05 |
multiplexing_api:epoll |
08 |
run_id:9b8b398fc63a26d160bf58df90cf437acce1d364 |
09 |
uptime_in_seconds:1961 |
14 |
used_cpu_sys_children:1.76 |
15 |
used_cpu_user_children:1.42 |
18 |
client_longest_output_list:0 |
19 |
client_biggest_input_buf:0 |
22 |
used_memory_human:31.52M |
23 |
used_memory_rss:34779136 |
24 |
used_memory_peak:33064400 |
25 |
used_memory_peak_human:31.53M |
26 |
mem_fragmentation_ratio:1.05 |
27 |
mem_allocator:jemalloc-3.0.0 |
30 |
changes_since_last_save:0 |
32 |
last_save_time:1348719252 |
33 |
bgrewriteaof_in_progress:0 |
34 |
total_connections_received:4 |
35 |
total_commands_processed:250311 |
45 |
aof_current_size:17908619 |
46 |
aof_base_size:16787337 |
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.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
02 |
redis_git_sha1:00000000 |
05 |
multiplexing_api:epoll |
08 |
run_id:6e5ba6c053583414e75353b283597ea404494926 |
14 |
used_cpu_sys_children:0.00 |
15 |
used_cpu_user_children:0.00 |
18 |
client_longest_output_list:0 |
19 |
client_biggest_input_buf:0 |
22 |
used_memory_human:31.52M |
23 |
used_memory_rss:34623488 |
24 |
used_memory_peak:33047192 |
25 |
used_memory_peak_human:31.52M |
26 |
mem_fragmentation_ratio:1.05 |
27 |
mem_allocator:jemalloc-3.0.0 |
30 |
changes_since_last_save:0 |
32 |
last_save_time:1348680180 |
33 |
bgrewriteaof_in_progress:0 |
34 |
total_connections_received:1 |
35 |
total_commands_processed:1 |
45 |
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
02 |
redis_git_sha1:00000000 |
05 |
multiplexing_api:epoll |
08 |
run_id:9b8b398fc63a26d160bf58df90cf437acce1d364 |
09 |
uptime_in_seconds:2652 |
14 |
used_cpu_sys_children:1.76 |
15 |
used_cpu_user_children:1.42 |
18 |
client_longest_output_list:0 |
19 |
client_biggest_input_buf:0 |
22 |
used_memory_human:31.52M |
23 |
used_memory_rss:34766848 |
24 |
used_memory_peak:33064400 |
25 |
used_memory_peak_human:31.53M |
26 |
mem_fragmentation_ratio:1.05 |
27 |
mem_allocator:jemalloc-3.0.0 |
30 |
changes_since_last_save:0 |
32 |
last_save_time:1348719252 |
33 |
bgrewriteaof_in_progress:1 |
34 |
total_connections_received:6 |
35 |
total_commands_processed:250313 |
42 |
latest_fork_usec:12217 |
45 |
aof_current_size:17908619 |
46 |
aof_base_size:16787337 |
49 |
aof_pending_bio_fsync:0 |
50 |
master_host:10.6.1.143 |
53 |
master_last_io_seconds_ago:0 |
54 |
master_sync_in_progress:0 |
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同时挂掉的话，数据的恢复也可以达到一个可接受的程度。
相关推荐
持久化是指将内存中的数据保存到磁盘上，以便在Redis服务器重启或者系统崩溃之后，数据依然能够得以保存和恢复。Redis提供了两种持久化方案：RDB（Redis Database）和AOF（Append Only File）。 RDB持久化方案是指...
### Redis持久化方式详解 Redis 是一款高性能的键值存储系统，因其卓越的读写速度、丰富的数据结构以及灵活的应用场景而备受青睐。为了保证数据的安全性和持久性，Redis 提供了两种主要的持久化机制：RDB 快照...
Redis是一款高性能的键值对内存数据库，常用于缓存、消息队列以及数据持久化等场景。本资料包主要探讨Redis的三个核心概念：持久化、主从复制和哨兵架构，这些都是确保Redis高可用性和数据安全的重要机制。 首先，...
持久化是Redis的一个重要特性，确保即使在服务器崩溃或系统断电后，数据也能得以恢复。本文将深入解析Redis的持久化机制，主要包括RDB快照和AOF日志。 首先，理解数据持久化的概念至关重要。简单来说，持久化就是将...
02-Redis持久化、主从与哨兵架构详解02-Redis持久化、主从与哨兵架构详解02-Redis持久化、主从与哨兵架构详解02-Redis持久化、主从与哨兵架构详解02-Redis持久化、主从与哨兵架构详解02-Redis持久化、主从与哨兵架构...
RDB和AOF两种持久化方式各有优缺点，RDB方式的优点是速度快，恢复性能好，适合灾难恢复；而AOF方式则具备更好的数据安全性和可靠性，但是恢复速度和数据一致性方面相对较弱。在实际应用中，根据不同的业务场景和需求...
Redis持久化是指将Redis中的数据保存到磁盘中，以便在Redis服务器重启或崩溃后可以恢复数据。Redis提供了两种持久化方式：RDB快照和AOFAppend-Only File。 RDB快照 RDB快照是Redis默认的持久化方式，它将内存...
在 Windows 上测试 Redis 的持久化功能，主要是确保数据在系统重启或异常情况后能够被正确地保存和恢复。以下将详细介绍如何在 Windows 环境下设置 Redis 以及其持久化机制。 首先，为了运行 Redis，我们需要在 ...
### Redis 持久化与集群部署探讨 #### 一、Redis 持久化机制 Redis 提供了两种持久化方式：RDB（Redis Database Backup）和 AOF（Append Only File）。这两种机制各有特点，适用于不同的场景。 ##### 1. RDB...
Redis持久化机制包括RDB快照和AOF（Append Only File）两种方式，它们有不同的特点和使用场景，下面将详细分析这两种机制。 首先，RDB是通过创建数据集的快照来进行持久化的，在默认情况下，Redis会在内存中存储...
redis，持久化，主要说明了redis中的两种持久化方式，是可以值得参考的
Redis 持久化是确保数据安全的重要机制，它提供了两种主要的方法：RDB（Redis Database）和 AOF（Append Only File）。RDB 是一种快照式的持久化方式，而 AOF 则记录每次写操作的日志。 RDB 持久化在特定条件下将...
作为一款内存数据库，Redis可以实现极快的读写速度，但同时也提供了可持久化功能，以确保数据在系统崩溃或重启后不会丢失。 Redis的持久化机制主要有两种方式：RDB（Redis Database Backup）和AOF（Append Only ...
【Redis持久化机制详解】 ...总之，Redis的持久化机制是为了确保数据的可靠性，即使在系统故障后也能恢复数据，从而提供了关键的业务连续性。通过对RDB和AOF的深入了解和合理配置，可以有效地管理和保护Redis中的数据。
Redis 持久化是 Redis 为了解决内存数据库在服务器宕机或重启时数据丢失问题而提供的功能。本文主要介绍了 Redis 的两种持久化机制：RDB（Redis Database Backup file）和 AOF（Append Only File），重点讲解了 RDB ...
当 Redis 重启时，可以读取最后一次持久化的 RDB 文件来恢复数据。 ##### 1. 配置文件介绍 为了在 Windows 环境下测试 Redis 的持久化功能，首先需要在 Redis 根目录下创建一个名为 `redis.conf` 的配置文件。此...
Macbook Pro进行Docker安装Redis并配置Redis持久化