redis学习系列（九）--redis-AOF和RDB实践

实践AOF和RDB的话，需要注明，本身并不是自己得来的知识，而是从网上的博客总结得来的，当然能自己动手吸收一下也是好的额。。。。。。。。。

实践RDB：

RDB其实之前已经初步试验过，这一次主要吸取别人博客的一些观点，充实自己

RDB配置：

下面两个是默认配置，没去管，先这样吧，一个是压缩。一个是检查校验的。

save 900 1
save 300 10
save 30 1
rdbcompression yes
rdbchecksum yes
appendonly no

1.当前的key是加载进来的，前天保存在RDB文件里的key

127.0.0.1:6379> keys *
1) "abc"
2) "num"

2.可以看下当前用量是40

[localhost bin]$ ls -lh /usr/local/redis/bin/dump.rdb
-rw-r--r--. 1 root root 40 10月 24 15:32 /usr/local/redis/bin/dump.rdb

3.设置一个新key

127.0.0.1:6379> set key "this is a key"
OK
127.0.0.1:6379> bgsave
Background saving started
127.0.0.1:6379> 

4.因为我配置的是30s，因此30s之后自动保存了，变成50

[localhost bin]$ ls -lh /usr/local/redis/bin/dump.rdb
-rw-r--r--. 1 root root 59 10月 25 14:08 /usr/local/redis/bin/dump.rdb

5.这一次以默认配置文件启动，默认配置不会这么快去执行RDB

4728:M 25 Oct 14:31:35.414 * DB loaded from disk: 0.000 seconds
4728:M 25 Oct 14:31:35.414 * The server is now ready to accept connections on port 6379

6.这边可见我在执行退出时，redis已经把当前操作的数据存储到RDB文件中去了

4837:M 25 Oct 14:35:35.469 # User requested shutdown...
4837:M 25 Oct 14:35:35.469 * Saving the final RDB snapshot before exiting.
4837:M 25 Oct 14:35:35.470 * DB saved on disk
4837:M 25 Oct 14:35:35.470 # Redis is now ready to exit, bye bye...

7.再次打开redis后台，这个之前就看见了，因为每次打开时会去加载RDB文件的，可见正常的关闭之前redis是会执行save操作的

127.0.0.1:6379> get k
Could not connect to Redis at 127.0.0.1:6379: Connection refused
not connected> get k
"this is a k"
127.0.0.1:6379> 

8.试验一下异常关闭，比如杀死，重启之后数据丢失......

127.0.0.1:6379> set kk "this is anotheer kk"
OK
# kill -9 4894
rt 6379
已杀死
127.0.0.1:6379> get kk
(nil)
127.0.0.1:6379> 

AOF实践
配置：只是将appendonly打开，其他仍使用默认项，RDB的save配置注释掉

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

1.重启之前查看当前key

127.0.0.1:6379> keys *
1) "k"
2) "abc"
3) "num"
4) "key"
127.0.0.1:6379> 

2.重启成功之后再次查看：已经生产aof文件

-rw-r--r--. 1 root root    0 10月 25 15:25 appendonly.aof
-rw-r--r--. 1 root root   74 10月 25 15:13 dump.rdb

此时查看key，有没有发现key消失不见了。为此，我特意去配置了一下logfile，因为我本机如果使用自己的配置启动时发现在客户端内不能打印日志

127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> 

3.logfile内没有去加载RDB文件，我这边并没有显示出是从aof内加载的。

5988:M 25 Oct 15:25:13.893 # Server started, Redis version 3.0.0
5988:M 25 Oct 15:25:13.893 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
5988:M 25 Oct 15:25:13.893 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.
5988:M 25 Oct 15:25:13.893 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
5988:M 25 Oct 15:25:13.893 * The server is now ready to accept connections on port 6379

使用kill -15 命令去正常关闭：

[root@localhost bin]# ps -ef | grep redis
root      5988     1  0 15:25 ?        00:00:00 ./redis-server *:6379
root      6313  4433  0 15:35 pts/2    00:00:00 grep --color=auto redis
[root@localhost bin]# kill -15 5988

日志如下：正常关闭，但是，但是，注意看下 DB saved on disk

5988:M 25 Oct 15:36:17.490 # User requested shutdown...
5988:M 25 Oct 15:36:17.490 * Calling fsync() on the AOF file.
5988:M 25 Oct 15:36:17.490 * Saving the final RDB snapshot before exiting.
5988:M 25 Oct 15:36:17.508 * DB saved on disk
5988:M 25 Oct 15:36:17.508 * Removing the pid file.
5988:M 25 Oct 15:36:17.508 # Redis is now ready to exit, bye bye...

再一次去尝试启动redis：keys都不存在了。

127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> 

此时的RDB文件看下：空的，空了。

[root@localhost bin]# cat dump.rdb
REDIS0006�ܳC�Z��V[root@localhost bin]# 

贴一段代码，加载的，可以看见redis是优先加载aof文件的。

void loadDataFromDisk(void) {
    long long start = ustime();
    if (server.aof_state == REDIS_AOF_ON) {
        if (loadAppendOnlyFile(server.aof_filename) == REDIS_OK)
            redisLog(REDIS_NOTICE,"DB loaded from append only file: %.3f seconds",(float)(ustime()-start)/1000000);
    } else {
        if (rdbLoad(server.rdb_filename) == REDIS_OK) {
            redisLog(REDIS_NOTICE,"DB loaded from disk: %.3f seconds",
                (float)(ustime()-start)/1000000);
        } else if (errno != ENOENT) {
            redisLog(REDIS_WARNING,"Fatal error loading the DB: %s. Exiting.",strerror(errno));
            exit(1);
        }
    }
}

总结：

1.我这边并没有显示是从aof读取数据，

2.明显的是这一次没有从RDB去读取数据库状态了，

3.如果你这时再去尝试重启redis的话，在正常退出时会去执行RDBsave保存，因为现在数据库内没值，所以RDB也就空了，再次执行时数据丢失。

因此如果在中途需要开启aof，注意需要预先保存RDB文件，不然你的数据全部丢失，如果之前还没备份的话，悲剧

但是如果一开始没有开启aof功能，而是中途开的呢。。。。。。。

1.模拟一下：塞值

127.0.0.1:6379> set key "this a key"
OK
127.0.0.1:6379> set k "this is a k"
OK
127.0.0.1:6379> set num "this is num"
OK
127.0.0.1:6379> keys *
1) "num"
2) "k"
3) "key"
127.0.0.1:6379> 

2.logfile信息：这次加载时从RDB加载的，此时aof暂时关闭

6945:M 25 Oct 15:55:05.810 * DB loaded from disk: 0.000 seconds
6945:M 25 Oct 15:55:05.810 * The server is now ready to accept connections on port 6379

3.执行bgrewriteaof操作：出现了aof文件，并且可以看见aof文件是有140K的数据的，说明刚刚的数据在其中

127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started
127.0.0.1:6379> 
-rw-r--r--. 1 root root  140 10月 25 15:59 appendonly.aof
-rw-r--r--. 1 root root   18 10月 25 15:36 dump.rdb

4.修改配置文件重启（相当于第一次重启）：可见是从aof文件读取数据的，此时数据没丢

7255:M 25 Oct 16:02:16.625 * DB loaded from append only file: 0.000 seconds
7255:M 25 Oct 16:02:16.625 * The server is now ready to accept connections on port 6379

5.查看数据：依然在数据库中

127.0.0.1:6379> keys *
1) "key"
2) "k"
3) "num"
127.0.0.1:6379> 

还有一种情况是同时配置，其实同时配置没什么具体的内容，不去实践了。。

总结一下加载顺序吧

1.如果只配置了aof，那么重启是加载aof

2.如果只配置了RDB，重启是加载RDB

3.如果同时存在，优先加载aof。

因此关键问题在于做好备份，备份，尤其是如果中途打开aof的话。

中途打开aof还有一种方式就是利用 config set 方式，但是只针对这一次有效，如果redis再次重启的话，会失效，因此还是存在风险，万一忘改了就遭了。。。

参考文章，吃水不忘挖井人

http://www.cnblogs.com/zhoujinyi/archive/2013/05/26/3098508.html