1、将数据持久化至硬盘
2、将数据复制至其他机器;
复制是在数据持久化的基础上进行的。
1、介绍:Redis是一个基于内存的数据库,它的数据是存放在内存中,内存有个问题就是关闭服务或者断电会丢失。Redis的数据也支持写到硬盘中,这个过程就叫做持久化。
持久化的一个重要原因是为了在之后重用数据,或是为了防止系统故障而将数据备份到一个远程位置。
注意:通常 Redis 的主节点是不会进行持久化操作,持久化操作主要在从节点进行。
从节点是备份节点,没有来自客户端请求的压力,它的操作系统资源往往比较充沛。
2、Redis持久化选项:Redis提供了2种不同形式的持久化方式
(1)RDB(Redis DataBase) :Redis可以通过快照来获得存储在内存里面的数据在某个时间点上的副本。创建快照后,用户可以对快照进行备份,也可以将快照复制到其他服务器从而创建具有相同数据的服务器副本。简而言之,就是在指定的时间间隔内,定时的将 redis 存储的数据生成Snapshot快照并存储到磁盘等介质上。这是redis备份默认方式;
(2)AOF(Append only File) :只追加文件,将被执行的写命令写到AOF文件的末尾,,在下次 redis 重新启动时,只要把这些写指令从前到后再重复执行一遍,就可以实现数据恢复了。
3、实际使用:
(1)可以单独使用某一种。如果对数据不敏感,可以单独用RDB;但不建议单独使用AOF,因为可能会出现BUG。
(2)也可以同时使用这两种方式,官方推荐2个都启用。
?在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据,这是因为 AOF 方式的数据恢复完整度更高,且AOF文件保存的数据集要比RDB文件保存的数据集要完整
(3)可以选择关闭持久化: 如果没有数据持久化的需求,也完全可以关闭 RDB 和 AOF 方式,这样的话,redis 将变成一个纯内存数据库,就像 memcache 一样。
官网介绍:
4、比较:
?5、性能建议:
(1)因为RDB文件只用作后备用途,建议只在Slave上持久化RDB文件,而且只要15分钟备份一次就够了,只保留 save 900 1 这一条
(2)AOF的代价,一是带来持续的IO,二是AOF rewrite的最后将rewrite过程中产生的新数据(aof_rewrite_buf)写到文件造成的阻塞几乎是不可避免的。如果使用AOF,好处是在最恶劣的情况下也只会丢失不超过两秒数据,启动脚本较简单只load自己的AOF文件就可以了。
只要硬盘许可,应该尽量减少AOF rewrite的频率,AOF重写的基数大小默认值64M(autoaof-rewrite-min-size)太小了,可以设置到5G以上;默认超过原大小100%(auto-aof-rewrite-percentage)大小时重写可以改到适当的数值。
1、原理:
重启 Redis 时,我们很少使用 rdb 来恢复内存状态,因为会丢失大量数据。我们通常使用 AOF 日志重放,但是重放 AOF 日志性能相对 rdb 来说要慢很多,这样在 Redis 实例很大的情况下,启动需要花费很长的时间。
Redis 4.0 为了解决这个问题,带来了一个新的持久化选项——混合持久化。将 rdb 文件的内容和增量的 AOF 日志文件存在一起。这里的 AOF 日志不再是全量的日志,而是自持久化开始到持久化结束的这段时间发生的增量 AOF 日志,通常这部分 AOF 日志很小。
在 Redis 重启的时候,可以先加载 rdb 的内容,然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放,重启效率因此大幅得到提升。
2、混合持久化配置:
在redis的配置文件当中有一个aof-use-rdb-preamble
参数来开启 混合持久化,默认是yes
开启的。混合持久化结合了 RDB 和 AOF 的优点,Redis 5.0 默认是开启的。
3、混合持久化优缺点:
(1)优点:混合持久化结合了 RDB 和 AOF 持久化的优点,开头为 RDB 的格式,使得 Redis 可以更快的启动,同时结合 AOF的优点,有减低了大量数据丢失的风险。
(2)缺点: