redis主从复制(replica)
1、是什么？
目录
redis主从复制(replica)
1、是什么？
2、能干嘛？
3、怎么玩？
4、案例演示
前置操作
🍗一主二仆
🍕薪火相传
🌭反客为主
5、复制的原理和工作的核心流程
6、主从复制有哪些缺点
一句话总结：
就是主从复制，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
-
使当前数据库停止和其他数据库的同步，转成主数据库，自立为王。
-
-
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跟
-
-
-
主机shutdown后，从机会上位吗？
-
答案：不会，从机不动，原地待命，从机数据可以正常使用，等待主机重启归来。
-
-
主机shutdown后，重启后主从关系还在吗？从机还能否顺利复制？
-
答案：关系依然在；能复制。
-
-
某台从机down后，master继续，从机重启后还能跟上大部队吗？
-
答案：能
-
方案2：命令操作手动指定
-
从机停机去掉配置文件中的从机配置项，达到3台都是主机状态，个不从属
-
就是把原来的从机一些配置修改
-
-
-
现在就是3台主机master
-
预设的从机上执行以下命令
-
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
-
那每次都要人工干预？
-
正是由于master挂掉了，从机不会自动重选一个主机，紧接着就有了redis哨兵模式
