【redis篇】redis持久化操作 |
您所在的位置:网站首页 › redis如何持久化到数据库 › 【redis篇】redis持久化操作 |
什么是持久化? 将数据从掉电易失的内存存放到能够永久存储的设备上 Redis持久化方式 RDB(Redis DB) hdfs: fsimage AOF(AppendOnlyFile) hdfs : edit logs 默认关闭的 第一种:RDB方式存储 在默认情况下,Redis 将数据库快照保存在名字为 dump.rdb的二进制文件中 方式:产生一个RDB: 1.阻塞方式: 客户端中执行save命令 (停服务,生产环境不用!)2.非阻塞方式:(复杂度高?) bgsave策略: 1.自动:按照配置文件中的条件满足就执行BGSAVE save 60 1000,Redis要满足在60秒内至少有1000个键被改动,会自动保存一次2.手动:客户端发起SAVE、BGSAVE命令1、手动方式: 1.1SAVE命令 redis > save 阻塞Redis服务,无法响应客户端请求 创建新的dump.rdb替代旧文件(覆盖 需要手动写脚本扫描目录) 1.2.BGSAVE命令 redis > bgsave 非阻塞,Redis服务正常接收处理客户端请求 Redis会fork()一个新的子进程来创建RDB文件,子进程处理完后会向父进程发送一个信号,通知它处理完毕 父进程用新的dump.rdb替代旧文件 备:写实复制方式解决实点数据不一致问题。子进程的指针会指向新的地址,而父进程还是指向原来的地址,持久化时候 不会存储被更改的值。 服务器内存: 512G redis容量:400G fork():copy on writ 子进程内存中存储父进程内存的指向,不必开辟真实400G的内存占用 父进程不会阻塞,如果客户端修改了父进程的内存,阻塞(copy on write):父进程的值,会在子进程中开辟(旧的)。父进程才真正修改。:阻塞是很小。 小的窗口:9:00 BGSAVE 10:00完成的是9:00 图解: 两种方式的比较: SAVE 和 BGSAVE 命令 SAVE不用创建新的进程,速度略快 BGSAVE需要创建子进程,消耗额外的内存 SAVE适合停机维护,服务低谷时段 BGSAVE适合线上执行 2.自动执行 其本质上就是BGSAVE 默认配置 save 900 1 save 300 10 save 60 10000 dbfilename dump.rdb dir /var/lib/redis/6379 只要上面三个条件满足一个,就自动执行备份。 创建RDB文件之后,时间计数器和次数计数器会清零。所以多个条件的效果不是叠加的自动执行的优点: 完全备份,不同时间的数据集备份可以做到多版本恢复(会覆盖 手动写脚本扫描目录拿走不同阶段备份,异地备份) 紧凑的单一文件,方便网络传输,适合灾难恢复 恢复大数据集速度较AOF快 自动执行的缺点: 会丢失最近写入、修改的而未能持久化的数据 fork过程非常耗时,会造成毫秒级不能响应客户端请求 生产环境: 创建一个定时任务cron job,每小时或者每天将dump.rdb复制到指定目录 确保备份文件名称带有日期时间信息,便于管理和还原对应的时间点的快照版本 定时任务删除过期的备份 如果有必要,跨物理主机、跨机架、异地备份 第二种:AOF方式存储 Append only file,采用追加的方式保存 AOF默认是关闭的,一旦开启后RDB机会备关闭。 默认文件appendonly.aof 记录所有的写操作命令,在服务启动的时候使用这些命令就可以还原数据库 因此在执行数据恢复的时候会很慢。 2.写入磁盘的策略 appendfsync选项,这个选项的值可以是always、everysec或者no Always:服务器每写入一个命令,就调用一次fdatasync,将缓冲区里面的命令写入到硬盘。这种模式下,服务器出现故障,也不会丢失任何已经成功执行的命令数据 Everysec(默认):服务器每一秒重调用一次fdatasync,将缓冲区里面的命令写入到硬盘。这种模式下,服务器出现故障,最多只丢失一秒钟内的执行的命令数据 备:使用较多。No:服务器不主动调用fdatasync,由操作系统决定何时将缓冲区里面的命令写入到硬盘。这种模式下,服务器遭遇意外停机时,丢失命令的数量是不确定的 运行速度:always的速度慢,everysec和no都很快 备:缓冲区一满就溢写。如果缓冲区设置过大,丢失数据过多。 3.AOF重写机制 AOF文件过大 合并重复的操作,AOF会使用尽可能少的命令来记录 4.重写过程 fork一个子进程负责重写AOF文件 子进程会创建一个临时文件写入AOF信息 父进程会开辟一个内存缓冲区接收新的写命令 子进程重写完成后,父进程会获得一个信号,将父进程接收到的新的写操作由子进程写入到临时文件中 新文件替代旧文件 注:如果写入操作的时候出现故障导致命令写半截,可以使用redis-check-aof工具修复 5.AOF重写触发的条件 手动:客户端向服务器发送BGREWRITEAOF命令 自动:配置文件中的选项,自动执行BGREWRITEAOF命令 auto-aof-rewrite-min-size ,触发AOF重写所需的最小体积:只要在AOF文件的体积大于等于size时,才会考虑是否需要进行AOF重写,这个选项用于避免对体积过小的AOF文件进行重写auto-aof-rewrite-percentage ,指定触发重写所需的AOF文件体积百分比:当AOF文件的体积大于auto-aof-rewrite-min-size指定的体积,并且超过上一次重写之后的AOF文件体积的percent %时,就会触发AOF重写。(如果服务器刚刚启动不久,还没有进行过AOF重写,那么使用服务器启动时载入的AOF文件的体积来作为基准值)。将这个值设置为0表示关闭自动AOF重写6.AOF重写配置项举例 auto-aof-rewrite-percentage 100 // 到达64M后扩容 auto-aof-rewrite-min-size 64mb appendonly no / yes 当AOF文件大于64MB时候,可以考虑重写AOF文件 只有当AOF文件的增量大于起始size的100%时(就是文件大小翻了一倍),启动重写 默认关闭,请开启 7.优缺点比较: 优点 写入机制,默认fysnc每秒执行,性能很好不阻塞服务,最多丢失一秒的数据 重写机制,优化AOF文件 如果误操作了(FLUSHALL等),只要AOF未被重写,停止服务移除AOF文件尾部FLUSHALL命令,重启Redis,可以将数据集恢复到 FLUSHALL 执行之前的状态 缺点 相同数据集,AOF文件体积较RDB大了很多 恢复数据库速度叫RDB慢(文本,命令重演) |
今日新闻 |
推荐新闻 |
CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |