redis主从复制详解
大约 8 分钟
redis主从复制详解
redis主从复制(replica)
1、是什么?
一句话总结:
就是主从复制,master以写为主,slave以读为主;当master数据变化的时候,自动将新的数据异步同步到slave数据库。

2、能干嘛?
读写分离
- 写数据找主机
- 读数据找从机
容灾恢复
- 若主机宕机,从机可以起到临时数据访问
数据备份
水平扩容支撑高并发
3、怎么玩?
配从(库)不配主(库)
权限细节,重要
- 主机master如果配置了requirepass参数,需要密码登录,那么从机slave就要配置masterauth来设置校验密码,否则的话主机master会拒接总计salve的访问请求。
基本操作命令
- info replication
- 可以查看复制节点的主从关系和配置信息
- replicaof 主库IP 主库端口
- 一般写入进redis.conf配置文件内
- slaveof 主库IP 主库端口
- 跟上面那个命令作用一样,不过只是临时作用。每次与主机master断开之后,都需要重新连接,除非你已经配置进redis.conf配置文件,在运行期间修改从机salve节点的信息,如果该数据库已经是某个主数据库的从数据库,那么会停止和原主数据库的同步关系转而和新的主数据库同步,重新拜码头。
- slaveof no one
- 使当前数据库停止和其他数据库的同步,转成主数据库,自立为王。
- info replication
4、案例演示
本次案例演示为一主二从架构,来说明以上的理论理解。
前置操作
①、架构说明
- 一个Master两个Slave
- 拷贝多个redis.conf文件

②、小口诀
- 三台redis主机网络相互ping通且注意防火墙配置
- 三大命令
- 主从复制:replicaof 主库IP 主库端口; 配从(库)不配主(库)
- 改换门庭:slaveof 新主库IP 新主库端口
- 自立为王:slaveof no noe
③、修改配置文件细节操作
**❗注意:**主机master的配置文件为redis6379.conf为例,从机的配置基本相同,个别需要修改的下面会说明。
配置细则:
- 开启daemonize yes (redis后台运行配置)
- 注释掉bind 127.0.0.1 (redis远程连接配置)
- protected-mode no (关闭redis安全检测机制)
- 指定端口:注意:redis默认端口是6379,主机master的端口就使用默认端口,从机的相应改成6380和6381两个端口。
- 指定当前工作目录,dir
- pid文件名字,pidfile(本次使用默认配置)
- log文件名字,logfile (方便排查bug)
- requirepass(设置密码为六个1)
- dump.rdb名字
- aof文件,appendfilename(本次使用默认配置)
- 从机访问主机的通行密码masterauth,从机需要配置,主机不用。
❗说明:
- 主机只需配置以上前十步即可。
- 从机需配置全部,并且需要修改端口号,不能使用默认的端口号
- 从机还需配置如下图片参数信息

④、常用3招
经过以上的前置铺垫,终于正式进入主从复制核心重点
- 一主二仆
- 薪火相传
- 反客为主
以这三招为例,一一为你娓娓道来~
🍗一主二仆

方案1:配置文件固定写死
配置文件执行
- replicaof 主库IP 主库端口号
配从库不配主库
- 配置从机6380
- 配置从机6381
先master后两台slave一次启动
主从关系查看
如何查看主从关系是否配置成功呢?
日志
查看主机日志
查看从机日志
命令
info replication命令查看
查看主机
查看从机
经过以上配置,主从配置就已经搭建完成
演示:主机:set k1 v1
从机:get k1
两个从机都可以查到主机设置的k1的值,说明很成功!
主从问题演示
- 1、从机可以执行写命令吗?
- 答案是:不能,从机只能被读
- 2、从机切入点问题
- 从机slave是从头开始复制还是从切入点开始复制?
- 答案:首次一锅端,后续跟随,master写,slave跟
- 从机slave是从头开始复制还是从切入点开始复制?
- 主机shutdown后,从机会上位吗?
- 答案:不会,从机不动,原地待命,从机数据可以正常使用,等待主机重启归来。
- 主机shutdown后,重启后主从关系还在吗?从机还能否顺利复制?
- 答案:关系依然在;能复制。
- 某台从机down后,master继续,从机重启后还能跟上大部队吗?
- 答案:能
方案2:命令操作手动指定
- 从机停机去掉配置文件中的从机配置项,达到3台都是主机状态,个不从属
- 就是把原来的从机一些配置修改
- 就是把原来的从机一些配置修改
- 现在就是3台主机master
- 预设的从机上执行以下命令
- slaveof 主机IP 主机端口号
- 效果就是又变成了从机
- slaveof 主机IP 主机端口号
问题演示
- 使用命令操作的话,2台从机重启后,关系还在吗?
- 答案:关系不存在了,因为命令操作是临时的,只有配置文件操作才是持久的。
总结
配置文件 VS 命令的区别,当堂经验讲解
- 配置文件:持久稳定
- 命令:当此生效
🍕薪火相传

几句话总结就是从机后面再跟从机
- 上一个slave可以是下一个slave的master,ave同样可以接收其他 引aves的连接和同步请求,那么该引ave作为了链条中下一个的master可以有效减轻主master的写压力
- 中途变更转向:会清除之前的数据,重新建立拷贝最新的
- slaveof 新主机IP 新主机端口号
演示
从原来的从机中选一台执行slaveof 新主机IP 新主机端口号此命令,这样原来的主机就只有一个从机跟着,原来的其中一个从机也变成了主机的身份。
**❗注意:**虽然其中一个从机也变成了主机,但是它依然只能被读,不能写,因为它上面有总的一个老大(主机)
🌭反客为主
一句话总结就是从机不想再当从机,想自立为王
操作:使用当前从机执行SLAVEOF no one即可
以上就是主从复制的案例演示
5、复制的原理和工作的核心流程
- slave启动,同步初请
- slave启动成功连接到master后会发送一个sync命令
- slave首次全新连接master,,一次完全同步(全量复制)将被动执行,slave自身原有数据会被master数据覆盖清除
- 首次连接,全量复制
- master节点收到sync命令后会开始在后台保存快照(即RDB持久化,主从复制时会触发RDB), 同时收集所有接收到的用于修改数据集命令缓存起来,master节点执行RDB持久化完后, master将rdb快照文件和所有缓存的命令发送到所有slave,以完成一次完全同步
- 而slave服务在接收到数据库文件数据后,将其存盘并加载到内存中,从而完成复制初始化
- 心跳持续,保持通信
- 主机会发送一个心跳包检测,默认10s发一次问:兄弟们,还在吗,兄弟们,还在吗…..
- 进入平稳,增量复制
- Master继续将新的所有收集到的修改命令自动依次传给slave,完成同步
- 从机下线,重连续传
- master会检查backlog里面的offset,master和slave都会保存一个复制的offset还有一个masterld,offset是保存在backlog中的:Master只会把已经复制的offset后的数据复制给SIave,类似断点续传。
6、主从复制有哪些缺点
- 复制延时,信号衰减
- 由于所有的写操作都是先在Master上操作,然后同步更新到slave上,所以从Master同步到slave机器有一定的延迟,当系统很繁忙的时候,延迟问题会更加严重,slave机器数量的增加也会使这个问题更加严重。
- 由于所有的写操作都是先在Master上操作,然后同步更新到slave上,所以从Master同步到slave机器有一定的延迟,当系统很繁忙的时候,延迟问题会更加严重,slave机器数量的增加也会使这个问题更加严重。
- master挂了如何办?
- 默认情况下,不会在slave节点中自动重选一个master
- 那每次都要人工干预?
正是由于master挂掉了,从机不会自动重选一个主机,紧接着就有了redis哨兵模式