[笔记迁移][Redis][7]Redis复制Master/Slave Replication(特别重要!)

版权声明:Collected by Bro_Rabbit only for study https://blog.csdn.net/weixin_38240095/article/details/83350333

一、概述

  1. 官网摘要

    At the base of Redis replication (excluding the high availability features provided as an additional layer by Redis Cluster or Redis Sentinel) there is a very simple to use and configure leader follower (master-slave) replication: it allows slave Redis instances to be exact copies of master instances. The slave will automatically reconnect to the master every time the link breaks, and will attempt to be an exact copy of it regardless of what happens to the master.

  2. 主从复制:主机数据更新之后,根据配置和策略,自动同步到备机的机制。Master以写为主,Slave以读为主。实现了读写分离与容灾恢复。

二、使用

  1. 原则:配从(Slave)不配主(Master)
    从库节点执行slaveof {主库IP} {主库Redis服务端口}。每次与Master断开后,都需要重新连接,除非配置到redis.conf中

  2. 复制多份配置文件并修改
    (1) daemonize yes
    (2) pid文件名
    (3) 指定端口
    (4) log文件名
    (5) dump.db文件名

  3. 常见的节点部署
    (1) “一拖二”——1个Master+2个Slave
    Master
    Slave

    ReadOnly
    注1:无法向从属节点Slave(只读节点READONLY)中置值→读写分离
    MasterOff
    注2:当主节点Master下线后,从属节点Slave仍然保持其之前的身份Slave,不会发生顶替,只是连接断开
    注3:当主节点Master再次上线后,从属节点Slave将“认主”重连,维持原先从属关系继续干活,实现了“半个HA”
    SlaveOff
    注4:当从节点Slave断开并重新上线后,丢失原身份Slave,变为初始状态Master。除非在redis.conf中进行配置,否则需要手动执行SLAVEOF进行重连

    (2)“从属分裂”——去中心化
    Slave‘s slave
    注1:前一个Slave身兼两职,可以是后一个Slave的Master,即Slave同样可以同样接收其他Slaves的链接和同步请求,形成“分裂的链条”,以减轻单个Master的集中程度

    注2:中途变更转向,会清除之前的数据,重新拷贝来自最新链接的数据

    (3)“反客为主”——Slave顶替下线的Master

    注1:选举,手动SLAVEOF no one,3/4个“HA”
    注2:原下线Master重新上线后,不会影响已经形成的新从属关系,“光杆司令”

三、命令

命令 说明
INFO REPLICATION 显示当前节点(实例)的副本信息
SLAVEOF {hostip} {port} 成为{hostip} {port}节点(实例)的从属节点Slave
注:第一次成为某Master的从属节点Slave后,将从主节点Master复制“从一开始到现在的所有数据”。第二次再连该Master,将进行“增量复制”
SLAVEOF no one 主节点Master下线后,执行该命令的从属节点Slave"上位"成为新Master,其他从属节点Slaves需要重新SLAVEOF“认新主”

四、复制原理

Slave成功连接到Master后会发送一个sync指令,Master接收到该命令后启动后台的存盘进程,同时收集所有用户修改数据集的命令。在后台进程执行完毕后,Master将整个数据文件递给Slave以完成一次同步。
全量复制:Slave服务接收到数据文件后,将其存盘并加载到内存中;
增量复制:Master继续将新收集到的所有修改命令依次传递给Slave,完成持续同步
注意,只要重连Master,将自动执行依次全量复制

五、哨兵模式(Sentinel):监控

  1. 监控主节点Master状态以自动“反客为主”进行投票选举(半数以上),实现整个HA
  2. 使用
    (1)在主节点Master的某目录(置于redis.conf同级目录较好)下新建sentinel.conf文件(名字不能错)
    (2)在sentinel.conf文件中添加内容
    	sentinel monitor 被监控Master名字(自定义) {ip} {port} {votes}
    	说明:
    	(1) Master下线后,Slaves投票以选举替换者,得票数多于votes指定将成为主机。如 sentinel monitor abc6379 127.0.0.1 6379 1
    	(2) 一个sentinel能够同时监控多个Master(一行一记录)
    
    (3)启动
    	redis-sentinel /.../sentinel.conf 
    
  3. 若之前Master重启上线,既不会发生"脑裂",也不会变成“光杆司令”,而是成为新Master的Slave

六、缺点——复制延时

由于所有“写操作”都先在Master上进行,再同步更新到Slave,因此传输间会有一定的延迟。当系统繁忙,网络拥堵,Slave层级/数量增多还会加重该问题

猜你喜欢

转载自blog.csdn.net/weixin_38240095/article/details/83350333