网站定制 北京,公司邮箱是什么,外贸网站优化软件,深圳律师网站建设目录 引言
AOF持久化模式编辑编辑
AOF与RDB的混合持久化(4.x后的新特性)
AOF的优缺点
修复破损aof文件
到底用RDB还是AOF 引言
AOF就相当于上面的日志形式。是追加式备份。所有发生的写操作#xff0c;新增啊#xff0c;修改啊#xff0c;删除啊#xff0c;这些命…目录 引言
AOF持久化模式编辑编辑
AOF与RDB的混合持久化(4.x后的新特性)
AOF的优缺点
修复破损aof文件
到底用RDB还是AOF 引言
AOF就相当于上面的日志形式。是追加式备份。所有发生的写操作新增啊修改啊删除啊这些命令都会记录在这个AOF日志里。 如果追求数据的一致性RDB会丢失最后一次的备份数据所以往往会采用AOF来做。AOF丢失的 数据会比RDB相对来说少一些。 需要注意redis是先执行写操作指令随后再把指令追加进aof中。有时候奇葩的面试官会问你先后顺序有些同学会冷不丁的犹豫一会。 特点:
类似日志的形式把所有写操作追加到文件追加的形式是append一个个命令追加而不是修改 比如说set k1 abcset k2 def,set k1 123虽然有两次k1但是不会合并而是追加。(后面会提到压缩)redis恢复的时候先恢复aof如果aof有问题(比如破损)则再恢复rdb.|redis恢复的时候是读取aof中的命令从头到尾读一遍然后数据恢复。 可以通过 bgrewriteaof 手动触发。异步重写aof日志假如重写失败那么数据还是存在的因为老的aof还在。
使用AOF引发的问题思考 Redis运行了好多年了比如10年用的AOF那么假如某一天redis名机挂了 1.这个10年的AOF有 多大?最大可以占用多少空间?有没有可能达到10来个T或者更大?
按理说会如果你吃饱了没事做就只对某个key新增修改删除无限次的做这样的作持续了十来年那么这个aof文件会很大而且都是重复的命令。但是AOF可以压缩重写使得体积不大。
2.恢复10几个T文件的时候内存不大会不会溢出?
不会。虽然文件很大但是有效的命令实际的不会很多。而且可以压缩重写这样体积不大读取肯定更加快速。
3.10来个T的aof恢复需要多久有没有可能1天?1周
按照现有情况来说有可能吧。
以上三点都是aof文件庞大而出现的顾虑其实aof可以重写对日志有一个重写机制 bgrewriteaof其实也就是瘦身的作用尝试想一想如果一个人很胖了不能越来越胖吧应该时不时的运动下瘦个身那么aof重写也是一个道理。
AOF持久化模式
AOF与RDB的混合持久化(4.x后的新特性)
yes:AOF重写redis会把当前所有的数据以rdb形式存入到aof中这都是二进制数据数据量小随后新的数据以aof形式追加到这个aof中那么这个aof中包含两种文件类型数据一个是rdb一个是aof那么恢复的时候redis会同时恢复这样恢复过程会更快。这相当于是一个混合体。no:关闭混合模式aof只会压缩重复的命令这是4.x以前老版本的机制也就是把重复的没有意义的指令去除减少文件体积也减少恢复的时间。 可能会有同学会问在重写AOF的时候如果有新的命令进来要写入怎么办?那么他其实也会fork一个子进程子进程复制重写而新的那些写入命令会被记录到一个缓冲区待子进程重写完毕后缓冲工区的新的写命令会被追加到新的AOF文件中这样就保持了数据在重写前后的一致性
AOF的优缺点
优点
耐用性高秒级别备份AOF更加耐用可以以秒级别为单位备份(通常我们都是每设置为1秒)如果发生问题也只会丢失最后一秒的数据大大增加了可靠性和数据完整性。所以AOF可以每秒备份一次使用fsync操作。log日志追加不惧怕磁盘大小限制以log日志形式追加如果磁盘满了会执行redis-check-aof 工具aof过大重写当数据太大的时候redis可以在后台自动重写aof当redis继续把日志追加到老的文件中去时重写也是非常安全的不会影响客户端的读写操作。日志形式更加有利于redis解析和恢复AOF 日志包含的所有写操作会更加便于redis的解析恢复
缺点
相同数据量AOF比RDB大更耗时相同的数据同一份数据AOF比RDB大而且恢复起来也会很耗时很慢同步比RDB慢针对不同的同步机制AOF会比RDB慢因为AOF每秒都会备份做写操作这样相对与RDB来说就略低。 每秒备份fsync没毛病但是如果客户端的每次写入就做一次备份fsync的话那么redis的性能就会下降。AOF数据可能不完整AOF发生过bug就是数据恢复的时候数据不完整这样显得AOF会比较脆弱容易出现bug因为AOF没有RDB那么简单但是呢为了防止bug的产生AOF就不会根据旧的指令去重构而是根据当时缓存中存在的数据指令去做重构这样就更加健壮和可靠了。
修复破损aof文件
如果aof文件破损那么可以修复一些无用的命令使得其还是可以继续恢复正常内容: redis-check-aof --fix [aof文件名]目的:删除不符合语法的指令 aof-load-truncated yes:Redis启动加载aof命令语法不完整则修复。设置为noRedis启动失败需要手动用redis-check-aof 工具修复
到底用RDB还是AOF
般来说可以RDBAOF的同时开启使用。上面已经说了可以把它们作为一个混合体去使用。如果说用户对redis的写操作不多甚至没有95%以上都是读操作那么用rdb也没啥问题我们有一个项目是采用的缓存预热方式用户几乎没有写操作所以直接采用RDB就够用了因为哪怕redis挂了甚至RDB没了数据还是能通过预热重新载入。如果说你们的Redis要作为一部分的数据库来使用那么需要用到aof或者rdbaof的混合模式这样数据的完整性就更大了
