Reids持久化-AOF

2023-11-02 本文已影响0人风雪_夜归人

AOF（Appen Only File）
以日志的形式记录服务器所处理的每一个更改操作，但操作过多。aof文件过大时，加载文件恢复数据会非常慢，为解决该问题，Redis支持aof文件重写，通过重写aof可以生成以给恢复当前数据的最少命令集。

所以流程大致分为两步，一是命令的实时写入，二是对aof文件的重写

命令写入流程：命令写入=》追加到aof_buf =》同步到aof磁盘（考虑到磁盘IO性能增加缓冲）

aof重写可以手动或自动触发

命令触发：bgrewriteaof
自动触发：根据配置规则来触发（整体时间和Redis的定时任务频率有关系）

在写入aof日志文件时，如果reids服务宕机，则日志文件会出格式错误，重启服务时，服务器会拒绝载入这个aof文件，此时可以通过以下命令修复aof并恢复数据
redis-check-aof -fix file.aof

appendonly yes 开启
appendfilename "appendonly.aof" 文件名称
appendfsync everysec 同步方式
- always: 把每个明亮都立即同步到aof，很慢但是安全
- everysec: 每秒同步一次，是折中方案
- no:redis不处理交给os来处理，非常快，但是也是最不安全的
no-appendfsync-on-rewrite no 重写期间是否同步
重写触发
- auto-aof-rewrite-precentage 100 百分比
- auto-aof-rewrite-min-size 64mb 最小数据量
aof-load-truncated 加载aof出错时如何处理
- yes：出错时向客户端写入log后继续执行
- no: 出错就停止执行
aof-rewrite-incremental-fsync yes 文件重写策略
aof-use-rdb-preamble yes
当RDB与AOP两种方式都开启时，redis启动时会优先使用AOF日志来恢复数据，因为AOF保存文件比RDB文件更完整
redis4.0提供了一个混合持久化的选择，将rdb文件的内容和增量的aof日志存在一起，重启时先加载rdb，再重放aof,以达到最大效率。

image.png

在重写期间，由于主机进程依然在响应命令，为了保证最终备份的完整性；因此它依然会写入旧的AOF file中，如果重写失败，能够保证数据不丢失

为了把重写期间的响应写入信息也写入到新的文件中，因此也会为子进程保留一个buf，防止新写的file丢失数据

重写是直接把当前内存的数据生成对应命令，并不需要读取老的AOF文件进行分析、命令合并

AOF文件直接采用文本协议，主要是兼容性好、追加方便、可读性高可认为修改修复