本文目录一览：
- 1、Redis数据库备份、迁移、恢复实践
- 2、redis文件中的dump.rdb文件是怎么生成的
- 3、Redis 持久化 ★
- 4、rdb文件,如何替换
- 5、关于Redis RDB方式数据备份与恢复
- 6、RDB、AOF持久化及如何优化fork
Redis数据库备份、迁移、恢复实践
描述: 当我们需要备份或迁移Redis集群时可以采用以下方案。
第三方redis集群数据迁移工具项目参考( )
描述:在系统删除了配置文件后以及用户账号后恢复方法流程，实际环境中建议利用rdb文件进行重新部署。
2.Kubernetes中单实例异常数据迁移恢复实践
方案1.利用其他kubernetes集群进行恢复原k8s集群的redis数据。
命令执行示例:
Tips : 从上述恢复结果可以看出以aof方式恢复的数据比rdb恢复的数据完整，但所加载的时间会随着数据增大会使得AOF方式耗时比rdb耗时更多。
方案2.利用宿主机安装编译redis源码，进行恢复原k8s集群的redis数据
方案3.利用Kubernetes部署的Redis集群，进行恢复原k8s集群的redis数据
Tips : 若id没发生变化，直接重启下该从节点就能解决。
Redis数据的导出和导入：dump和load方式
redis文件中的dump.rdb文件是怎么生成的
1、使用CRT远程登录装有redis的机器。
2、登录redis,执行命令redis-cli -h 127.0.0.1 -p 6379，其中127.0.0.1为redis的ip地址，6379为redis端口号，执行save命令保存数据，该命令将在redis安装目录中创建dump.rdb文件。-.rdb备份文件
3、如果忘记了 redis 安装目录，执行config get dir。
4、进入redis安装目录，拷贝生成的dump.rdb。
5、如果需要恢复数据，拷贝备份文件 dump.rdb到安装目录 。
6、启动redis服务端，/etc/init.d/redis_6355 start。
Redis 持久化 ★
1、RDB
2、AOF
3、两种的使用场景
在指定的时间间隔内将内存中的数据集快照写入磁盘， 也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里
Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。-.rdb备份文件
（1）Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程
（2）在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，Linux中引入了“写时复制技术”
（3）一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。
在redis.conf中配置文件名称，默认为dump.rdb
rdb文件的保存路径，也可以修改。默认为Redis启动时命令行所在的目录下
dir "/myredis/"
dir ./ 表示在当前配置文件的文件夹下生成 .rdb文件
（1）配置文件中默认的快照配置
（2）命令save VS bgsave
save ：save时只管保存，其它不管，全部阻塞。手动保存。不建议。
bgsave：Redis会在后台异步进行快照操作， 快照同时还可以响应客户端请求。
可以通过lastsave 命令获取最后一次成功执行快照的时间
（3）save（禁用）
格式：save 秒钟 写操作次数
RDB是整个内存的压缩过的Snapshot，RDB的数据结构，可以配置复合的快照触发条件，
默认是1分钟内改了1万次，或5分钟内改了10次，或15分钟内改了1次。(短时间内越多越快)
不设置save指令，或者给save传入空字符串
（4）stop-writes-on-bgsave-error
如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制
（5）rdbcompression 压缩文件
对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能：
（6）rdbchecksum
在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能：
（7）rdb的备份
1）将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可
2）CONFIG GET dir获取目录
（1）优点：
适合大规模的数据恢复
对数据完整性和一致性要求不高更适合使用
节省磁盘空间
恢复速度快
（2）缺点：
Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。
在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。
以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作-.rdb备份文件
（1）客户端的请求写命令会被append追加到AOF缓冲区内；
（2）AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；
（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；
（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的
可以在redis.conf中配置文件名称，默认为 appendonly.aof
AOF文件的保存路径，同RDB的路径一致。
AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失）
AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载。
正常恢复：
修改默认的appendonly no，改为yes
将有数据的aof文件复制一份保存到对应目录(查看目录：config get dir)
恢复：重启redis然后重新加载
异常恢复：
修改默认的appendonly no，改为yes
如遇到AOF文件损坏，通过/usr/local/bin/redis-check-aof--fix appendonly.aof进行恢复
备份被写坏的AOF文件
恢复：重启redis，然后重新加载
appendfsync always
始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好
appendfsync everysec
每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
appendfsync no
redis不主动进行同步，把同步时机交给操作系统。
（1）是什么
AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制, 当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩， 只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof-.rdb备份文件
（2）重写原理，如何实现重写
AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，redis4.0版本后的重写，是指上就是把rdb 的快照，以二级制的形式附在新的aof头部，作为已有的历史数据，替换掉原来的流水账操作。-.rdb备份文件
no-appendfsync-on-rewrite：
如果 no-appendfsync-on-rewrite=yes ,不写入aof文件只写入缓存，用户请求不会阻塞，但是在这段时间如果宕机会丢失这段时间的缓存数据。（降低数据安全性，提高性能）
重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定Redis要满足一定条件才会进行重写。
（3）重写流程
（1）bgrewriteaof触发重写，判断是否当前有bgsave或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行。
（2）主进程fork出子进程执行重写操作，保证主进程不会阻塞。
（3）子进程遍历redis内存中数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。-.rdb备份文件
（4）
1).子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息。
2).主进程把aof_rewrite_buf中的数据写入到新的AOF文件。
（5）使用新的AOF文件覆盖旧的AOF文件，完成AOF重写。
备份机制更稳健，丢失数据概率更低。
可读的日志文本，通过操作AOF稳健，可以处理误操作。
比起RDB占用更多的磁盘空间。
恢复备份速度要慢。
每次读写都同步的话，有一定的性能压力。
存在个别Bug，造成恢复不能。
官方推荐两个都启用。
如果对数据不敏感，可以选单独用RDB。
不建议单独用 AOF，因为可能会出现Bug。
如果只是做纯内存缓存，可以都不用。
rdb文件,如何替换
1.
关闭所有正在运行的QQ进程.(任务管理器里)
2.
打开QQ的安装目录,如:\Program Files\Tencent\QQ2009\ (这里注意一下,不需要进入Bin目录)
3.
找到Res.rdb文件,将它备份好.
4.
解压下载的替换文件,把Res.rdb复制到QQ安装目录下替换原来的文件.
关于Redis RDB方式数据备份与恢复
Redis RDB方式数据备份与恢复
Redis 数据备份
实例
Redis恢复数据
1、 获取redis备份目录
以上命令 CONFIG GET dir 输出的 redis 备份目录为 /usr/local/redis/bin。
2、 停止redis服务
src是redis安装目录
3、拷贝redis备份文件（dump.rdb）到 /usr/local/redis/bin目录下
4、重新启动redis服务
5、查看是否redis恢复数据
本文来自PHP中文网的 redis教程 栏目：
RDB、AOF持久化及如何优化fork
Redis支持RDB和AOF两种持久化机制 ，持久化功能有效地避免因进程退出造成的数据丢失问题，当下次重启时利用之前持久化的文件即可实现数据恢复。
RDB持久化是把当前进程数据生成快照保存到硬盘的过程，触发RDB持久化过程分为手动触发和自动触发。
手动触发分别对应save和bgsave命令：
◆ (1).save命令
save命令： 阻塞当前Redis服务器，直到RDB过程完成为止，对于内存比较大的实例会造成长时间阻塞，线上环境不建议使用。 运行save命令对应的Redis日志如下：
◆ (2).bgsave命令
bgsave命令Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。 运行bgsave命令对应的Redis日志如下：
RDB相关参数：
RDB启动方式，sava配置
RDB工作过程
RDB的优点：
1.RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的数据快照。非常适用于备份，全量复制等场景。比如每6小时执行bgsave备份，并把RDB文件拷贝到远程机器或者文件系统中（如hdfs），用于灾难恢复。-.rdb备份文件
2.Redis加载RDB恢复数据远远快于AOF的方式。
RDB的缺点：
1.RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高。
2.RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题。针对RDB不适合实时持久化的问题，Redis提供了AOF持久化方式来解决。-.rdb备份文件
● AOF（append only file）持久化： 以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。-.rdb备份文件
● 开启AOF功能需要设置配置： appendonly yes，默认不开启。AOF文件名通过appendfilename配置设置，默认文件名是appendonly.aof。保存路径同RDB持久化方式一致，通过dir配置指定。AOF的工作流程操作：命令写入（append）、文件同步（sync）、文件重写（rewrite）、重启加载（load）。-.rdb备份文件
Redis提供了多种AOF缓冲区同步文件策略，由参数appendfsync控制，appendfsync参数有以下几种设置方式。
随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入AOF重写机制压缩文件体积。AOF文件重写是把Redis进程内的数据转化为写命令同步到新AOF文件的过程。
重写后的AOF文件为什么可以变小？有如下原因：
1）进程内已经超时的数据不再写入文件。
2）旧的AOF文件含有无效命令，如del key1、hdel key2、srem keys、set a111、set a222等。重写使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令。-.rdb备份文件
3）多条写命令可以合并为一个，如：lpush list a、lpush list b、lpush list c可以转化为：lpush list a b c。为了防止单条命令过大造成客户端缓冲区溢出，对于list、set、hash、zset等类型操作，以64个元素为界拆分为多条。-.rdb备份文件
AOF重写过程可以手动触发和自动触发： ·
● 手动触发： 直接调用bgrewriteaof命令。 ·
● 自动触发： 根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。
bgrewriteaof流程如下：
当Redis做RDB或AOF重写时，一个必不可少的操作就是执行fork操作创建子进程，对于大多数操作系统来说fork是个重量级错误。虽然fork创建的子进程不需要拷贝父进程的物理内存空间，但是会复制父进程的空间内存页表。例如对于10GB的Redis进程，需要复制大约20MB的内存页表，因此fork操作耗时跟进程总内存量息息相关，如果使用虚拟化技术，特别是Xen虚拟 机，fork操作会更耗时。-.rdb备份文件
fork耗时问题定位：
对于高流量的Redis实例OPS可达5万以上，如果fork操作耗时在秒级别将拖慢Redis几万条命令执行，对线上应用延迟影响非常明显。正常情况下fork耗时应该是每GB消耗20毫秒左右。可以在info stats统计中查latest_fork_usec指标获取最近一次fork操作耗时，单位微秒。-.rdb备份文件
如何改善fork操作的耗时：
1）优先使用物理机或者高效支持fork操作的虚拟化技术，避免使用Xen。
2）控制Redis实例最大可用内存，fork耗时跟内存量成正比，线上建议每个Redis实例内存控制在10GB以内。
3）合理配置Linux内存分配策略，避免物理内存不足导致fork失败 4）降低fork操作的频率，如适度放宽AOF自动触发时机，避免不必要的全量复制等。
