网站建设工作室门头,seo排名赚,河北怎样做网站,网站建设公司是怎么找客户前引 1、redis持久化的文件是什么 dump.rdb appendonly.aof 2、这两中文件有什么异同 save 秒 1 alaways everysec no 3、文件存放的位置 dir ./ 4、默认的存放位置:命令启动的地方 dir 自定义的路径 rdb 和aof 文件 存放在同一个路径下面 5、rdb文件默认备份的策略是什么…前引 1、redis持久化的文件是什么 dump.rdb appendonly.aof 2、这两中文件有什么异同 save 秒 1 alaways everysec no 3、文件存放的位置 dir ./ 4、默认的存放位置:命令启动的地方 dir 自定义的路径 rdb 和aof 文件 存放在同一个路径下面 5、rdb文件默认备份的策略是什么如何修改这个策略 save 600 1 6、备份的原理是什么 Redis备份的原理是通过将Redis数据库中的数据持久化到磁盘上从而实现数据的备份和恢复。 7、aof持久化的流程 AOF持久化的流程主要包括以下几个步骤 在Redis服务器启动时会根据配置的持久化策略打开或者创建一个AOF文件用于记录所有修改数据库的指令。 当客户端对数据库进行增删改操作时Redis会将这些操作转换成相应的指令并追加到AOF文件的末尾。 Redis在执行完每条写命令后会调用fsync()函数强制将AOF缓冲区的内容写入到磁盘上。这样会导致性能稍微有些下降但可以更好地保证数据不丢失。 当AOF文件变得太大时Redis会自动触发AOF重写AOF Rewrite操作。AOF重写是指将AOF文件中的历史指令重新生成一份新的AOF文件并且只保留产生快照后的数据从而避免了AOF文件的膨胀和无效指令的累积。 在Redis关闭时也会调用fsync()函数将最后一次操作的指令保存到AOF文件中。 通过AOF持久化方式Redis可以在重启后通过执行AOF文件中的指令恢复出先前的数据库状态。虽然相比RDB持久化方式AOF持久化的文件较大但是它可以保证更高的数据完整性和可靠性并且可以提供更好的读写性能。
主从复制的原理
一 Redis持久化之RDB Redis 提供了2个不同形式的持久化方式。 RDBRedis DataBase AOFAppend Of File 1.RDB是什么 在指定的时间间隔内将内存中的数据集快照写入磁盘 也就是行话讲的Snapshot快照它恢复时是将快照文件直接读到内存里 2. 备份是如何执行的 Redis会单独创建fork一个子进程来进行持久化会先将数据写入到 一个临时文件中待持久化过程都结束了再用这个临时文件替换上次持久化好的文件。 整个过程中主进程是不进行任何IO操作的这就确保了极高的性能 如果需要进行大规模数据的恢复且对于数据恢复的完整性不是非常敏感那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。 3.Fork Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据变量、环境变量、程序计数器等 数值都和原进程一致但是是一个全新的进程并作为原进程的子进程 在Linux程序中fork()会产生一个和父进程完全相同的子进程但子进程在此后多会exec系统调用出于效率考虑Linux中引入了“写时复制技术” 一般情况父进程和子进程会共用同一段物理内存只有进程空间的各段的内容要发生变化时才会将父进程的内容复制一份给子进程。 4. RDB持久化流程 5. dump.rdb文件 在redis.conf中配置文件名称默认为dump.rdb 文件在哪里启动这个文件就在哪里 6. 配置位置 rdb文件的保存路径也可以修改。默认为Redis启动时命令行所在的目录下 redis.conf dir /myredis/ 7. 如何触发RDB快照保持策略 7.1 配置文件中默认的快照配置时间间隔 7.2 命令save bgsave save save时只管保存其它不管全部阻塞。手动保存。不建议。 bgsaveRedis会在后台异步进行快照操作快照同时还可以响应客户端请求。 可以通过lastsave 命令获取最后一次成功执行快照的时间 7.3 flushall命令 执行flushall命令也会产生dump.rdb文件但里面是空的无意义 7.4 SNAPSHOTTING快照 7.5. Save 格式save 秒 写操作次数 RDB是整个内存的压缩过的SnapshotRDB的数据结构可以配置复合的快照触发条件 默认是1分钟内改了1万次或5分钟内改了10次或15分钟内改了1次。 禁用 不设置save指令或者给save传入空字符串 7.6. stop-writes-on-bgsave-error 当Redis无法写入磁盘的话(磁盘已满)直接关掉Redis的写操作。推荐yes. 7.7 rdbcompression 压缩文件 对于存储到磁盘中的快照可以设置是否进行压缩存储。如果是的话redis会进行压缩。
如果你不想消耗CPU来进行压缩的话可以设置为关闭此功能。推荐yes. 7.8. rdbchecksum 检查数据的完整性 在存储快照后还可以让redis来进行数据校验如果数据已经损坏就不需要再进行持久化的操作这样做会增加大约10%的性能消耗如果希望获取到最大的性能提升可以关闭此功能
推荐yes. 7.9. rdb的备份 先查询rdb文件的目录 将*.rdb的文件拷贝到别的地方 rdb的恢复 关闭Redis 先把备份的文件拷贝到工作目录下 cp dump2.rdb dump.rdb 启动Redis, 备份数据会直接加载 7.10. 优势 适合大规模的数据恢复 对数据完整性和一致性要求不高更适合使用 节省磁盘空间 恢复速度快 7.11 劣势 Fork的时候内存中的数据被克隆了一份大致2倍的膨胀性需要考虑 虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。 在备份周期在一定间隔时间做一次备份所以如果Redis意外down掉的话就会丢失最后一次快照后的所有修改。
二 Redis持久化之AOF 2.1. AOFAppend Only File 2.1.1. 是什么 以日志的形式来记录每个写操作增量保存将Redis执行过的所有写指令记录下来(读操作不记录) 只许追加文件但不可以改写文件redis启动之初会读取该文件重新构建数据换言之redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作 2.1.2. AOF持久化流程 1客户端的请求写命令会被append追加到AOF缓冲区内 2AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中 3AOF文件大小超过重写策略或手动重写时会对AOF文件rewrite重写压缩AOF文件容量 4Redis服务重启时会重新load加载AOF文件中的写操作达到数据恢复的目的 2.1.3. AOF默认不开启 可以在redis.conf中配置文件名称默认为 appendonly.aof AOF文件的保存路径同RDB的路径一致。 2.1.4. AOF和RDB同时开启redis听谁的 AOF和RDB同时开启系统默认取AOF的数据数据不会存在丢失 2.1.5. AOF启动/修复/恢复 AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样都是拷贝备份文件需要恢复时再拷贝到Redis工作目录下启动系统即加载。 正常恢复 修改默认的appendonly no改为yes 将有数据的aof文件复制一份保存到对应目录 恢复重启redis然后重新加载 异常恢复 修改默认的appendonly no改为yes 如遇到AOF文件损坏通过 /usr/redis/bin/redis-check-aof --fix 文件的位置/appendonly.aof进行恢复 备份被写坏的AOF文件 恢复重启redis然后重新加载 2.1.6. AOF同步频率设置 appendfsync always 始终同步每次Redis的写入都会立刻记入日志性能较差但数据完整性比较好 appendfsync everysec 每秒同步每秒记入日志一次如果宕机本秒的数据可能丢失。 appendfsync no redis不主动进行同步把同步时机交给操作系统。 2.1.7. Rewrite压缩 1是什么 AOF采用文件追加方式文件会越来越大为避免出现此种情况新增了重写机制, 当AOF文件的大小超过所设定的阈值时Redis就会启动AOF文件的内容压缩 只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof 2重写原理如何实现重写 AOF文件持续增长而过大时会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)redis4.0版本后的重写是指上就是把rdb 的快照以二级制的形式附在新的aof头部作为已有的历史数据替换掉原来的流水账操作。 no-appendfsync-on-rewrite 如果 no-appendfsync-on-rewriteyes ,不写入aof文件只写入缓存用户请求不会阻塞但是在这段时间如果宕机会丢失这段时间的缓存数据。降低数据安全性提高性能 如果 no-appendfsync-on-rewriteno, 还是会把数据往磁盘里刷但是遇到重写操作可能会发生阻塞。数据安全但是性能降低 触发机制何时重写
Redis会记录上次重写时的AOF大小默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发
重写虽然可以节约大量磁盘空间减少恢复时间。但是每次重写还是有一定的负担的因此设定Redis要满足一定条件才会进行重写。
auto-aof-rewrite-percentage设置重写的基准值文件达到100%时开始重写文件是原来重写后文件的2倍时触发
-40m 80
auto-aof-rewrite-min-size设置重写的基准值最小文件64MB。达到这个值开始重写。
例如文件达到70MB开始重写降到50MB下次什么时候开始重写100MB
系统载入时或者上次重写完毕时Redis会记录此时AOF大小设为base_size,
如果Redis的AOF当前大小 base_size base_size*100% (默认)且当前大小64mb(默认)的情况下Redis会对AOF进行重写。 3、重写流程背 1bgrewriteaof触发重写判断是否当前有bgsave或bgrewriteaof在运行如果有则等待该命令结束后再继续执行。 2主进程fork出子进程执行重写操作保证主进程不会阻塞。 3子进程遍历redis内存中数据到临时文件客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。 41).子进程写完新的AOF文件后向主进程发信号父进程更新统计信息。2).主进程把aof_rewrite_buf中的数据写入到新的AOF文件。 5使用新的AOF文件覆盖旧的AOF文件完成AOF重写。
