redis修改配置文件立即生效_NoSQL，从Redis开始（二）

上篇回顾：NoSQL，从Redis开始(一)

一、RDB持久化

RDB持久化是把当前进程数据生成快照保存到硬盘的过程。

1、手动触发

• Save：阻塞当前redis进程，直到rdb过程完成。线上不建议使用，并且后续版本已废弃。

• Bgsave：fork子进程负责rdb持久化，完成后自动结束。

2、自动触发

• 使用save相关配置，如“save m n”,表示m秒内数据集存在n次修改时，自动触发bgsave。

• 从节点全量复制时，主节点自动执行bgsave生成rdb文件并发送给从节点。

• debug reload时，也会自动触发save操作。

• shutdown且没有aof持续化功能时，自动执行bgsave。

3、RDB命令

1)备份

bgsave

2)关闭redis

systemctl stop redis

3)恢复(重新开启redis)

systemctl start redis

4、RDB流程

1)备份流程

• 我们使用bgsave命令，redis父进程判断是否有正在执行的子进程，如果存在子进程，则直接返回。

• 父进程fork一个bgsave的子进程，fork操作过程中父进程会有短暂的阻塞。Fork完成后，父进程不再阻塞并且返回“Background savingstarted”信息，此时可以响应其他命令。

• 子进程创建rdb文件，根据父进程内存生产临时快照文件，完成后对原文件进行替换。然后发送信号给父进程表示完成，父进程更新统计信息。

• 具体流程如下图所示：

2)恢复流程

• 关闭redis，把你备份的rdb文件移到redis默认生成rdb文件的文件夹中。

• 启动redis，redis就会恢复rdb中的数据。

5、RDB的优缺点

• 优点：rdb是一个压缩的二进制文件，代表redis在某个时间点上的数据快照。数据恢复速度远远快于aof方式。

• 缺点：没办法做到秒级持久化，因为bgsave每次执行都要执行fork创建子进程，频繁操作成本过高。Rdb格式过多，老版本redis服务无法兼容新版本rdb格式。

二、AOF持久化

Aof，append only file，以日志的方式记录每次写命令(个人感觉有点像mysql中的binlog日志)。

1、配置文件

1)修改redis.conf配置文件

把appendonly参数的值改成yes

2)配置文件的热修改

config set appendonly yes

2、默认流程

1)      所有的写入命令会追加到aof_buf(缓冲区)中。

2)     AOF缓冲区根据对应的策略向硬盘做同步操作。

3)     随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。

4)     当Redis服务器重启时，可以加载AOF文件进行数据恢复。

三、持久化注意点

1、备份数据从rdb文件转移到aof文件

如果之前是使用rdb方式备份的，那么配置文件中的appendonly参数就是no(表示aof备份是关闭的)。这种情况下，如果想把rdb文件中已有的数据转到aof文件中，直接关闭redis并修改配置文件中的appendonly参数是行不通的：

关闭redis——》自动bgsave内存数据到rdb——》修改配置参数appendonly——》开启redis。(整个流程，没有任何一步会把内存的数据写入aof中，所以以前的数据就丢失了)

解决方案：

配置参数的热修改，appendonly的参数改为yes。(在不关闭redis的情况下，该备份方式为aof，会自动把数据从内存写入aof文件)

2、备份数据从aof文件转移到rdb文件

原理同上，不再赘述。配置参数的热修改，appendonly的参数改为no。

3、主从分离也要对数据进行持久化

不能因为redis做成高可用，就不开启持久化了。我们知道，开启主从分离时，主承担写操作，从承担读操作。slave的数据就是从master上同步过来的，slave承担master的数据热备。但是，如果master宕机了，master内存中的数据全部清空了，slave同步master也会把数据清空。所以，主从分离这些高可用也是需要做持久化的。

四、主从复制

1、复制方式

1)建立复制

• 在配置文件中加入slaveof{masterHost}{masterPort}随Redis启动生效。

• 在redis-server启动命令后加入--slaveof{masterHost}{masterPort}生效。

• 客户端直接使用命令：slaveof{masterHost}{masterPort}生效。

2)断开复制

l  关闭redis服务器，注释掉slaveof参数，重启redis服务器生效。

l  客户端直接使用命令：slaveof no one生效。

2、复制结构

1)一主一从

2)一主多从

3)树形结构

3、复制流程

• 1. 从节点向主节点发送PSYNC命令。

• 2. 收到PSYNC命令的主节点执行BGSAVE命令，在后台生成一个RDB文件，并使用一个缓冲区记录从现在开始执行的所有写命令。

• 3. 当主节点的BGSAVE命令执行完毕时，主节点会将BGSAVE命令生成的RDB文件发送给从节点，从节点接受并载入这个RDB文件，将自己的数据库状态更新至主节点执行BGSAVE命令时的数据库状态。

• 4. 主节点将记录在缓冲区里面的所有写命令发送给从节点，从节点执行这些写命令，将自己的数据库状态更新至主节点数据库当前所处的状态。

4、实际操作

1)复制配置文件

mkdir -p /etc/redis_slave1  mkdir -p /etc/redis_slave2  cp -a /etc/redis.conf /etc/redis_slave1  cp -a /etc/redis.conf /etc/redis_slave2

2)修改配置文件

3)启动两个从库

/usr/bin/redis-server /etc/redis_slave1/redis.conf  /usr/bin/redis-server /etc/redis_slave2/redis.conf  

 

了解新钛云服

新钛云服与AWS联合举办的“混合云与云治理专家研讨会”圆满结束！

新钛云服正式获批工信部ISP/IDC(含互联网资源协作)牌照

深耕专业，矗立鳌头，新钛云服获千万Pre-A轮融资

原电讯盈科中国区副总裁加入新钛云服「附专访」

新钛云服，打造最专业的Cloud MSP+，做企业业务和云之间的桥梁

新钛云服一周年，完成两轮融资，服务五十多家客户

上海某仓储物流电子商务公司混合云解决方案

新钛云服出品的部分精品技术干货

万字长文：云架构设计原则|附PDF下载

如何将业务迁移到AWS上

AWS S3六项存储类别详解，从成本到访问频率

AWS EC2的价格模型

Ceph OSD故障排除|万字经验总结

七个用于Docker和Kubernetes防护的安全工具

维人的终身成长，从清单管理开始|万字长文！

什么是云原生？

IT混合云战略：是什么、为什么，如何构建？