Redis-3 持久化以及主从复制

        redis持久化的文件分为两种：

        dump.rdb  和  appendonly.aof

一、Redis持久化之 RDB

Redis 提供了 2 个不同形式的持久化方式

RDB（Redis DataBase）

AOF（Append Of File）

1、RDB 是什么

在指定的时间间隔内将内存中的数据集快照写入磁盘， 也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里

2. 备份是如何执行的

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

3.Fork

Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程

4. RDB持久化流程

5. dump.rdb文件

在redis.conf中配置文件名称，默认为dump.rdb

文件在哪里启动这个文件就在哪里

6. 配置位置

rdb文件的保存路径，也可以修改。默认为Redis启动时命令行所在的目录下

redis.conf：

7. 如何触发RDB快照；保持策略

7.1 配置文件中默认的快照配置时间间隔

7.2 命令save bgsave

save ：save时只管保存，其它不管，全部阻塞。手动保存。不建议。

bgsave：Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。

可以通过lastsave 命令获取最后一次成功执行快照的时间

7.3 flushall命令

执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义

7.4 SNAPSHOTTING快照

7.5. Save

格式：save 秒 写操作次数

RDB是整个内存的压缩过的Snapshot，RDB的数据结构，可以配置复合的快照触发条件，

默认是1分钟内改了1万次，或5分钟内改了10次，或15分钟内改了1次。

禁用

不设置save指令，或者给save传入空字符串

7.6. stop-writes-on-bgsave-error

当Redis无法写入磁盘的话(磁盘已满)，直接关掉Redis的写操作。推荐yes.

7.7 rdbcompression 压缩文件

对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会进行压缩。

如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能。推荐yes.

7.8. rdbchecksum 检查数据的完整性

在存储快照后，还可以让redis来进行数据校验，如果数据已经损坏就不需要再进行持久化的操作，这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能

推荐yes.

7.9. rdb的备份

先查询rdb文件的目录

创建备份文件 mkdir dump-bak.rdb

把备份的文件拷贝到工作目录下 cp dump-bak.rdb dump.rdb

关闭Redis

然后移除 dump.rdb       mv -rf dump.rdb

rdb的恢复

进入myredis     删除原本的  dump.rdb

然后复制 dump-bak.rdb    cp dump-bak.rdb dump.rdb

启动Redis, 备份数据会直接加载

打开客户端

7.10. 优势

适合大规模的数据恢复

对数据完整性和一致性要求不高更适合使用

节省磁盘空间

恢复速度快

7.11 劣势

Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。

在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。

二 Redis持久化之AOF

2.1. AOF（Append Only File）

2.1.1. 是什么

以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

2.1.2. AOF持久化流程  （会背）

（1）客户端的请求写命令会被append追加到AOF缓冲区内；

（2）AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；

（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；

（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；

2.1.3. AOF默认不开启 --------》 改为开启状态

可以在redis.conf中配置文件名称，默认为 appendonly.aof

AOF文件的保存路径，同RDB的路径一致。

aof  保存的策略（电脑性能好的话，改为） 一直开启

不能选择  no

2.1.4. AOF和RDB同时开启，redis听谁的？

AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失）

2.1.5. AOF修复/恢复

如遇到AOF文件损坏，通过

/usr/redis/bin/redis-check-aof --fix 文件的位置/appendonly.aof进行恢复

备份被写坏的AOF文件

恢复：重启redis，然后重新加载

 ./redis-check-aof --fix ./myredis/appendonly.aof     （aof文件的位置）

重写文件的大小

第一次:64m  rewrite ->50m   50+50*100%=100

第二次: 100m

第三次: 200m

触发机制，何时重写

Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发

重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定Redis要满足一定条件才会进行重写。

auto-aof-rewrite-percentage：设置重写的基准值，文件达到100%时开始重写（文件是原来重写后文件的2倍时触发）

->40m 80

auto-aof-rewrite-min-size：设置重写的基准值，最小文件64MB。达到这个值开始重写。

3、重写流程（背）

（1）bgrewriteaof触发重写，判断是否当前有bgsave或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行。

（2）主进程fork出子进程执行重写操作，保证主进程不会阻塞。

（3）子进程遍历redis内存中数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。

（4）1).子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息。2).主进程把aof_rewrite_buf中的数据写入到新的AOF文件。

（5）使用新的AOF文件覆盖旧的AOF文件，完成AOF重写。

3.1、 优势

3.2、劣势

• 比起RDB占用更多的磁盘空间。
• 恢复备份速度要慢。
• 每次读写都同步的话，有一定的性能压力。
• 存在个别Bug，造成恢复不能。

3.3、 用哪个好

官方推荐两个都启用。

如果对数据不敏感，可以选单独用RDB。

不建议单独用 AOF，因为可能会出现Bug。

如果只是做纯内存缓存，可以都不用。

三 主从复制

3.1. 是什么

主机数据更新后根据配置和策略， 自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主

3.2. 能干嘛

读写分离，性能扩展（主 写 从 读）

容灾快速恢复

3.3 主从复制

一主二仆

6380 主

6381 从

6382 从

拷贝多个redis.conf文件include(写绝对路径)

开启daemonize yes

Pid文件名字pidfile

指定端口port

Log文件名字

dump.rdb名字dbfilename

Appendonly 改为no

注意：不能设置密码

主机配置的文件  redis.conf

include /usr/redis/bin/redis.conf

port 6380

dbfilename dump_6380.rdb

appendfilename "appendonly_6380.aof"

pidfile /var/run/redis_6380.pid

daemonize yes

查看三台服务器的运行情况

连接客户端 ：./redis-cli -p 6380    （6381/6382）

查看运行 状态：info replication

三台全部都是主机

配从

主机不需要配置

6380 主    81   82 从

slaveof <ip><port>

成为某个实例的从服务器

1.在6381和6382上执行: slaveof 127.0.0.1 6380

主机数据

从机数据

2.在主机上写，在从机上可以读取数据

3.主机挂掉，重启就行，一切如初

4.从机重启需重设：slaveof 127.0.0.1 6379

（主机宕机  重启即可   一切恢复。从机宕机 重新设置对应主机是谁）

复制原理

• Slave启动成功连接到master后会发送一个sync命令
• Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令， 在后台进程执行完毕之后，master将传送整个数据文件到slave,以完成一次完全同步
• 全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
• 增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步
• 但是只要是重新连接master,一次完全同步（全量复制)将被自动执行

薪火相传

上一个Slave可以是下一个slave的Master，Slave同样可以接收其他 slaves的连接和同步请求，那么该slave作为了链条中下一个的master, 可以有效减轻master的写压力,去中心化降低风险。

用 slaveof <ip><port>

中途变更转向:会清除之前的数据，重新建立拷贝最新的

风险是一旦某个slave宕机，后面的slave都没法备份

主机挂了，从机还是从机，无法写数据了

反客为主

当一个master宕机后，后面的slave可以立刻升为master，其后面的slave不用做任何修改。

用 slaveof no one 将从机变为主机。

手动版

哨兵模式(sentinel)

反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库

调整为一主二仆模式，6379带着6380、6381

自定义的/myredis目录下新建sentinel.conf文件，名字绝不能错

80

配置哨兵,填写内容

sentinel monitor mymaster 127.0.0.1 6380 1

其中mymaster为监控对象起的服务器名称， 1 为至少有多少个哨兵同意迁移的数量。

启动哨兵

执行 ./redis-sentinel sentinel.conf 

启动之后的  sentinel.conf

检测是否成功，把主机6380 关掉，从机选举中产生新的主机

(大概10秒左右可以看到哨兵窗口日志，切换了新的主机)

哪个从机会被选举为主机呢？根据优先级别：replica-priority

1. replica-priority ： 100 越小优先级越高
2. 偏移量: 拿到主机的数据比较全
3. Runid ： redis自动生成的40 的uuid 小的

原主机重启后会变为从机。

领导 （主）

储备干部 员工

优先级在redis.conf中默认：replica-priority 100，值越小优先级越高

偏移量是指获得原主机数据最全的

每个redis实例启动后都会随机生成一个40位的runid