中建八局土木建设有限公司网站,wordpress sensei插件,培训公司网站建设,市北区网站建设目录 前言
RDB
AOF
总结 前言
我们都知道Redis 是基于内存的数据库#xff0c;一旦服务器的进程退出#xff0c;数据库数据就会随之丢失#xff0c;这不是我们想看到的#xff0c;为了避免这个问题#xff0c;Redis 为我们提供了俩种持久化方案#xff0c;将数据保存…目录 前言
RDB
AOF
总结 前言
我们都知道Redis 是基于内存的数据库一旦服务器的进程退出数据库数据就会随之丢失这不是我们想看到的为了避免这个问题Redis 为我们提供了俩种持久化方案将数据保存到磁盘上去避免数据的丢失。 数据的持久化存储是 Redis 的重要特性之一它能够将内存中的数据保存到本地磁盘中实现对数据的持久存储。这样即使在服务器发生故障之后也能通过本地磁盘对数据进行恢复。 RDB
RDB 即快照模式它是 Redis 默认的数据持久化方式它会将数据库的快照保存在 dump.rdb 这个二进制文件中。 RDB持久化产生的RDB文件是一个经过压缩的二进制文件这个文件被保存在硬盘中redis可以通过这个文件还原数据库当时的状态。 RDB 持久化提供了两种触发策略一种是手动触发另一种是自动触发。
手动触发是通过SAVAE命令或者BGSAVE命令将内存数据保存到磁盘文件中。
SAVE阻塞redis的服务器进程直到RDB文件被创建完毕。BGSAVE派生(fork)一个子进程来创建新的RDB文件记录接收到BGSAVE当时的数据库状态父进程继续处理接收到的命令子进程完成文件的创建之后会发送信号给父进程而与此同时父进程处理命令的同时通过轮询来接收子进程的信号。 自动触发策略是指 Redis 在指定的时间内数据发生了多少次变化时会自动执行BGSAVE命令。自动触发的条件包含在了 Redis 的配置文件中 # 以下配置表示的条件
# 服务器在900秒之内被修改了1次
save 900 1
# 服务器在300秒之内被修改了10次
save 300 10
# 服务器在60秒之内被修改了10000次
save 60 10000save 900 1 表示在 900 秒内至少更新了 1 条数据Redis 自动触发 BGSAVE 命令将数据保存到硬盘。save 300 10 表示在 300 秒内至少更新了 10 条数据Redis 自动触 BGSAVE 命令将数据保存到硬盘。save 60 10000 表示 60 秒内至少更新了 10000 条数据Redis 自动触发 BGSAVE 命令将数据保存到硬盘。 优点
1.RDB是二进制压缩文件占用空间小便于传输传给slaver 2.主进程fork子进程可以最大化Redis性能 3.使用RDB文件来恢复数据较快。
缺点
1、不保证数据完整性会丢失最后一次快照以后更改的所有数据 2、父进程在fork子进程的时候如果主进程比较大会阻塞
AOF
AOF 被称为追加模式或日志模式是 Redis 提供的另一种持久化策略它能够存储 Redis 服务器已经执行过的的命令并且只记录对内存有过修改的命令这种数据记录方法被叫做“增量复制”其默认存储文件为appendonly.aof。
具体配置可以在配置文件中进行配置
#AOF 和 RDB 持久化方式可以同时启动并且无冲突。
#如果AOF开启启动redis时会加载aof文件这些文件能够提供更好的保证。
appendonly yes# 只增文件的文件名称。默认是appendonly.aof
# appendfilename appendonly.aof
#redis支持三种不同的写入方式
#
# no:不调用之等待操作系统来清空缓冲区当操作系统要输出数据时。很快。
# always: 每次更新数据都写入仅增日志文件。慢但是最安全。
# everysec: 每秒调用一次。折中。
appendfsync everysec # 设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入.官方文档建议如果你有特殊的情况可以配置为yes。但是配置为no是最为安全的选择。
no-appendfsync-on-rewrite no # 自动重写只增文件。
# redis可以自动盲从的调用‘BGREWRITEAOF’来重写日志文件如果日志文件增长了指定的百分比。
# 当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时自动启动新的日志重写过程。
auto-aof-rewrite-percentage 100
# 当前AOF文件启动新的日志重写过程的最小值避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。
auto-aof-rewrite-min-size 64mb服务器配置中有一项appendfsync这个配置会影响服务器多久完成一次命令的记录
always将缓存区的内容总是即时写到AOF文件中。everysec将缓存区的内容每隔一秒写入AOF文件中。no 写入AOF文件中的操作由操作系统决定一般而言为了提高效率操作系统会等待缓存区被填满才会开始同步数据到磁盘。
redis默认实用的是everysec。 在RDB和AOF备份文件都有的情况下redis会优先载入AOF备份文件 Redis 在长期运行的过程中aof 文件会越变越长。如果机器宕机重启“重演”整个 aof 文件会非常耗时导致长时间 Redis 无法对外提供服务。因此就需要对 aof 文件做一下“瘦身”运动。Redis 提供了 AOF 重写机制手动执行BGREWRITEAOF命令开始重写 aof 文件
127.0.0.1:6379 BGREWRITEAOF
Background append only file rewriting started
新的 aof 文件记录的数据库数据和原 aof 文件记录的数据库数据完全一致新的 aof 文件会使用尽可能少的命令来记录数据库数据因此新的 aof 文件的体积会小很多AOF 重写期间服务器不会被阻塞它可以正常处理客户端发送的命令
优点
更好的保护数据不丢失性能高可做紧恢复
缺点
等量级的命令AOF持久化文件要大于RDB持久化文件恢复速度慢于RDB
总结
RDB持久化AOF持久化全量备份一次保存整个数据库。增量备份一次只保存一个修改数据库的命令。每次执行持久化操作的间隔时间较长。保存的间隔默认为一秒钟Everysec数据保存为二进制格式其还原速度快。使用文本格式还原数据所以数据还原速度一般。执行 SAVE 命令时会阻塞服务器但手动或者自动触发的 BGSAVE 不会阻塞服务器AOF持久化无论何时都不会阻塞服务器。 如果进行数据恢复时既有 dump.rdb文件又有 appendonly.aof 文件您应该先通过 appendonly.aof 恢复数据这能最大程度地保证数据的安全性。
