• Redis的主从复制


    主从复制
    主从复制即将master中的数据即时、有效的复制到slave中
    特征:一个master可以拥有多个slave,一个slave只对应一个master
    职责:
      master:
         1) 写数据
         2) 执行写操作时,将出现变化的数据自动同步到slave
         3) 读数据(可忽略)
     slave:
         1) 读数据
         2) 写数据(禁止)
    主从复制的作用

    1. 读写分离: master写、 slave读,提高服务器的读写负载能力
    2. 负载均衡: 基于主从结构,配合读写分离,由slave分担master负载,并根据需求的变化,改变slave的数量,通过多个从节点分担数据读取负载,大大提高Redis服务器并发量与数据吞吐量
    3. 故障恢复:当master出现问题时,由slave提供服务,实现快速的故障恢复
    4. 数据冗余:实现数据热备份,是持久化之外的一种数据冗余方式
    5. 高可用基石: 基于主从复制,构建哨兵模式与集群,实现Redis的高可用方案

    主从复制工作流程 

      从复制过程大体可以分为3个阶段

    • 建立连接阶段(即准备阶段)
    • 数据同步阶段
    • 命令传播阶段

     阶段一:建立连接阶段
    流程:建立slavemaster的连接,使master能够识别slave, 并保存slave端口号

     主从连接( slave连接master)

    方式一:客户端发送命令

    slaveof <masterip> <masterport>

    方式二:启动服务器参数

    redis-server -slaveof <masterip> <masterport>

    方式三:服务器配置

    slaveof <masterip> <masterp

    如下面演示,在客户端执行主从连接命令

    [root@iZbp143t3oxhfc3ar7jey0Z redis-4.0.12]# redis-server redis.conf
    26260:C 07 Apr 10:15:24.212 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
    26260:C 07 Apr 10:15:24.212 # Redis version=4.0.12, bits=64, commit=00000000, modified=0, pid=26260, just started
    26260:C 07 Apr 10:15:24.212 # Configuration loaded
                    _._
               _.-``__ ''-._
          _.-``    `.  `_.  ''-._           Redis 4.0.12 (00000000/0) 64 bit
      .-`` .-```.  ```/    _.,_ ''-._
     (    '      ,       .-`  | `,    )     Running in standalone mode
     |`-._`-...-` __...-.``-._|'` _.-'|     Port: 6379
     |    `-._   `._    /     _.-'    |     PID: 26260
      `-._    `-._  `-./  _.-'    _.-'
     |`-._`-._    `-.__.-'    _.-'_.-'|
     |    `-._`-._        _.-'_.-'    |           http://redis.io
      `-._    `-._`-.__.-'_.-'    _.-'
     |`-._`-._    `-.__.-'    _.-'_.-'|
     |    `-._`-._        _.-'_.-'    |
      `-._    `-._`-.__.-'_.-'    _.-'
          `-._    `-.__.-'    _.-'
              `-._        _.-'
                  `-.__.-'
    
    26260:M 07 Apr 10:15:24.215 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
    26260:M 07 Apr 10:15:24.215 # Server initialized
    26260:M 07 Apr 10:15:24.215 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
    26260:M 07 Apr 10:15:24.215 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.
    26260:M 07 Apr 10:15:24.215 * Ready to accept connections
    26260:M 07 Apr 10:30:33.003 * Slave 127.0.0.1:6380 asks for synchronization
    26260:M 07 Apr 10:30:33.003 * Partial resynchronization not accepted: Replication ID mismatch (Slave asked for '83c02182bfec39697066ab7cc9faa14603dc6ee9', my replication IDs are 'a950489a53d4fbfc41834ef633c8a59e95bca4c1' and '0000000000000000000000000000000000000000')
    26260:M 07 Apr 10:30:33.003 * Starting BGSAVE for SYNC with target: disk
    26260:M 07 Apr 10:30:33.005 * Background saving started by pid 26728
    26728:C 07 Apr 10:30:33.009 * DB saved on disk
    26728:C 07 Apr 10:30:33.503 * RDB: 6 MB of memory used by copy-on-write
    26260:M 07 Apr 10:30:33.603 * Background saving terminated with success
    26260:M 07 Apr 10:30:33.603 * Synchronization with slave 127.0.0.1:6380 succeeded
    26260:M 07 Apr 10:45:34.001 * 1 changes in 900 seconds. Saving...
    26260:M 07 Apr 10:45:34.001 * Background saving started by pid 28986
    28986:C 07 Apr 10:45:34.008 * DB saved on disk
    28986:C 07 Apr 10:45:34.008 * RDB: 2 MB of memory used by copy-on-write

    从节点:

    [root@iZbp143t3oxhfc3ar7jey0Z redis-4.0.12]# redis-server redis-6380.conf
    26434:C 07 Apr 10:20:41.532 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
    26434:C 07 Apr 10:20:41.532 # Redis version=4.0.12, bits=64, commit=00000000, modified=0, pid=26434, just started
    26434:C 07 Apr 10:20:41.532 # Configuration loaded
                    _._
               _.-``__ ''-._
          _.-``    `.  `_.  ''-._           Redis 4.0.12 (00000000/0) 64 bit
      .-`` .-```.  ```/    _.,_ ''-._
     (    '      ,       .-`  | `,    )     Running in standalone mode
     |`-._`-...-` __...-.``-._|'` _.-'|     Port: 6380
     |    `-._   `._    /     _.-'    |     PID: 26434
      `-._    `-._  `-./  _.-'    _.-'
     |`-._`-._    `-.__.-'    _.-'_.-'|
     |    `-._`-._        _.-'_.-'    |           http://redis.io
      `-._    `-._`-.__.-'_.-'    _.-'
     |`-._`-._    `-.__.-'    _.-'_.-'|
     |    `-._`-._        _.-'_.-'    |
      `-._    `-._`-.__.-'_.-'    _.-'
          `-._    `-.__.-'    _.-'
              `-._        _.-'
                  `-.__.-'
    
    26434:M 07 Apr 10:20:41.534 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
    26434:M 07 Apr 10:20:41.534 # Server initialized
    26434:M 07 Apr 10:20:41.534 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
    26434:M 07 Apr 10:20:41.534 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.
    26434:M 07 Apr 10:20:41.534 * Ready to accept connections
    26434:S 07 Apr 10:30:31.644 * Before turning into a slave, using my master parameters to synthesize a cached master: I may be able to synchronize with the new master with just a partial transfer.
    26434:S 07 Apr 10:30:31.644 * SLAVE OF 127.0.0.1:6379 enabled (user request from 'id=3 addr=127.0.0.1:34200 fd=9 name= age=525 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=slaveof')
    26434:S 07 Apr 10:30:33.003 * Connecting to MASTER 127.0.0.1:6379
    26434:S 07 Apr 10:30:33.003 * MASTER <-> SLAVE sync started
    26434:S 07 Apr 10:30:33.003 * Non blocking connect for SYNC fired the event.
    26434:S 07 Apr 10:30:33.003 * Master replied to PING, replication can continue...
    26434:S 07 Apr 10:30:33.003 * Trying a partial resynchronization (request 83c02182bfec39697066ab7cc9faa14603dc6ee9:1).
    26434:S 07 Apr 10:30:33.006 * Full resync from master: 75f06abf1e9772f269eace1095fd8ed8726ecfaa:0
    26434:S 07 Apr 10:30:33.006 * Discarding previously cached master state.
    26434:S 07 Apr 10:30:33.603 * MASTER <-> SLAVE sync: receiving 176 bytes from master
    26434:S 07 Apr 10:30:33.603 * MASTER <-> SLAVE sync: Flushing old data
    26434:S 07 Apr 10:30:33.604 * MASTER <-> SLAVE sync: Loading DB in memory
    26434:S 07 Apr 10:30:33.604 * MASTER <-> SLAVE sync: Finished with success
    26434:S 07 Apr 10:30:33.605 * Background append only file rewriting started by pid 26729
    26434:S 07 Apr 10:30:33.628 * AOF rewrite child asks to stop sending diffs.
    26729:C 07 Apr 10:30:33.628 * Parent agreed to stop sending diffs. Finalizing AOF...
    26729:C 07 Apr 10:30:33.628 * Concatenating 0.00 MB of AOF diff received from parent.
    26729:C 07 Apr 10:30:33.629 * SYNC append only file rewrite performed
    26729:C 07 Apr 10:30:33.629 * AOF rewrite: 0 MB of memory used by copy-on-write
    26434:S 07 Apr 10:30:33.703 * Background AOF rewrite terminated with success
    26434:S 07 Apr 10:30:33.703 * Residual parent diff successfully flushed to the r                                                                                     ewritten AOF (0.00 MB)
    26434:S 07 Apr 10:30:33.703 * Background AOF rewrite finished successfully
    26434:S 07 Apr 10:35:42.001 * 1 changes in 900 seconds. Saving...
    26434:S 07 Apr 10:35:42.001 * Background saving started by pid 28699
    28699:C 07 Apr 10:35:42.004 * DB saved on disk
    28699:C 07 Apr 10:35:42.005 * RDB: 0 MB of memory used by copy-on-write
    26434:S 07 Apr 10:35:42.499 * Background saving terminated with success

    主从客户端

    [root@iZbp143t3oxhfc3ar7jey0Z ~]#  redis-cli -p 6380
    127.0.0.1:6380> keys *
    (empty list or set)
    127.0.0.1:6380> SLAVEOF 127.0.0.1 6379
    OK
    127.0.0.1:6380> keys *
    (empty list or set)
    127.0.0.1:6380> get name
    "wgr"
    [root@iZbp143t3oxhfc3ar7jey0Z ~]# redis-cli
    127.0.0.1:6379> set name wgr
    OK

     主从断开连接 

    slaveof no one

     注意:slave断开连接后,不会删除已有数据,只是不再接受master发送的数据

     授权访问:

     阶段二:数据同步阶段工作流程

    •  slave初次连接master后,复制master中的所有数据到slave
    • slave的数据库状态更新成master当前的数据库状态

     

     数据同步阶段master说明

    •  如果master数据量巨大,数据同步阶段应避开流量高峰期,避免造成master阻塞,影响业务正常执行
    • 复制缓冲区大小设定不合理,会导致数据溢出。如进行全量复制周期太长,进行部分复制时发现数据已经存在丢失的情况,必须进行第二次全量复制,致使slave陷入死循环状态 repl-backlog-size 1mb
    • master单机内存占用主机内存的比例不应过大,建议使用50%-70%的内存,留下30%-50%的内存用于执行bgsave命令和创建复制缓冲区

    数据同步阶段slave说明

    1. 为避免slave进行全量复制、部分复制时服务器响应阻塞或数据不同步,建议关闭此期间的对外服务 【slave-serve-stale-data yes|no
    2. 数据同步阶段, master发送给slave信息可以理解master是slave的一个客户端,主动向slave发送命令
    3. 多个slave同时对master请求数据同步, master发送的RDB文件增多, 会对带宽造成巨大冲击, 如果master带宽不足, 因此数据同步需要根据业务需求, 适量错峰
    4. slave过多时, 建议调整拓扑结构,由一主多从结构变为树状结构, 中间的节点既是master,也是slave。注意使用树状结构时,由于层级深度,导致深度越高的slave与最顶层master间数据同步延迟较大, 数据一致性变差, 应谨慎选择

    阶段三:命令传播阶段

    • 当master数据库状态被修改后,导致主从服务器数据库状态不一致,此时需要让主从数据同步到一致的状态,同步的动作称为命令传播
    • master将接收到的数据变更命令发送给slave, slave接收命令后执行命令

     注:如果命令传播阶段出现了断网现象

    • 网络闪断闪连             可以忽略
    • 短时间网络中断         部分复制
    • 长时间网络中断         全量复制

    部分复制的三个核心要素
       服务器的运行 id( run id)
       主服务器的复制积压缓冲区
       主从服务器的复制偏移量 

    服务器运行ID( runid)
       概念:服务器运行ID是每一台服务器每次运行的身份识别码,一台服务器多次运行可以生成多个运行id
       组成:运行id由40位字符组成,是一个随机的十六进制字符

      作用:运行id被用于在服务器间进行传输,识别身份如果想两次操作均对同一台服务器进行,必须每次操作携带对应的运行id,用于对方识别
      实现方式: 运行id在每台服务器启动时自动生成的, master在首次连接slave时,会将自己的运行ID发送给slave, slave保存此ID,通过info Server命令,可以查看节点的runid
    复制缓冲区
    概念:复制缓冲区,又名复制积压缓冲区,是一个先进先出( FIFO)的队列, 用于存储服务器执行过的命令, 每次传播命令, master都会将传播的命令记录下来, 并存储在复制缓冲区
               复制缓冲区默认数据存储空间大小是1M,由于存储空间大小是固定的,当入队元素的数量大于队列长度时,最先入队的元素会被弹出,而新元素会被放入队列
    由来:每台服务器启动时,如果开启有AOF或被连接成为master节点, 即创建复制缓冲区
    作用:用于保存master收到的所有指令(仅影响数据变更的指令,例如set, select)
    数据来源:当master接收到主客户端的指令时,除了将指令执行,会将该指令存储到缓冲区中

    主从服务器复制偏移量( offset)

    • 概念:一个数字,描述复制缓冲区中的指令字节位置
    • 分类: 1)master复制偏移量:记录发送给所有slave的指令字节对应的位置(多个)2) slave复制偏移量:记录slave接收master发送过来的指令字节对应的位置(一个)
    • 数据来源:master端:1)发送一次记录一次  2)slave端:接收一次记录一次
    • 作用:同步信息,比对master与slave的差异,当slave断线后,恢复数据使用

    心跳机制
    进入命令传播阶段候, master与slave间需要进行信息交换,使用心跳机制进行维护,实现双方连接保持在线
    master心跳:

    • 指令: PING
    • 周期:由repl-ping-slave-period决定,默认10秒
    • 作用:判断slave是否在线
    • 查询: INFO replication 获取slave最后一次连接时间间隔, lag项维持在0或1视为正常

    slave心跳任务

    • 指令: REPLCONF ACK {offset}
    • 周期: 1秒
    • 作用1:汇报slave自己的复制偏移量,获取最新的数据变更指令
    • 作用2:判断master是否在线

     

  • 相关阅读:
    动态规划-矩阵链乘法
    钢条切割问题
    代码着色
    Sublime配置C和C++编译运行环境
    Guava中集合类的简单实用
    Junit单元测试入门
    Sublime Text 快捷键
    Editplus 的配色方案
    利用Wireshark任意获取QQ好友IP实施精准定位
    linux下实现定时执行php脚本
  • 原文地址:https://www.cnblogs.com/dalianpai/p/12652809.html
Copyright © 2020-2023  润新知