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文件，名字绝不能错
    • 配置哨兵,填写内容

　　　　　　　　　　1. sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 6379 1

　　　　　　　　　　

 　　　　　　　　　　2.上面最后一个数字1，表示主机挂掉后salve投票看让谁接替成为主机，得票数多少后成为主机

• • • 启动哨兵

　　　　　　　　　　1.Redis-sentinel /myredis/sentinel.conf 

　　　　　　　　　　2.上述目录依照各自的实际情况配置，可能目录不同

• • • 原有的master挂了

　　　　　　　　

• • • 投票新选

　　　　　　　　

• • • 重新主从继续开工,info replication查查看

　　　　　　　　

• • • 问题：如果之前的master重启回来，会不会

　　　　　　　　

• • • 一组sentinel能同时监控多个Master

复制的缺点

• • • 复制延时

　　　　　　　　　　1.由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。