专栏/我在B站学运维之Redis数据库持久化方与备份、迁移、恢复实践(9)

我在B站学运维之Redis数据库持久化方与备份、迁移、恢复实践(9)

2021年09月18日 08:05--浏览 · --喜欢 · --评论
全栈工程师修炼指南
粉丝：2369文章：145

本章目录:

  • 0x00 数据持久化

    • 1.RDB 方式

    • 2.AOF 方式

    • 如何抉择 RDB OR AOF?

  • 0x01 备份容灾

    • 一、备份

    • 1.手动备份redis数据库

    • 2.迁移Redis指定db-数据库

    • 3.Redis集群数据备份与迁移

    • 二、恢复

    • 1.手动备份redis数据库

    • 2.迁移Redis指定db-数据库

    • 3.Redis集群数据备份与迁移

0x00 数据持久化

描述: Redis 是将数据存储在内存之中所以其读写效率非常高，但是往往事物都不是那么美好，当由于某些不可抗力导致机器宕机、redis服务停止此时您在内存中的数据将完全丢失;

所以为了使 Redis 在异常重启后仍能保证数据不丢失, 我们就需要对其进行设置持久化存储，使其将内存的数据通过某种方式存入磁盘中，当Redis服务端重启后便会从该磁盘中进行读取数据进而恢复Redis中的数据, ;


Redis支持两种持久化方式:

  • (1) RDB 持久化(默认支持): 该机制是指在指定的时间间隔内将内存中数据集写入到磁盘;

  • (2) AOF 持久化: 该机制将以日志的形式记录服务器所处理的每一个写操作，同时在Redis服务器启动之初会读取该文件来重新构建数据库，以保证启动后数据库中的数据完整;

  • (3) 无持久化: 将 Redis 作为一个临时缓存，并将数据存放到之中;

Tips: 为保证数据安全性，我们可以设置 Redis 同时使用RDB和AOF持久化方式，来保证重启后Redis服务器中的数据完整;


1.RDB 方式

描述: Redis 将某一时刻的快照（备份的数据库数据）保存成一种称为RDB格式的文件中，这种格式是经过压缩的二进制文件，数据库的保存和恢复文件如下图所示。

WeiyiGeek.rdb数据


保存RDB数据的两种方式:

  • 1、save命令:save命令会阻塞redis服务器的进程，直到RDB文件创建完，在该期间redis不能处理任何的命令请求，这就是save命令最大的缺陷。

  • 2、bgsave命令:与save命令不同的是 bgsave在生成RDB文件时，会派生出一个子进程，子进程负责创建RDB文件，在此期间，主进程和子进程是同时存在的，因此不会阻塞redis服务器进程。 (推荐方式)

说明:可用查看生成RDB文件是否成功


优势

  • 1.采用子线程创建RDB文件()，不会对redis服务器性能造成大的影响( 性能最大化)；

  • 2.快照生成的RDB文件是一种压缩的二进制文件，可以方便的在网络中传输和保存。通过RDB文件可以方便的将redis数据恢复到某一历史时刻，可以提高数据安全性，避免宕机等意外对数据的影响。

  • 3.适合大规模的数据恢复, RDB的启动恢复效率高。

  • 4.如果业务对数据完整性和一致性要求不高，RDB是很好的选择。


劣势

  • 1.在redis文件在时间点A生成，之后产生了新数据，还未到达另一次生成RDB文件的条件，redis服务器崩溃了，那么在时间点A之后的数据会丢失掉，数据一致性不是完美的好，如果可以接受这部分丢失的数据，可以用生成RDB的方式；

  • 2.快照持久化方法通过调用fork()方法创建子线程。当redis内存的数据量比较大时，创建子线程和生成RDB文件会占用大量的系统资源和处理时间，对 redis处理正常的客户端请求造成较大影响。

  • 3.数据的完整性和一致性不高，因为RDB可能在最后一次备份时宕机了。

  • 4.备份时占用内存，因为Redis 在备份时会独立创建一个子进程，将数据写入到一个临时文件（此时内存中的数据是原来的两倍哦），最后再将临时文件替换之前的备份文件。所以 Redis 的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的。


Q: 通过RDB文件恢复数据?

答: 将dump.rdb 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。在实际开发中，一般会考虑到物理机硬盘损坏情况，选择备份dump.rdb 。


配置说明:

实际案例:


RDB文件恢复数据流程


2.AOF 方式

描述: AOF是redis对将所有的写命令保存到一个aof文件中，根据这些写命令实现数据的持久化和数据恢复。

WeiyiGeek.AOF备份还原


AOF文件生成机制

答: 生成过程包括三个步骤,即。
redis 打开AOF持久化功能之后，redis在执行完一个写命令后，把执行的命令首先追加到redis内部的aof_buf缓冲区膜末尾，此时缓冲区的记录还没有写到Appendonly.aof文件中。然后，缓冲区的写命令会被写入到 AOF 文件，这一过程是文件写入过程。对于操作系统来说，调用write函数并不会立刻将数据写入到硬盘，为了将数据真正写入硬盘，还需要调用fsync函数，调用fsync函数即是文件同步的过程，只有经过了文件的同步过程，写命令才真正的被保存到了AOF文件中。选项 Appendfsync 就是配置同步的频率的。

WeiyiGeek.AOF备份流程


AOF文件重写

  • 1、redis不断的将写命令保存到AOF文件中，导致AOF文件越来越大，当AOF文件体积过大时，数据恢复的时间也是非常长的，因此，redis提供了重写或者说压缩AOF文件的功能。
    比如，AOF重写功能就是干这个事情的。重写时，可以调用BGREWRITEAOF命令重写AOF文件，与新建子线程bgsave命令的工作原理相似。也可以通过配置文件配置什么条件下对AOF文件重写。

  • 2、重写的原理:Redis 会fork出一条新进程，读取内存中的数据，并重新写到一个临时文件中。并没有读取旧文件（太大了）。最后替换旧的aof文件

  • 3、重写触发机制:当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发，这里的“一倍”和“64M” 可以通过配置文件修改


优势

  • 1.该机制可以带来更高的数据安全性，即数据持久化; 常规三种同步策略即每秒同步()、每修改同步()和不同步；

  • 2.由于该机制对日志文件的写入操作采用的是Append模式，即使过程中出现宕机也不会破坏日志文件中已经存在的内容,如果数据不完整在Redis下次启动之前, 通过redis-check-aof解决数据一致性问题;

  • 3.如果日志文件体积过大可以启动rewrite机制，即redis以Append模式不断的将修改数据写到老的磁盘文件中，同时创建新文件记录期间有哪些修改命令执行，此项极大的保证数据的安全性;

  • 4.AOF文件可读性强,其包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作（）

  • 5.数据的完整性和一致性更高


劣势

  • 1.AOF文件比RDB文件较大, 对于相同数量的数据集而言;

  • 2.redis负载较高时，RDB文件比AOF文件具有更好的性能；

  • 3.RDB使用快照的方式持久化整个redis数据，而aof只是追加写命令，因此从理论上来说，RDB比AOF方式更加健壮，另外，官方文档也指出，在某些情况下，AOF的确也存在一些bug，比如使用阻塞命令时，这些bug的场景RDB是不存在的。

  • 4.因为AOF记录的内容多，文件会越来越大，数据恢复也会越来越慢。

  • 5.根据同步策略的不同，AOF在运行效率上往往会慢于RDB,总的来说每秒同步策略的效率还是比较高的


Q: 如何触发AOF快照?

答: 根据配置文件触发，可以是每次执行触发，可以是每秒触发，可以不同步。


Q: 如何根据AOF文件恢复数据?

答: 正常情况下，将Appendonly.aof 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。但在实际开发中，可能因为某些原因导致  文件格式异常，从而导致数据还原失败，可以通过命令进行修复 。

配置说明:


Q: 如何通过AOF文件恢复数据流程?


Tips : 在数据库恢复时把 aof(Append only file) 从中对redis数据库操作的命令，增删改操作的命令，执行了一遍即可。


实际案例:
描述: 用于异步执行一个  文件重写操作, 重写会创建一个当前 AOF 文件的体积优化版本，因为AOF为记录每次的操作会导致实际记录冗杂、使得文件过大，所以需要做重写操作。

重写方式分为以下两种:



如何抉择 RDB OR AOF?

描述: 在实际生产环境中不要仅使用RDB(加载快、不保证数据完整性)或仅使用AOF(加载慢、数据完整性保证)， 所以推荐综合使用AOF和RDB两种持久化机制进行数据备份。

  • AOF 机制保证数据不丢失，并且文件有一定的可读性即可以选择性恢复一部分数据，所以作为数据恢复的第一选择;

  • RDB 机制在AOF文件都丢失或损坏不可用的时候，可以利用其冷备文件来进行快速的数据恢复;


AOF和RDB同时工作特点:

  • 当 rdb 进行 snapshotting 时, redis 便不会再执行 AOF rewrite, 反之则一样。

  • 当 rdb 进行 snapshotting 时, 其它用户也在执行 BGREWRITEAOF 命令, 结果是只有等RDB快照生成之后，才会执行AOF rewrite；

  • 当同时拥有rdb 快照文件和AOF日志文件时, Redis 重启时会优先使用AOF日志进行恢复，。

  • 数据恢复完全依赖于磁盘持久化，如果rdb和aof上都没有数据，数据就无法恢复了。


Tips : 重点再记录、为保证数据容灾建议启用rdb与aof持久化机制，前者保证数据备份而后者保证数据的完整性。
Tips : 重点再记录、当在服务器中同时启用rdb与aof持久化机制时，在redis服务启动时优先加载AOF文件（其数据的完整性）。


合并两个不同实例的数据
描述: 我们可以利用如下方式进行集群多个主节点持久化数据的合并。

(1) AOF 备份合并: 我们说过它实际上是一些列Redis的命令文本。
例如，假设有两台 Redis（6379, 6479），它们的AOF文件名分别为(6379.aof, 6479.aof)，现在要将6379的数据合并到 6479.aof


(2) RDB 备份合并: 注意以下方法可能由于服务端版本不同而有些许差异。
RDB格式如下：头5个字节是字符REDIS,之后4个字节代表版本号，阿里的版本分别是 00 00 00 06,之后2个字节 FE 00，FE是标识 00是数据库，还好我们只有一个库, 最后的结尾9个字节 , FF 加上8个字节的CRC64校验码（实在没空弄，后来偷了一个懒）


Tips : 数据恢复到此结束，此方法只适合用于临时恢复和导出数据，数据完整性不敢保证。

参考地址: https://github.com/sripathikrishnan/redis-rdb-tools/wiki/Redis-RDB-Dump-File-Format

其它工具:

  • https://github.com/leonchen83/redis-rdb-cli/ | 一个可以解析, 过滤, 分割, 合并 rdb 离线内存分析的工具. 也可以在两个redis之前同步数据并允许用户自定义同步服务来把redis数据同步到其他地方.

0x01 备份容灾

一、备份

1.手动备份redis数据库


2.迁移Redis指定db-数据库

方式1.同主机db迁移到另外一个dbn中


方式2.跨主机迁移db



3.Redis集群数据备份与迁移

描述: 当我们需要备份或迁移Redis集群时可以采用以下方案。


Tips: 第三方redis集群数据迁移工具项目参考(https://github.com/alibaba/RedisShake)


二、恢复

1.系统Redis用户被删除后配置数据恢复流程

描述:在系统删除了配置文件后以及用户账号后恢复方法流程，实际环境中建议利用rdb文件进行重新部署。

  • Step1.Redis账户数据恢复首先确定系统中是否还有redis用户。（如果拷贝过来的系统也安装了redis，那么肯定是会有redis账户）

  • Step2.如果发现有redis用户以下步骤可以跳过，否则进行手动添加。

  • Step3.Redis配置文件恢复, Redis的配置文件恢复相对简单一些，官方提供了命令重写redis.conf配置文件。

  • Step4.修改配置文件权限



2.Kubernetes中单实例异常数据迁移恢复实践

方案1.利用其他kubernetes集群进行恢复原k8s集群的redis数据。


命令执行示例:

WeiyiGeek.rdb与aof恢复对比

Tips : 从上述恢复结果可以看出以aof方式恢复的数据比rdb恢复的数据完整，但所加载的时间会随着数据增大会使得AOF方式耗时比rdb耗时更多。


方案2.利用宿主机安装编译redis源码，进行恢复原k8s集群的redis数据


方案3.利用Kubernetes部署的Redis集群，进行恢复原k8s集群的redis数据


3.当Redis集群中出现从节点slave,fail,noaddr问题进行处理恢复流程。

  • Step 1.利用cluster nodes查看你集群状态，发现其中一个从节点异常(是Fail状态)。

  • Step 2.在问题节点上查看节点状态，发现它已脱离集群，且其ID都已发生了变化.

Tips : 若id没发生变化，直接重启下该从节点就能解决。

  • Step 3.但如果ID与Node IP都发生变化时，此时我们需要将该从节点剔出集群

  • Step 4.我们重新将该节点加入集群，此时我们只需要 在集群内任意节点上执行命令加入新节点，握手状态会通过信息在集群内传播，这样其他节点会自动发现新节点并发起握手流程。


  • Step 5.最后检测集群是否恢复正常,执行如下命令即可。

            如果你觉得这个专栏还不错的，请给这篇专栏点个赞、投个币、收个藏，这将对我有很大帮助！          

欢迎各位志同道合的朋友一起学习交流，如文章有误请在下方留下您宝贵的经验知识，个人邮箱地址【master#weiyigeek.top】


文章来源: https://weiyigeek.top 【WeiyiGeek Blog - 为了能到远方，脚下的每一步都不能少】

本文为我原创本文禁止转载或摘编
学习笔记 入门学习 Redis 内存数据库
投诉或建议
目录
--
--
--
2