Redis持久化实践及灾难恢复模拟 [转]

unijun

　　参考资料：
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参数来定义快照的周期。
下面是默认的快照设置：

1	save 900 1    #当有一条Keys数据被改变时，900秒刷新到Disk一次

2	save 300 10   #当有10条Keys数据被改变时，300秒刷新到Disk一次

3	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

1	appendonly yes       #启用AOF持久化方式

2	appendfilename appendonly.aof #AOF文件的名称，默认为appendonly.aof

3	# appendfsync always #每次收到写命令就立即强制写入磁盘，是最有保证的完全的持久化，但速度也是最慢的，一般不推荐使用。

4	appendfsync everysec #每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，是受推荐的方式。

5	# 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-rewrite yes   #在日志重写时，不进行命令追加操作，而只是将其放在缓冲区里，避免与命令的追加造成DISK IO上的冲突。

2	auto-aof-rewrite-percentage 100 #当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。

3	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 1 #禁用Snapshot

2	#save 300 10

3	#save 60 10000

4

5	appendonly no #禁用AOF

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

01	save 900 1 #启用Snapshot

02	save 300 10

03	save 60 10000

04

05	appendonly yes #启用AOF

06	appendfilename appendonly.aof #AOF文件的名称

07	# appendfsync always

08	appendfsync everysec #每秒钟强制写入磁盘一次

09	# appendfsync no

10

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

01	#!/bin/bash

02

03	REDISCLI="redis-cli -a slavepass -n 1 SET"

04

ID=1

05

06	while(($ID info [table]
01	redis_version:2.4.17

02	redis_git_sha1:00000000

03	redis_git_dirty:0

04	arch_bits:64

05	multiplexing_api:epoll

06	gcc_version:4.4.5

07	process_id:27623

08	run_id:e00757f7b2d6885fa9811540df9dfed39430b642

09	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: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

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

44	role:master

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

01	redis_version:2.4.17

02	redis_git_sha1:00000000

03	redis_git_dirty:0

04	arch_bits:64

05	multiplexing_api:epoll

06	gcc_version:4.4.5

07	process_id:13003

08	run_id:9b8b398fc63a26d160bf58df90cf437acce1d364

09	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: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

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

44	role:slave

45	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

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

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 ONE
OK
　　确认一下已经没有了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

05	multiplexing_api:epoll

06	gcc_version:4.4.5

07	process_id:13003

08	run_id:9b8b398fc63a26d160bf58df90cf437acce1d364

09	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: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

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

44	role:master

45	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.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

01	redis_version:2.4.17

02	redis_git_sha1:00000000

03	redis_git_dirty:0

04	arch_bits:64

05	multiplexing_api:epoll

06	gcc_version:4.4.5

07	process_id:16959

08	run_id:6e5ba6c053583414e75353b283597ea404494926

09	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: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

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

44	role:master

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

01	redis_version:2.4.17

02	redis_git_sha1:00000000

03	redis_git_dirty:0

04	arch_bits:64

05	multiplexing_api:epoll

06	gcc_version:4.4.5

07	process_id:13003

08	run_id:9b8b398fc63a26d160bf58df90cf437acce1d364

09	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: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

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

44	role:slave

45	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

52	master_link_status:up

53	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同时挂掉的话，数据的恢复也可以达到一个可接受的程度。