做网站什么价位,企业建网站能不能一次进费用,所谓做网站就这么几步,wordpress 简单幻灯片插件持久化之RDB
RDB的持久化方式是在指定时间间隔#xff0c;执行数据集的时间点快照。也就是在指定的时间间隔将内存中的数据集快照写入磁盘#xff0c;也就是Snapshot内存快照#xff0c;它恢复时再将硬盘快照文件直接读回到内存里面。
RDB保存的是dump.rdb文件。
自动触发…持久化之RDB
RDB的持久化方式是在指定时间间隔执行数据集的时间点快照。也就是在指定的时间间隔将内存中的数据集快照写入磁盘也就是Snapshot内存快照它恢复时再将硬盘快照文件直接读回到内存里面。
RDB保存的是dump.rdb文件。
自动触发
默认redis是有三种自动触发的规则在配置文件中也有注释
分别是一个小时内有一次变化五分钟内有100次变化一分钟内有10000次变化。如果要配置自己的规则可以在配置文件中写一下语法
save (time) (changes)
time指的是在多少时间内单位是秒。
changes指的是变化次数单位是次。
也可以在一行配置多个规则
save (time) (changes) (time) (changes) (time) (changes)……
只要redis数据库中存在一定的变化满足了规则就会进行一次快照
手动触发
手动触发分为两个指令SAVE和BGSAVE
只要执行了这两个指令就会进行一次快照。
至于这两指令有和区别呢
SAVE使用SAVE的时候在保存快照文件期间当前redis服务器会被阻塞将不能正常进行缓存因为会影响redis的功能的使用所以通常这个指令不被推荐使用。
BGSAVE使用BGSAVE的时候redis会fork出一个子进程来进行持久化原来的主线程不会被影响通常推荐使用这个指令
如果要想查看上一次快照的时间可以使用LASTSAVE指令步骤按如下 RDB的优点和缺点
优点 适合大规模的数据恢复按时业务定时备份对数据完整性和一致性要求不高RDB文件在内存中的加载速度要比AOF快得多 缺点 如果Redis意外地down了就会丢失从当前到最近一次的快照期间的数据会导致快照文件的丢失内存数据的全量同步如果数据量太大会导致IO严重影响服务器性能RDB依赖于主进程的fork在更大的数据集中可能会导致服务请求的瞬间延迟。fork的时候内存中的数据被克隆了一份导致两倍的膨胀率 检查修复RDB文件的命令redis-check-rdb (rdb文件的路径)
快照执行的情况 配置文件中默认的快照规则手动执行SAVE和BGSAVE命令执行了flushall和flushdb命令但是产生的快照文件是空的执行shutdown且没有开启使用AOF主从复制时主节点自动触发 如何禁用快照动态停止所有RDB保存规则的方法redis-cli config set save “”
或者在配置文件中写一个 save “”
RDB优化配置项
在配置文件中 stop-write-on-bgsave-error默认是yes如果配置成no表示不在乎数据不一致或者有其他的手段发现和控制这种不一致那么在快照写入失败时也能确保redis继续接收新的写请求。建议使用yesrdbcompression默认yes对于存储到磁盘中的快照可以设置是否进行压缩存储如果是的话redis会采用LZF算法进行压缩。如果不想消耗CPU来进行压缩的话可以设置关闭次功能。建议使用yesrdbchecksum在存储快照后还可以让redis使用CRC64算法来进行数据校验但是这样做会增大约10%的性能消耗如果希望获取到最大的性能提示可以关闭此功能。建议使用yesrdb-del-sync-files在没有持久性的情况下删除复制中使用的RDB文件启用。默认情况下是no此选项是禁用的 持久化之AOF
AOFappend only file是以日志的形式来记录每个写操作将Redis执行过的所有写的指令记录下来读操作不记录只许追加文件但是不可以更改文件redis启动后会读取改文件重新构建数据换言之redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
默认情况下redis并没有开启AOF的开启AOF的功能需要设置配置文件中的appendonly为yes
AOF保存的是appendonly.aof文件
AOF工作流程
Client作为命令的来源会有多个源头以及源源不断的请求命令在这些命令到达Redis Server后并不是直接写入AOF文件会将这些命令先放入AOF缓存中进行保存。这里的AOF缓冲区实际上是内存中的一片区域存在的目的是当这些命令达到一定量以后再写入磁盘避免频繁地磁盘IO操作AOF缓冲会根据AOF缓冲区同步文件的三种写回策略将命令写入磁盘上的AOF文件随着写入AOF的内容的增加为避免文件膨胀会根据对着进行命令的合并又称AOF的重写从而起到AOF文件压缩的目的当Redis Server服务器重启的时候会从AOF文件中载入数据
写回策略可在配置文件中进行配置appendfsync有以下三种 everysecredis默认为这种方式每秒写回每个写命令执行完后只是把日志写到AOF的内存缓冲区没隔一秒把缓冲区中的内容写入磁盘always同步写回每个命令执行完后立即同步地将日志写回磁盘性能影响大no由操作系统控制的写回每个写命令执行完只是先把日志写到AOF文件的内存缓冲区由操作系统决定何时将缓冲区写回磁盘容易丢失数据 在Redis6中AOF文件分为三种类型 base标识基础AOF一般由子进程通过重写产生该文件最多只有一个 incr表示增量AOF一般会在AOFRW开始执行是被创建该文件可能存在多个。 history表示历史AOF由BASE和INCR变化而来每次AOFRW成功完成时本次AOFRW之前对应的base和incr都将变成historyhistory类型的AOF会被Redis自动删除 为了管理这些AOF文件引入了一个manifest文件来跟踪、管理这些AOF。同时为了便于AOF备份和拷贝我们将所有的AOF文件和mainfest文件放入一个单据的文件目录目录名由appenddirname配置决定
AOF文件修复命令redis-check-aof --fix (文件名)
AOF优缺点
优点 使用AOF后Redis更加持久使用每秒读入的方式是当出现异常时只会出现一秒的数据丢失AOF日志是一个仅附加日志不会出现寻道问题不会因为断电出现损坏如果因为一些原因出现写到一半结尾了可以使用redis-check-aof工具来修复文件当AOF变得太大时可以在后台自动重写AOF。格式易于理解和解析易于恢复数据。 缺点 AOF文件通常比相同数据集的等效RDB文件大AOF运行效率要慢于rdbeverysec时 AOF重写机制
由于AOF持久化是Redis不断将写命令记录到AOF文件中随着Redis不断地进行AOF文件会越来越大。文件越大占用服务器内存越大以及AOF恢复要求时间越长。
为了解决这个问题Redis新增了重写机制当AOF文件的大小超过所设定的峰值时Redis就会自动启动AOF文件的内容压缩只保留可以恢复数据的最小指令集
自动触发是默认为根据上次重写的AOF大小增长了一倍并且文件大小有64mb时自动进行重写
或者可以手动使用命令bgrewriteaof来重写
最小指令集的案例
set k1 v2
set k1 v3
set k1 v4
最终只保留set k1 v4
重写原理 在重写开始前redis会创建一个”重写子进程“这个子进程会读取现有的AOF文件并将其包含的指令进行分析压缩并写入到一个临时文件中。与此同时主进程会将新接收到的指令一边累积到内存缓冲区中一边继续写入到原有的AOF文件中这样做是保证原有的AOF文件的可用性避免在重写过程中出现意外。当”重写子进程“完成重写工作后会给父进程发一个信号父进程收到信号后就会将内存中的缓存的写指令追加到新的AOF中当追加结束后redis就会用新的AOF文件来代替旧的AOF文件之后再有新的写指令就都会追加到新的AOF文件中重写AOF文件的操作并没有读取旧的AOF文件而是将整个内存中的数据库内容用命令的方式重写了一个新的AOF文件和快照有点类似 RDBAOF混合持久化
如果同时开启RDB和AOF重启时只会加载AOF文件不会加载RDB文件如果没有AOF就会加载RDB文件
当redis重启时会优先载入AOF文件来恢复原始的数据因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整
RDB的数据不实时同时使用两者时服务器重启只会找AOF但是也建议不要只使用AOF因为AOF在不断变化不好备份RDB更适合用于备份数据库留着RDB作为一个万一的手段
开启混合方式设置设置aof-use-rdb-preamble的值为yes
混合持久化之后RDB镜像做全量持久化AOF做增量持久化
先使用RDB进行快照存储然后使用AOF持久化所有的写操作当重写策略满足或者手写触发重写的时候将最新的数据存储为新的RDB记录。这样的话重启服务的时候会从RDB和AOF两个部分恢复数据又提高了恢复数据的性能。简单来说混合持久化方式产生的文件一部分是RDB格式一部分是AOF格式
纯缓存模式
同时关闭RDB和AOFRedis只做缓存功能。
在这种情况下依然可以使用手动触发的方式使用AOF和RDB
