IT序号网

Redis的复制(Master/Slave)知识解答

shasha 2021年06月13日 数据库 158 0

是什么

复制

在 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机器数量的增加也会使这个问题更加严重。


        


发布评论
IT序号网

微信公众号号:IT虾米 (左侧二维码扫一扫)欢迎添加!

Redis的发布订阅知识解答
你是第一个吃螃蟹的人
发表评论

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。