哪些网站可以做设计软件,宁夏网站备案,微信开发工具文档,苏州教育学会网站建设如何选择RDB和AOF 1 #xff09;同时开启 在我们 Redis 的服务器上#xff0c;把RDB和AOF同时打开, 这样可以通过RDB快速的恢复数据#xff0c;因为它是一个紧凑的缩缩的二进制文件, 但是有时 Redis 的不小心故障了#xff0c;丢失了十几分钟的数据 可以通过AOF来做数据的…如何选择RDB和AOF 1 同时开启 在我们 Redis 的服务器上把RDB和AOF同时打开, 这样可以通过RDB快速的恢复数据因为它是一个紧凑的缩缩的二进制文件, 但是有时 Redis 的不小心故障了丢失了十几分钟的数据 可以通过AOF来做数据的恢复, 因为它所有写命令都会记录Redis先加载AOF文件来恢复原始数据因为AOF数据比RDB更完整有时候我们会把一些错误的命令也记录在文件中, 会有一些潜在的bug可以通过 redis-check-aof 来做修复如果AOF文件实在是用不了恢复不了可以把RDB作为一种后备数据来使用这就是最常用的一种方式 为了考虑性能可以只在Slave上开启RDB,并且15min备份一次因为在主从模式下让从节点去实现持久化其实也是可以达到避免数据丢失的这样的一个效果如果为了避免 AOF rewite的IO以及阻塞可以在Redis集群中不开启AOF, 靠集群的备份机制来保证可用性在启动时选取较新的RDB文件如果集群全部崩溃会丢失15min前的数据
2 混合模式
Redis4.0开始支持该模式解决的问题Redis在重启时通常是加载AOF文件但加载速度慢因为 RDB 数据不完整所以加载 AOF开启方式aof-use-rdb-preamble true开启后AOF在重写时会直接读取RDB中的内容运行过程通过 bgrwriteaof 完成不同的是当开启混合持久化后 子进程会把内存中的数据以RDB的方式写入aof中把重写缓冲区中的增量命令以AOF方式写入到文件将含有RDB个数和AOF格数的AOF数据覆盖旧的AOF文件 新的AOF文件中一部分数据来自RDB文件一部分来自Redis运行过程时的增量数据
3 ) 数据恢复
当我们开启了混合持久化时启动Redis依然优先加载aof文件aof文件加载可能有两种情况如下 aof文件开头是rdb的格式先加载 rdb内容再加载剩余的 aofaof文件开头不是rdb的格式直接以aof格式加载整个文件 优点既能快速备份又能避免大量数据丢失缺点RDB是压缩格式AOF在读取它时可读性较差
二者动态切换
在Redis 2.2或以上版本可以在不重启的情况下从RDB切换到AOF: 为最新的dump.rdb文件创建一个备份将备份放到一个安全的地方 cp dump.rdb dump.rdb.bak 执行以下两条命令# 开启 aof
redis-cli config set appendonly yes
# 关闭 rdb
redis-cli config set save 确保写命令会被正确地追加到AOF文件的末尾执行的第一条命令开启了AOF功能 Redis会阻塞直到初始AOF文件创建完成为止所以不要在高峰期做这个事情之后Redis会继续处理命令请求并开始将写入命令追加到AOF文件末尾
Redis容灾备份 1 ) 开启RDB持久化
save 900 1
save 300 10
save 60 100002 ) 开启AOF配置
# 开启 aof
appendonly yes
appendfilename appendony. aof# rewrite
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb# appendfsync always
appendfsync everysec
# appendfsync no3 ) RDB日志备份编写脚本定时备份 vim bin/redis-rdb-copy-per-hour.sh #!bin/bash
cur_date$(date %Y%m%d%H%M%S)
rm -rf /usr/local/redis/snapshotting/$cur_date
mkdir -p /usr/local/redis/snapshotting/$cur_date
cp /usr/local/redis/data/dump.rdb /usr/local/redis/snapshotting/$cur_datedel_date$(date -d -48hour %Y%m%d%H%M)
rm -rf /usr/local/redis/snapshotting/$del_date备份与删除48小时之前的 使用 crontab 定时器执行备份脚本 确保机器上有定时任务服务 $ systemctl status crond 可看到定时服务是运行的状态默认linux都会集成 crond 服务没有启动进行 start 即可现在编写定时任务 $ crontab -e下面写入 (以下为每分钟执行一次生产环境可调整为每小时执行一次)*/1 * * * * sh /usr/local/redis/bin/redis-rdb-copy-per-hour.sh
*/1 * * * * sleep 10; sh /usr/local/redis/bin/redis-rdb-copy-per-hour.sh
*/1 * * * * sleep 20; sh /usr/local/redis/bin/redis-rdb-copy-per-hour.sh
*/1 * * * * sleep 30; sh /usr/local/redis/bin/redis-rdb-copy-per-hour.sh
*/1 * * * * sleep 40; sh /usr/local/redis/bin/redis-rdb-copy-per-hour.sh
*/1 * * * * sleep 50; sh /usr/local/redis/bin/redis-rdb-copy-per-hour.sh这里虽然每分钟执行一次但是加上了 sleep 用来演示阻塞的效果仅仅是演示*/1 表示“每 1 分钟”而其余的星号分别代表小时、日期、月份和星期几这里用星号表示任意值生产环境配置如0 * * * * sh /usr/local/redis/bin/redis-rdb-copy-per-hour.sh 每小时执行一次 查看定时任务列表 $ crontab -l到时间后检查是否生成相应的备份 这样就实现了通过脚本来实现了容灾备份 考虑到恢复则考虑到 redis 进程挂掉了 基于 aof 和 rdb 文件恢复即可如果 aof 文件损坏了可以通过机器上最新时间段的rdb副本来恢复
Redis 持久化的优化方案 1 独立部署
因为Redis 的RDB和AOF文件生成的这个过程除了会对内存和硬硬盘造成压力之外它其实都是属于一个CPU密集型的操作所以最好是把 Redis 单独部署在一台服务器上不要和其他的存储服务, 例如关系数据库或者说消息队列服务部署在一起消息队列和关系数据库本来就会有大量的磁盘IO再加上 Redis 的话可能磁盘和CPU就会受不了选择独立部署其实就是为了解决子进程的频繁开销的问题
2 ) 硬盘优化
可以根据写入量来决定比如当前这个 Redis 的服务器它有大量的写入请求的话可以决定是否使用性能更高的SSD的磁盘
3 ) 缓存禁用持久化
如果我们业务的Redis 它的定位就是做缓存缓存的数据肯定是在别的地方都已经有的即使它丢失了也不要紧这个缓存备份就是AB两套缓存比如A缓存失效了马上B缓存顶上去只需要把这种方案做好就行, 持久缓存的数据丢失了是不需要考虑的因为这个缓存的数据肯定是在关系数据库里边都有的丢失了也不要紧所以说这种场景下就可以把 Redis 这个节点的持久化功能直接给它禁用掉这样它从关系数据库加载提供缓存的服务就可以了
4 ) 主从模式从持久化
从模式主从模式从节点的数据是从主节点复制的因为从节点我们一般是不会开启写模式的也就是它是只读的它是写不进去数据的它的数据都是通过主节点复制过去的但是它每次从主节点复制数据的时候首先会主节点进行一次BGSAVE的操作然后跟磁盘交互一下生成RDB的快照然后再把快照发给从节点这就是一次复制的过程如果从节点频繁的跟主节点进行复制那么主节点这边肯定会压力比较大因为它频繁的在fork 进程去做RDB快照生成这件事情这样可以考虑把主节点的持久化给它关闭掉, 从节点来做持久化比如说从节点15分钟备份一次只需要在从节点上添加一个 save 900 1 就可以了甚至可以把AOF也给它禁用掉因为 master/slave 主从已经高可用了数据是不可能丢失的因为15分钟内假如说某一节点的数据丢失了但还有其他的节点还在工作着所以说不可能像之前单节点十几分钟的一个很长的窗口期当掉了数据全丢了也可以考虑AOF的禁用那就又节省掉了一大笔的IO的行为因为AOF它在 rewrite 的时候肯定会带来一个系统的波动因为AOF的同步策略默认情况下是每秒每一次的同步实际上都是它要去把这些数据从缓冲区写到一个AOF文件里边最后会覆盖掉原来的那个AOF文件它是这样去做的新浪微博的架构就是 主从模式 从节点备份然后关闭主节点AOF提高性能
5 ) 优化 fork 处理
这个优化就是降低 AOF 的重写频率RDB它虽然是子进程 fork 在做这件事情但是RDB毕竟是一个很长的时间窗口期才会去做这件事儿所以降低重写频率说的无非就是我们开启了AOF的情况比如说现在已经超过64m了它就会rewrite在rewrite的这个过程中它肯定是会影响到性能的那我们把 rewrite的执行的这个时间给它拉长即把重写上限调高比如从 64m 到 5g这样就可以降低rewrite的一个触发的频率这样也会提高我们的性能降低 fork 子进程的一个创建还有一个AOF的配置优化在重写的时候要不要去执行正常的追加操作 如果说在它重写的这个期间段内本来就已经带来阻塞了然后我还让它去正常进入我们正常的一些命令这个时候它又要去folk进程去做这件事开销销比较大的我们可以把这个 no-appendfsync-on-rewrite 选项改为 yes 默认是 no改为yes之后AOF 重写段内不去执行接收正常命令追加的这个行为这样的话它就会专心去做 rewriterewrite做完才会继续接受命令这个方案不好的地方就是重写期间的数据可能会丢失需要根据具体生产环境包括你的服务器CPU硬盘各方面因素来决定的如果你的硬盘是能扛得住的你的服务器性能是比较好的就可以忽略这个选项不要去禁用让它在重写期间仍然可以执行正常的追加就可以了
