数据持久化
简介
数据持久化,就是将内存中的数据,持久化到本地磁盘中,推荐(SSD 固态硬盘)
数据持久化的方式:
RDB(快照方式): RDB方式是一种快照式的持久化方法,将某一时刻的数据持久化到磁盘中。这种方式就是将内存中数据以快照的方式写入到二进制文件中 ,默认的文件名为dump.rdb。
AOF(日志追加): AOF方式是将执行过的写指令记录下来,在数据恢复时按照从前到后的顺序再将指令执行一遍。这种方式 redis 会将每一个收到的写命令都通过 write 函数追加到文件中(默认appendonly.aof)。
RDB + AOF: 您也可以在同一实例中合并AOF和RDB
RDB 优缺点
优点: 快速和方便
缺点: 单服务器出现断电、网络连接不稳定或者服务器出现重启的状态有可能就会丢失数据(数据的不完整性)
AOF 优缺点
优点: AOF只是追加日志文件,因此对服务器性能影响较小,速度比RDB要快,消耗的内存较少。
缺点: AOF方式生成的日志文件太大,即使通过AOF重写,文件体积仍然很大。 恢复数据的速度比RDB慢。
RDB持久化触发机制
触发RDB持久化过程分为手动触发和自动触发
手动触发
手动触发持久化的操作有二个:save和bgsave。它们主要区别体现在:是否阻塞 Redis 主线程的执行。
save命令
在客户端中执行 save 命令,就会触发 Redis 的持久化,但同时也是使 Redis 处于阻塞状态,直到 RDB 持久化完
成,才会响应其他客户端发来的命令,所以在生产环境一定要慎用
示例:
#检查dump.rdb 的生成时间
[root@data-server ~]# ll
-rw-r--r-- 1 root root 99 Dec 21 10:37 dump.rdb
127.0.0.1:6379[1]> save #登录redis 服务器支持save命令
OK
#再次查看dump.rdb 的生成时间
[root@data-server ~]# ll
-rw-r--r-- 1 root root 104 Dec 21 10:38 dump.rdb
bgsave命令
bgsave(background save)既后台保存的意思, 它和 save 命令最大的区别就是 bgsave 会 fork() 一个子进程来 执行持久化,整个过程中只有在 fork() 子进程时有短暂的阻塞,当子进程被创建之后,Redis 的主进程就可以响应 其他客户端的请求了,相对于整个流程都阻塞的 save 命令来说,显然 bgsave 命令更适合我们使用
示例:
#执行前
[root@data-server ~]# ll
-rw-r--r-- 1 root root 104 Dec 21 10:38 dump.rdb
[root@data-server ~]# redis-cli
127.0.0.1:6379> bgsave
#执行后
[root@data-server ~]# ll
-rw-r--r-- 1 root root 104 Dec 21 10:58 dump.rdb
自动触发
自动触发持久化,本质是 Redis 通过判断,如果满足设置的触发条件,自动执行一次 bgsave 命令。
RDB 自动持久化主要来源于以下几种情况:
save m n
表示的是在 m 秒内,如果有 n 个键发生改变,则自动触发持久化。 如:
配置文件(/usr/local/redis/redis.conf)中的默认配置
# save 3600 1 300 100 60 10000
# 如果至少进行了 1 次更改,则在 3600 秒(1 小时)后启动持久化
# 如果至少执行了 100 次更改,则在 300 秒(5 分钟)后启动持久化
# 如果至少执行了 10000 次更改,则保存 60 秒后启动持久化
RDB持久化配置
[root@data-server redis-7.0.14]# cat redis.conf | grep save | egrep '^save'
save 60 5 #定义触发自动RDB持久化的条件 </br>
stop-writes-on-bgsave-error yes #如果执行bgsave的时候,出现错误是否定义执行备份,yes|no yes:表示停止备份,no:不停止
#rdb文件是否压缩
rdbcompression yes
#写入文件和读取文件时是否开启rdb文件检查,检查是否有无损坏,如果在启动是检查发现损坏,则停止启动
rdbchecksum yes
#rdb持久化后存放的文件名
dbfilename dump_test.rdb
rdb-del-sync-files no
#rdb持久化后文件的存放路径
dir /data/redis_backup/
重启服务
[root@data-server redis-7.0.14]# redis-server redis.conf
触发自动备份的条件
[root@data-server ~]# redis-cli
127.0.0.1:6379> SELECT 2
OK
127.0.0.1:6379[2]> set name1 "Xl"
OK
127.0.0.1:6379[2]> SET name2 "xw"
OK
127.0.0.1:6379[2]> SET name3 "xh"
OK
127.0.0.1:6379[2]> SET name4 "xs"
OK
127.0.0.1:6379[2]> SET name5 "xs"
OK
检查是否可以实现自动备份
[root@data-server redis-7.0.14]# ll /data/redis-backup/
total 4
-rw-r--r-- 1 root root 144 Dec 21 11:47 dump_test.rdb
恢复数据
- 清除缓存(redis)
AOF 持久化
AOF方式在使用Redis存储非临时数据时,一般都需要打开AOF持久化来降低进程终止导致的数据丢失,AOF可以将 Redis执行的每一条写命令追加到硬盘文件中,这一过程显然会降低Redis的性能,但是大部分情况下这个影响是可 以接受的,另外,使用较快的硬盘能提高AOF的性能。
AOF 工作方式
命令写入 (append)、文件同步(sync)、文件重写(rewrite)、重启加载 (load)
AOF特点
默认文件名是 appendonly.aof。保存的位置由配置中 dir 来配置目录。
AOF 每次都会保存写命令,数据实时性更高。
AOF 需要使用“重写机制”来优化,每次记录写命令,文件会很大的问题。
AOF 根据不同的“缓冲区同步策略”将我们缓冲区中写入的命令,同步到磁盘。、
缓冲区同步策略
设置appendfsync 控制,一共3种:
always:客户端的每一个写操作都保存到aof文件当中,这种策略很安全,但是每个写都会有IO操作,所以也很
慢。
everysec:每秒写入一次aof文件,因此,最多可能会丢失1s的数据。 推荐使用这种方式。
no: 交由操作系统来处理什么时候写入aof文件。更快,但也是最不安全的选择,不推荐使用。
开启AOF持久化
redis.conf AOF 持久化默认配置文件
appendonly no #默认不开启AOF日志备份, NO不开启 yes 开启AOF日志机制
appendfilename "appendonly.aof" #AOF持久化文件名
appenddirname "appendonlydir" #存放持久化文件的所在目录
appendfsync everysec #缓冲同步策略,默认值
no-appendfsync-on-rewrite no #是否重写,默认不重写
案例:
[root@gitbook-server ~]# redis-cli -h 192.168.212.163
192.168.212.163:6379> SELECT 1
OK
192.168.212.163:6379[1]> set name xiaosan
OK
192.168.212.163:6379[1]> set name xiaosi
[root@data-server appendonlydir]# cat appendonly_test.aof.1.incr.aof
*2
$6
SELECT
$1
1
*3
$3
set
$4
name
$7
xiaosan
*3
$3
set
$4
name
$6
xiaosi
*3
$3
SET
$5
name2
$7
xiaobai
*3
$3
set
$5
name3
$6
xiaosi
*3
$3
set
$5
name4
$6
xiaowu
恢复过程
AOF 重写
7.1、为什么要重写 随着aof文件越来越大,需要定期对aof文件进行重写,达到压缩的目的。
7.2、重写aof改变
进程内已经超时的数据不再写入文件。
旧的aof有无效命令(如:set k1 hello ex 10000),新的aof文件只保留最终数据的写入命令。
多条写命令可以合并为一个(如:lpush list a、lpush list b、lpush list c可以转化为:lpush list a b c)。但也不 能将整个lpush生成的元素全部写在一起,所以对于list、set、hash、zset等类型操作,以64个元素为界拆分为多 条。来防止客户端缓冲区溢出。
AOF重写降低了文件占用空间,更小的aof 文件启动redis时,加载更快。
7.3、重写方式 AOF重写过程可以手动触发和自动触发:
手动触发:直接调用bgrewriteaof命令。
自动触发:根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机
7.3.1 配置文件 修改配置文件/usr/local/redis/redis.conf
auto-aof-rewrite-percentage100#AOF文件增⻓率(当前AOF文件大小超过上一次重写的AOF文件大小的 百分之多少才会重写)
auto-aof-rewrite-min-size64mb#表示运行AOF重写时文件最小体积,默认为64MB。
注意:
aof_current_size: aof当前尺寸(单位:字节)
aof_base_size: aof上次启动和重写的尺寸(单位:字节)
7.5.2、自动触发时机
当前 AOF 文件大小超过最小重写尺寸
当前 AOF 文件大小超过上次重写完的 AOF 尺寸的百分之多少(auto-aof-rewrite-percentage)
换算:
自动触发时机=aof_current_size>auto-aof-rewrite-min-size&&(aof_current_size- aof_base_size)/aof_base_size>=auto-aof-rewrite-percentage
查看aof_current_size和aof_base_size的值
Redis
192.168.212.163:6379[1]> info persistence
# Persistence
loading:0
async_loading:0
current_cow_peak:0
current_cow_size:0
current_cow_size_age:0
current_fork_perc:0.00
current_save_keys_processed:0
current_save_keys_total:0
rdb_changes_since_last_save:0
rdb_bgsave_in_progress:0
rdb_last_save_time:1703213843
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:0
rdb_current_bgsave_time_sec:-1
rdb_saves:4
rdb_last_cow_size:286720
rdb_last_load_keys_expired:0
rdb_last_load_keys_loaded:0
aof_enabled:1
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:0
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_rewrites:1
aof_rewrites_consecutive_failures:0
aof_last_write_status:ok
aof_last_cow_size:339968
module_fork_in_progress:0
module_fork_last_cow_size:0
aof_current_size:385
aof_base_size:192
aof_pending_rewrite:0
aof_buffer_length:0
aof_pending_bio_fsync:0
aof_delayed_fsync:0
1 auto-aof-rewrite-percentage100#AOF文件增⻓率(当前AOF文件大小超过上一次重写的AOF文件大小的 百分之多少才会重写)
2 auto-aof-rewrite-min-size64mb#表示运行AOF重写时文件最小体积,默认为64MB。
295>64M &&(295-211)/211>=100
只有当这二个条件同时成立,我们才会去触发我们的重写AOF 7.6、aof文件恢复
AOF 恢复
在写入aof日志文件时,如果Redis服务器宕机,则aof日志文件文件会出格式错误,在重启Redis服务器时,Redis 服务器会拒绝载入这个aof文件,可以通过以下步骤修复aof并恢复数据。
备份现在aof文件,以防万一。
* Reading RDB preamble from AOF file...
* Reading the remaining AOF tail...
# !!! Warning: short read while loading the AOF file !!!
# !!! Truncating the AOF at offset 439 !!!
# AOF loaded anyway because aof-load-truncated is enabled
可以通过redis自带工具redis-check-aof工具修复原始文件
redis-check-aof --fix {filename}
开启redis密码验证
protected-mode yes
requirepass 123456 #设置密码
客户端登录
[root@gitbook-server ~]# redis-cli -h 192.168.212.163 -a 123456
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
192.168.212.163:6379> KEYS * #获取所在库里的所有的key
(empty array)
192.168.212.163:6379> SELECT 1
OK
192.168.212.163:6379[1]> KEYS *
1) "name4"
2) "a8"
3) "a3"
4) "a4"
5) "a9"
6) "name"
7) "a5"
8) "name2"
9) "a11"
10) "a7"
11) "a10"
12) "a2"
13) "a1"
14) "a6"
15) "name3"