Redis的复制(Master/Slave)

是什么

复制

在 Redis 复制的基础上，使用和配置主从复制非常简单，能使得从 Redis 服务器（下文称 slave）能精确得复制主 Redis 服务器（下文称 master）的内容。每次当 slave 和 master 之间的连接断开时， slave 会自动重连到 master 上，并且无论这期间 master 发生了什么， slave 都将尝试让自身成为 master 的精确副本。

这个系统的运行依靠三个主要的机制：

当一个 master 实例和一个 slave 实例连接正常时， master 会发送一连串的命令流来保持对 slave 的更新，以便于将自身数据集的改变复制给 slave ，：包括客户端的写入、key 的过期或被逐出等等。
当 master 和 slave 之间的连接断开之后，因为网络问题、或者是主从意识到连接超时， slave 重新连接上 master 并会尝试进行部分重同步：这意味着它会尝试只获取在断开连接期间内丢失的命令流。
当无法进行部分重同步时， slave 会请求进行全量重同步。这会涉及到一个更复杂的过程，例如 master 需要创建所有数据的快照，将之发送给 slave ，之后在数据集更改时持续发送命令流到 slave 。

Redis使用默认的异步复制，其特点是低延迟和高性能，是绝大多数 Redis 用例的自然复制模式。但是，从 Redis 服务器会异步地确认其从主 Redis 服务器周期接收到的数据量。

客户端可以使用 WAIT 命令来请求同步复制某些特定的数据。但是，WAIT 命令只能确保在其他 Redis 实例中有指定数量的已确认的副本：在故障转移期间，由于不同原因的故障转移或是由于 Redis 持久性的实际配置，故障转移期间确认的写入操作可能仍然会丢失。你可以查看 Sentinel 或 Redis 集群文档，了解关于高可用性和故障转移的更多信息。本文的其余部分主要描述 Redis 基本复制功能的基本特性。

接下来的是一些关于 Redis 复制的非常重要的事实：

Redis 使用异步复制，slave 和 master 之间异步地确认处理的数据量
一个 master 可以拥有多个 slave
slave 可以接受其他 slave 的连接。除了多个 slave 可以连接到同一个 master 之外， slave 之间也可以像层叠状的结构（cascading-like structure）连接到其他 slave 。自 Redis 4.0 起，所有的 sub-slave 将会从 master 收到完全一样的复制流。
Redis 复制在 master 侧是非阻塞的。这意味着 master 在一个或多个 slave 进行初次同步或者是部分重同步时，可以继续处理查询请求。
复制在 slave 侧大部分也是非阻塞的。当 slave 进行初次同步时，它可以使用旧数据集处理查询请求，假设你在 redis.conf 中配置了让 Redis 这样做的话。否则，你可以配置如果复制流断开， Redis slave 会返回一个 error 给客户端。但是，在初次同步之后，旧数据集必须被删除，同时加载新的数据集。 slave 在这个短暂的时间窗口内（如果数据集很大，会持续较长时间），会阻塞到来的连接请求。自 Redis 4.0 开始，可以配置 Redis 使删除旧数据集的操作在另一个不同的线程中进行，但是，加载新数据集的操作依然需要在主线程中进行并且会阻塞 slave 。
复制既可以被用在可伸缩性，以便只读查询可以有多个 slave 进行（例如 O(N) 复杂度的慢操作可以被下放到 slave ），或者仅用于数据安全。
可以使用复制来避免 master 将全部数据集写入磁盘造成的开销：一种典型的技术是配置你的 master Redis.conf 以避免对磁盘进行持久化，然后连接一个 slave ，其配置为不定期保存或是启用 AOF。但是，这个设置必须小心处理，因为重新启动的 master 程序将从一个空数据集开始：如果一个 slave 试图与它同步，那么这个 slave 也会被清空。

以上摘自官网

行话：也就是我们所说的主从复制，主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主

能干嘛

读写分离
容灾恢复

操作/案例

配从(库)不配主(库)
从库配置：slaveof 主库IP 主库端口
- 每次与master断开之后，都需要重新连接，除非你配置进redis.conf文件
- Info replication
修改配置文件细节操作
- 拷贝多个redis.conf文件

[root@izuf6hmkcpexishpa3id8xz redis-5.0.5]# ls -l
total 272
-rw-rw-r--  1 root root 106874 May 16  2019 00-RELEASENOTES
-rw-rw-r--  1 root root     53 May 16  2019 BUGS
-rw-rw-r--  1 root root   2381 May 16  2019 CONTRIBUTING
-rw-rw-r--  1 root root   1487 May 16  2019 COPYING
drwxrwxr-x  6 root root   4096 Jul 10 16:30 deps
-rw-r--r--  1 root root    162 Jul 14 15:50 dump.rdb
-rw-rw-r--  1 root root     11 May 16  2019 INSTALL
-rw-rw-r--  1 root root    151 May 16  2019 Makefile
-rw-rw-r--  1 root root   6888 May 16  2019 MANIFESTO
-rw-rw-r--  1 root root  20555 May 16  2019 README.md
-rw-rw-r--  1 root root  61797 May 16  2019 redis.conf
-rwxrwxr-x  1 root root    275 May 16  2019 runtest
-rwxrwxr-x  1 root root    280 May 16  2019 runtest-cluster
-rwxrwxr-x  1 root root    341 May 16  2019 runtest-moduleapi
-rwxrwxr-x  1 root root    281 May 16  2019 runtest-sentinel
-rw-rw-r--  1 root root   9710 May 16  2019 sentinel.conf
drwxrwxr-x  3 root root   4096 Jul 10 16:31 src
drwxrwxr-x 11 root root   4096 May 16  2019 tests
drwxrwxr-x  8 root root   4096 May 16  2019 utils
[root@izuf6hmkcpexishpa3id8xz redis-5.0.5]# pwd
/root/redis-5.0.5
[root@izuf6hmkcpexishpa3id8xz redis-5.0.5]# cp redis.conf /r
root/ run/  
[root@izuf6hmkcpexishpa3id8xz redis-5.0.5]# cp redis.conf /root/re
readme.txt          redis-5.0.5/        redis-5.0.5.tar.gz  
[root@izuf6hmkcpexishpa3id8xz redis-5.0.5]# cp redis.conf /root/re
readme.txt          redis-5.0.5/        redis-5.0.5.tar.gz  
[root@izuf6hmkcpexishpa3id8xz redis-5.0.5]# cp redis.conf /root/redis-5.0.5/redis6379.conf 
[root@izuf6hmkcpexishpa3id8xz redis-5.0.5]# cp redis.conf /root/redis-5.0.5/redis6380.conf 
[root@izuf6hmkcpexishpa3id8xz redis-5.0.5]# cp redis.conf /root/redis-5.0.5/redis6381.conf 
[root@izuf6hmkcpexishpa3id8xz redis-5.0.5]# ls -l
total 464
-rw-rw-r--  1 root root 106874 May 16  2019 00-RELEASENOTES
-rw-rw-r--  1 root root     53 May 16  2019 BUGS
-rw-rw-r--  1 root root   2381 May 16  2019 CONTRIBUTING
-rw-rw-r--  1 root root   1487 May 16  2019 COPYING
drwxrwxr-x  6 root root   4096 Jul 10 16:30 deps
-rw-r--r--  1 root root    162 Jul 14 15:50 dump.rdb
-rw-rw-r--  1 root root     11 May 16  2019 INSTALL
-rw-rw-r--  1 root root    151 May 16  2019 Makefile
-rw-rw-r--  1 root root   6888 May 16  2019 MANIFESTO
-rw-rw-r--  1 root root  20555 May 16  2019 README.md
-rw-r--r--  1 root root  61797 Jul 14 16:39 redis6379.conf
-rw-r--r--  1 root root  61797 Jul 14 16:40 redis6380.conf
-rw-r--r--  1 root root  61797 Jul 14 16:40 redis6381.conf
-rw-rw-r--  1 root root  61797 May 16  2019 redis.conf
-rwxrwxr-x  1 root root    275 May 16  2019 runtest
-rwxrwxr-x  1 root root    280 May 16  2019 runtest-cluster
-rwxrwxr-x  1 root root    341 May 16  2019 runtest-moduleapi
-rwxrwxr-x  1 root root    281 May 16  2019 runtest-sentinel
-rw-rw-r--  1 root root   9710 May 16  2019 sentinel.conf
drwxrwxr-x  3 root root   4096 Jul 10 16:31 src
drwxrwxr-x 11 root root   4096 May 16  2019 tests
drwxrwxr-x  8 root root   4096 May 16  2019 utils
[root@izuf6hmkcpexishpa3id8xz redis-5.0.5]#

- 开启daemonize yes

- Pid文件名字
- 指定端口
- Log文件名字

- Dump.rdb名字

常用3招
- 一主二仆
1. Init

　　　　　　2.一个Master两个Slave

　　　　　　3.日志查看

　　　　　　　　主机日志

　　　　　　　　备机日志

　　　　　　　　info replication

　　　　　　4.主从问题演示

1 切入点问题？slave1、slave2是从头开始复制还是从切入点开始复制?比如从k4进来，那之前的123是否也可以复制

2 从机是否可以写？set可否？

3 主机shutdown后情况如何？从机是上位还是原地待命

4 主机又回来了后，主机新增记录，从机还能否顺利复制？

5 其中一台从机down后情况如何？依照原有它能跟上大部队吗？

- 薪火相传
  - 上一个Slave可以是下一个slave的Master，Slave同样可以接收其他
    slaves的连接和同步请求，那么该slave作为了链条中下一个的master,
    可以有效减轻master的写压力
  - 中途变更转向:会清除之前的数据，重新建立拷贝最新的
  - Slaveof 新主库IP 新主库端口
- 反客为主(SLAVEOF no one)
  - 使当前数据库停止与其他数据库的同步，转成主数据库
复制原理
- Slave启动成功连接到master后会发送一个sync命令
- Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，
  在后台进程执行完毕之后，master将传送整个数据文件到slave,以完成一次完全同步
- 全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
- 增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步
- 但是只要是重新连接master,一次完全同步（全量复制)将被自动执行
哨兵模式(sentinel)
- 是什么
  - 反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库
- 使用步骤
  - 调整结构，6379带着80、81
  - 自定义的/myredis目录下新建sentinel.conf文件，名字绝不能错
  - 配置哨兵,填写内容