redis 持久化+主从

Redis持久化

1.RDB和AOF优缺点

RDB: 快照,把当前内存里的状态快照到磁盘上
优点: 压缩格式/恢复速度快
缺点: 可能会丢失数据

AOF: 类似于mysql的binlog,重写,、每次操作都写一次/1秒写一次
优点: 安全,有可能会丢失1秒的数据
缺点: 文件比较大,恢复速度慢 

持久化RDB

1.配置

[root@db01 redis_6379]# vim /opt/redis_6379/conf/redis_6379.conf
save 900 1
save 300 10
save 60 10000

背景：

1.配置文件里设置了数据目录和持久化文件名

现象：

1.直接关闭重启，数据丢失

2.执行了bgsave之后。数据目录持久化了，重启数据不丢失

背景：

1.配置文件设置了数据目录和持久化文件名

2.设置了触发条件

现象：

1.触发条件都不满足，但是重启之后数据还在，持久化了

结论：

1.如果不设定触发条件，关闭redis不会持久化

2.如果设定了触发条件，即使触发持久化，但是关闭的时候，redis会替你执行一次bgsave

2.结论:

1.执行shutdown的时候,内部会自动执行bgsave,然后再执行shutdown
2.pkill  会持久化
kill     会持久化
killall  会持久化
shutdown  会持久化.会触发bgsave持久化
kill -9 不会持久化


3.恢复的时候,rdb文件名称要和配置文件里写的一样
4.如果没有配置save参数,执行shutdown不会自动bgsave持久化
5.如果没有配置save参数,可以手动执行bgsave触发持久化保存

常用命令:
ll /data/redis_6379/
cat /opt/redis_6379/conf/redis_6379.conf
vim /opt/redis_6379/conf/redis_6379.conf
pkill redis
redis-server /opt/redis_cluster/redis_6379/conf/redis_6379.conf
redis-cli -h db01
redis-cli -h db01 shutdown
bash for.sh


3.配置AOF
appendfilename "redis_6379.aof"
appendonly yes
appendfsync everysec

3.实验

设置数据
127.0.0.1:6379> MSET k1 v1 k2 v2 k3 v3
OK
#关机
[root@db01 redis_6379]# redis-cli
127.0.0.1:6379> SHUTDOWN
not connected>
#开机
[root@db01 redis_6379]# redis-server /opt/redis_6379/conf/redis_6379.conf
#查看
[root@db01 redis_6379]# ll
total 4
-rw-r--r-- 1 root root 102 Dec 25 15:17 redis_6379.rdb
[root@db01 redis_6379]# redis-cli
127.0.0.1:6379> KEYS *
1) "k1"
2) "k2"
3) "k3"
127.0.0.1:6379> 

实验:
如果aof和rdb文件同时存在,redis会如何读取:

实验步骤:
1.插入一条数据
aof: 有记录
rdb: 没有记录
2.复制到其他地方
3.把redis停掉
4.清空数据目录
5.把数据文件拷贝过来
aof: 有记录
rdb: 没有记录
6.启动redis
7.测试,如果有新插入的数据,就表示读取的是aof,如果没有,就表示读取的是rdb

实验结论:
如果2种数据格式都存在,优先读取aof


官方文档：
https://redis.io/topics/persistence

如何选择：
好的，那我该怎么用？
通常的指示是，如果您希望获得与PostgreSQL可以提供的功能相当的数据安全性，则应同时使用两种持久性方法。
如果您非常关心数据，但是在灾难情况下仍然可以承受几分钟的数据丢失，则可以仅使用RDB。
有很多用户单独使用AOF，但我们不建议这样做，因为不时拥有RDB快照对于进行数据库备份，加快重启速度以及AOF引擎中存在错误是一个好主意。
注意：由于所有这些原因，我们将来可能会最终将AOF和RDB统一为一个持久性模型（长期计划）。
以下各节将说明有关这两个持久性模型的更多详细信息。

持久化AOF

开启AOF功能需要设置配置:

appendonly yes,默认不开启.AOF文件名通过appendfilename配置设置,默认文件名是appendonly.aof. 保存路径通RDB持久化方式一致,通过dir配置指定.

1.AOF的工作流程

1.所有写入命令会追加到aof_buf(缓冲区)中.

2.AOF缓冲区根据对应的策略向硬盘做同步操作

3.随着AOF文件越来越大,需要定期对AOF文件进行重写,达到压缩的目的.

4.当Redis服务重启时,可以加载AOF文件进行数据恢复.

2.配置

[root@db01 redis_6379]# vim /opt/redis_6379/conf/redis_6379.conf
appendfilename "redis_6379.aof"
appendonly yes
appendfsync everysec

3.实验

#开机
[root@db01 redis_6379]# redis-server /opt/redis_6379/conf/redis_6379.conf
[root@db01 redis_6379]# ll
total 4
-rw-r--r-- 1 root root   0 Dec 25 16:05 redis_6379.aof
-rw-r--r-- 1 root root 102 Dec 25 16:04 redis_6379.rdb
#插入数据
[root@db01 redis_6379]# redis-cli
127.0.0.1:6379> KEYS *
(empty list or set)
127.0.0.1:6379> MSET k1 v1 k2 v2 k3 v3
OK
127.0.0.1:6379>
#查看
[root@db01 redis_6379]# ll
total 8
-rw-r--r-- 1 root root  85 Dec 25 16:07 redis_6379.aof
-rw-r--r-- 1 root root 102 Dec 25 16:04 redis_6379.rdb
#再次插入
[root@db01 redis_6379]# redis-cli set k4 v4
OK
#再次查看发现.aof 有变化 而.rdb没有变化
[root@db01 redis_6379]# ll
total 8
-rw-r--r-- 1 root root 114 Dec 25 16:09 redis_6379.aof
-rw-r--r-- 1 root root 102 Dec 25 16:04 redis_6379.rdb


#for循环插入数据
for i in {1..10000}; do redis-cli set k_${i} v_${i};echo ${i};done

4.结论

.aof 是实时记录的
.rdb 是关机或者pkill 做的一个备份

测试,如果有新插入的数据,就表示读取的是aof,如果没有,就表示读取的是rdb

实验结论:
如果2种数据格式都存在,优先读取aof

官方解释：

https://redis.io/topics/persistence

安全认证

#配置密码
[root@db01 redis_6379]# vim /opt/redis_6379/conf/redis_6379.conf
requirepass 123456



[root@db01 redis_6379]# pkill redis
[root@db01 redis_6379]# redis-server /opt/redis_6379/conf/redis_6379.conf

#登录发现需要认证
[root@db01 redis_6379]# redis-cli
127.0.0.1:6379> KEYS *
(error) NOAUTH Authentication required.
#输入密码登录
[root@db01 redis_6379]# redis-cli -a 123456
127.0.0.1:6379> get k1
"v1"

禁用危险命令

配置文件里添加禁用危险命令的参数
[root@db01 redis_6379]# vim /opt/redis_6379/conf/redis_6379.conf

rename-command KEYS ""
rename-command FLUSHALL ""

rename-command FLUSHDB ""

rename-command CONFIG ""


#关机
[root@db01 redis_6379]# pkill redis
#启动
[root@db01 redis_6379]# redis-server /opt/redis_6379/conf/redis_6379.conf
[root@db01 redis_6379]# redis-cli -a 123456
#查看
127.0.0.1:6379> KEYS *
(error) ERR unknown command 'KEYS'



设置一个别名
[root@db01 redis_6379]# vim /opt/redis_6379/conf/redis_6379.conf

rename-command KEYS "AA"
rename-command FLUSHALL ""

rename-command FLUSHDB ""

rename-command CONFIG ""

就是 输入 AA*的时候，才可以看到keys *的所有内容

主从复制

快速创建第二台redis节点命令:

[root@db01 redis_6379]# yum install -y rsync
利用rsync 传到对端
[root@db01 redis_6379]# rsync -avz /opt/* db02:/opt/
[root@db01 redis_6379]# rsync  -avz /data db02:/

db02 操作

[root@db02 ~]# cd /opt/redis
[root@db02 redis]# make install

修改端口
[root@db02 redis]# sed -i 's#51#52#g' /opt/redis_6379/conf/redis_6379.conf

[root@db02 redis]# rm -rf /data/redis_6379/*

启动
[root@db02 redis]# redis-server /opt/redis_6379/conf/redis_6379.conf

进入查看
[root@db02 redis]# redis-cli
127.0.0.1:6379> KEYS *
(empty list or set)
开始做主从

#临时生效
127.0.0.1:6379> SLAVEOF 10.0.0.51 6379
ok
127.0.0.1:6379> get k1
"v1"
#永久生效 将SLAVEOF 10.0.0.51 6379  写入配置文件中

注意：做主从的时候，从的配置文件一定要跟主的一模一样，要不然做不了

主的配置文件

[root@db01 redis_6379]# !v
vim /opt/redis_6379/conf/redis_6379.conf

### 监听端口
port 6379
### pid文件和log文件的保存地址
pidfile /opt/redis_6379/pid/redis_6379.pid
logfile /opt/redis_6379/logs/redis_6379.log
### 设置数据库的数量，默认数据库为0
databases 16
### 指定本地持久化文件的文件名,默认是dump.rdb
dbfilename redis_6379.rdb
### 本地数据库的目录
dir /data/redis_6379
#save 900 1
#save 300 10
#save 60 10000
#
#appendfilename "redis_6379.aof"
#appendonly yes
#appendfsync everysec
#requirepass 123456

通过看日志来分析主从复制的原理

[root@db02 ~]# cat /opt/redis_6379/logs/redis_6379.log

从节点日志

9744:S 25 Dec 19:03:53.501 * Connecting to MASTER 10.0.0.51:6379
9744:S 25 Dec 19:03:53.502 * MASTER <-> SLAVE sync started
9744:S 25 Dec 19:03:53.502 * Non blocking connect for SYNC fired the event.
9744:S 25 Dec 19:03:53.502 * Master replied to PING, replication can continue...
9744:S 25 Dec 19:03:53.503 * Partial resynchronization not possible (no cached master)
9744:S 25 Dec 19:03:53.505 * Full resync from master: cbd36d5d4638a5433f3e6bbaf1e402fe8abb5ee4:1

#从节点接收主节点发送的数据,然后载入内存:

9744:S 25 Dec 19:03:53.602 * MASTER <-> SLAVE sync: receiving 147898 bytes from master
9744:S 25 Dec 19:03:53.604 * MASTER <-> SLAVE sync: Flushing old data
9744:S 25 Dec 19:03:53.604 * MASTER <-> SLAVE sync: Loading DB in memory
9744:S 25 Dec 19:03:53.616 * MASTER <-> SLAVE sync: Finished with success



======================================================================================
主节点日志
[root@db01 ~]# cat /opt/redis_6379/logs/redis_6379.log
33819:M 25 Dec 19:02:56.917 * DB loaded from disk: 0.013 seconds

#主节点收到请求之后开始持久化保存数据:
33819:M 25 Dec 19:02:56.917 * The server is now ready to accept connections on port 6379
33819:M 25 Dec 19:03:53.815 * Slave 10.0.0.52:6379 asks for synchronization
33819:M 25 Dec 19:03:53.815 * Full resync requested by slave 10.0.0.52:6379
33819:M 25 Dec 19:03:53.815 * Starting BGSAVE for SYNC with target: disk
33819:M 25 Dec 19:03:53.815 * Background saving started by pid 33826
33826:C 25 Dec 19:03:53.830 * DB saved on disk
33826:C 25 Dec 19:03:53.831 * RDB: 8 MB of memory used by copy-on-write

#主节点收到从节点同步完成的消息
33819:M 25 Dec 19:03:53.913 * Background saving terminated with success
33819:M 25 Dec 19:03:53.915 * Synchronization with slave 10.0.0.52:6379 succeeded

主从复制流程:

1.从节点发送同步请求到主节点
2.主节点接收到从节点的请求之后,做了如下操作

- 立即执行bgsave将当前内存里的数据持久化到磁盘上
- 持久化完成之后,将rdb文件发送给从节点
  3.从节点从主节点接收到rdb文件之后,做了如下操作
- 清空自己的数据
- 载入从主节点接收的rdb文件到自己的内存里
  4.后面的操作就是和主节点实时的了

取消主从复制
SLAVEOF no one

查看取消主从复制日志

[root@db02 ~]# cat /opt/redis_6379/logs/redis_6379.log

9744:M 25 Dec 19:25:12.655 # Connection with master lost.
#缓存断开连接的主状态
9744:M 25 Dec 19:25:12.655 * Caching the disconnected master state.
#丢弃以前缓存的主状态。
9744:M 25 Dec 19:25:12.655 * Discarding previously cached master state.
9744:M 25 Dec 19:25:12.656 * MASTER MODE enabled (user request from 'id=5 addr=127.0.0.1:53702 fd=6 name= age=3 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=slaveof')




[root@db01 ~]# cat /opt/redis_6379/logs/redis_6379.log
#连接从10.0.0.52:6379丢失。
33819:M 25 Dec 19:25:12.967 # Connection with slave 10.0.0.52:6379 lost.

注意!!!
1.从节点只读不可写
2.从节点不会自动故障转移,它会一直同步主
10.0.1.52:6379> set k1 v1
(error) READONLY You can't write against a read only slave.
3.主从复制故障转移需要人工介入

• 修改代码指向REDIS的IP地址
• 从节点需要执行SLAVEOF no one

注意!!!
1.从节点会清空自己原有的数据,如果同步的对象写错了,就会导致数据丢失

安全的操作:
1.无论是同步,无论是主节点还是从节点

2.先备份一下数据