加载中...
数据持久化
发表于:2024-01-10 | 分类: NoSQL
字数统计: 14k | 阅读时长: 13 mins.分钟 | 阅读量:

数据持久化

简介

数据持久化,就是将内存中的数据,持久化到本地磁盘中,推荐(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

恢复数据

  1. 清除缓存(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"
上一篇:
redis
下一篇:
mysql 配置环境变量
本文目录
本文目录