第1章 Redis持久化介绍
1.为什么需要持久化
因为Redis是内存性数据库,启动后会将所有的数据载入到内存里
如果服务器重启,内存里数据就没了,所以为了避免丢失数据
Redis可以按照一定的条件定期的将数据持久化到磁盘上
2.Redis持久化格式
RDB格式: 快照持久化
优点:
压缩格式
备份恢复速度快
缺点:
不是实时备份
属于重量级操作,会消耗CPU和内存资源
因为是压缩格式,所以不可阅读
AOF格式:
优点:
近乎实时备份,数据丢失的风险小
有一定的可读性
缺点:
持久化文件占用空间大
恢复速度没有RDB快
第2章 Redis持久化RDB格式
1.配置RDB
save 900 1
save 300 10
save 60 10000
dbfilename redis.rdb
dir /data/redis_6379/
2.配置解释
after 900 sec (15 min) if at least 1 key changed
after 300 sec (5 min) if at least 10 keys changed
after 60 sec if at least 10000 keys changed
3.持久化命令
bgsave
4.实验结论
没有配置save触发条件:
不会自动持久化
只有手动执行持久化命令才能持久化
停止或重启都不会进行持久化
配置了save触发条件:
不管有没有满足触发条件,当关闭/重启/kill/pkill的时候都会持久化
kill -9 不会自动持久化
恢复时：
1.持久化数据文件名要和配置文件里定义的一样才能被识别
2.RDB文件只有一个数据文件，迁移和备份只要这一个RDB文件即可
第3章 Redis持久化AOF格式
1.AOF格式配置
appendonly yes
appendfilename "redis.aof"
appendfsync everysec
2.实验结论
AOF会每秒保存一次操作记录
文件容量比RDB要大
AOF和RDB可以同时开启
恢复时:
如果RDB和AOF同时存在,则只读取AOF文件
测试AOF的安全性:
1.写入脚本
#!/bin/bash
for i in {1..10000}
do
redis-cli set k_${i} v_${i} >> /tmp/redis.log
done
2.kill -9
3.对比日志和写入的数据
3.AOF清理机制
redis Redis指令 AOF
k3 set k1 set k1
set k2 set k1 set k2
set k3 set k1 set k2 set k3
del k1 set k1 set k2 set k3 del k1
del k2 set k1 set k2 set k3 del k1 del k2
set k3
手动持久化rdb
bgsave
第一步删除aof，rdb
第二步
手动压缩aof
原理:
Redis会定期的比较AOF文件里的指令和内存里的数据对比
如果失效的比例超过一定百分比,那么Redis就会进行AOF的重写并压缩
重写就是将AOF里失效的语句删除
手动执行AOF压缩命令:
BGREWRITEAOF
4.如果软件停止了过期的key如何处理
Redis会将设置了过期Key的过期时间记录在aof或rdb里
当你重启的时候,读取aof里的过期时间,然后和当前系统时间做对比
如果已经过期了,就删除
第4章 redis用户验证
1.配置密码认证功能
requirepass 123456
2.使用认证方法
方法1: 命令里使用
# redis-cli
127.0.0.1:6379> keys *
(error) NOAUTH Authentication required.
127.0.0.1:6379> auth 123456
OK
127.0.0.1:6379> keys *
方法2: 连接时使用
# redis-cli -a 123456
3.为什么redis的密码认证这么简单?
redis一般都部署在内网环境，默认是相对比较安全的
有同学担心密码写在配置文件里，不用担心
因为开发不允许SSH登陆到Linux服务器，但是可以远程连接Redis，所以设置密码还是有作用的
第5章 禁用或重命名危险命令
1.Rdis危险命令
keys *
FLUSHALL
SHUTDOWN
CONFIG
2.禁用危险命令
rename-command SHUTDOWN "526195417"
改变命令名称
rename-command keys ""
禁止使用
修改完成后要重启redis
第6章 Redis主从复制
1.配置命令
在从库上执行该命令
临时配置:
SLAVEOF 10.0.0.52 6379
永久配置:写入配置文件
SLAVEOF 10.0.0.52 6379
db-52配置dir目录
先取消复制关系
查看状态
db-52 配置aof目录
2.取消复制关系
slaveof no one
3.主从复制原理
1)从节点发送同步请求到主节点
2)主节点接收到从节点的请求之后,做了如下操作
- 立即执行bgsave将当前内存里的数据持久化到磁盘上
- 持久化完成之后,将rdb文件发送给从节点
3)从节点从主节点接收到rdb文件之后,做了如下操作
- 清空自己的数据
- 载入从主节点接收的rdb文件到自己的内存里
4)后面的操作就是和主节点实时的了
4.主从复制注意
1)从节点只读不可写
2)从节点不会自动故障转移，他会一直尝试同步主节点，并且依然不可写
3)主从复制故障转移需要介入的地方
- 修改代码指向新主的IP
- 从节点需要执行slaveof no one
4)从库建立同步时会清空自己的数据，如果同步对象写错了，就清空了
5)从库也可以正常的RDB持久化
5.主从复制注意
一定要做好数据备份，无论是主节点还是从节点，操作前最好做下备份
第7章 Redis热更新配置
1.实验背景
配置文件只有RDB配置
不重启Redis,不丢失数据的情况下激活AOF功能
2.实验思路
第1步: 热更新配置打开AOF功能
CONFIG set appendonly yes
CONFIG set appendfsync everysec
第2步: AOF立即持久化
BGREWRITEAOF
第3步: 修改配置文件,下次重启生效
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
清除主从配置