Redis复制
文章目录
- 1、Redis复制
- 2、Redis复制细节以及基本命令
- 3、Redis主从复制演示
-
- 3.1 一主二从
- 3.2 薪火相传
- 3.3 反客为主
- 4、复制原理和工作流程
- 5、复制的缺点
1、Redis复制
Redis通过复制来支持高可用性和故障转移
Redis主机上所具备的数据将通过复制机制，重新写入到Redis从机上，完成主从备份
一句话：就是主从复制，master以写为主，slave以读为主，当master数据变化的时候，自动将新的数据异步同步到其它slave数据库(可以有多台从机)
Redis复制主要有4个作用
1、读写分离
如果只有一台redis，读写都是它，那么它的负担很重。如果有几台从机，读找从机，写找主机，主机的负担大大减轻，可用性大大提高
2、容灾恢复
即使主机挂了，那么还有从机在，而且数据的同步是实时的，可以用于数据恢复，可以理解为是rdb和aof的延伸
3、数据备份
主机上的所有数据在从机中都有，那么从机上的数据就相当于备份
4、水平扩容支撑高可用
如果一两台从机不够用，那么可以多上几台从机，从而提升高可用
2、Redis复制细节以及基本命令
配置从(库)不配主(库)
当我们有了3台Redis主机后，不可能让3台主机都称为master，否则读写操作在哪台主机上呢？因此我们需要让其中一台为master，另外两台为slave
master主要用来写数据，而slave主要用来读取数据。当master写数据成功之后，它会将数据同步给slave，此时就保证了数据的一致性
权限细节
slave需要在自己的配置文件中写上自己的master是谁，并且需要告知master的密码，才能读取master的数据。假设不需要设置master的密码，那么谁都可以读取master的数据，这是非常不安全的，容易被黑客攻击
master如果配置了requirepass参数，需要密码登陆。那么slave就要配置masterauth来设置校验密码
否则的话master会拒绝slave的访问请求
基本命令
info replication
可以查看复制节点的主从关系和配置信息
replicaof 主库IP 主库端口
一般写入进redis.conf配置文件内，表示slave的master是谁
slaveof 主库IP 主库端口
slave每次与master断开之后，都需要使用该命令重新连接，除非你配置进redis. conf文件
在运行期间修改slave节点的信息，如果该数据库已经是某个主数据库的从数据库，那么会停止和原主数据库的同步关系转而和新的主数据库同步。一句话就是换一个master
slaveof no one
使当前数据库停止与其他数据库的同步，转成主数据库。一句话就是自己称为master
3、Redis主从复制演示
架构说明
一个master两个slave，做一主二从。拷贝多个redis.conf文件，例如：
redis6379.conf
redis6380.conf
redis6381.conf
我这里就用一台云服务即可，如果条件允许，可以用多台云服务器，不过要服务器之间能相互ping通且注意防火墙的配置
** 修改配置文件细节操作**
以redis6379.conf为例，其他配置文件都一样
-
开启daemonize yes
-
注释掉bind 127.0.0.1
-
关闭保护模式protected-mode no
-
指定端口
注意：如果是配置的redis6380.conf或者redis6381.conf，那么这里就是6380或者6381。 -
指定当前工作目录，dir
注意：如果是配置的redis6380.conf或者redis6381.conf，则改为root/myredis/redis6380或者root/myredis/redis6381 -
pid文件名字，pidfile
其他配置文件需要做相应的修改 -
log文件名字，logfile
其他配置文件需要做相应的修改 -
一定要设置密码 requirepass
其他配置文件也需要做相应的修改 -
配置dbfilename的名字
设置为对应的端口号，出现了问题好排查，其他配置文件也需要做相应的修改 -
aof文件，appendfilename
本步骤可选，但非必须，因为我们要演示主从复制，aof可以用也可以不用 -
从机访问主机的通行密码masterauth， 必须-----从机需要配置，主机不需要
上述步骤，三个配置配置文件都需要配置，本步骤只需要配置从机，也就是redis6380.conf和redis6381.conf
经过上述步骤，所有配置文件都已经配置好了
3.1 一主二从
先启动master(端口为6379)，再依次启动slave(端口号为6380和6381)
3台redis分别登录，查看是否有数据，注意登录的时候一定要指明端口，否则都会采用默认端口6379
主从关系日志产看
主机日志(master)
从机日志(slave)
从机6380日志
从机6381日志
但是一般redis中出现错误，我们才查看日志，所以我们可以用命令 info replication查看主从关系
主机：
从机6380：
从机6381：
在主机6379上进行写入操作，在两台从机上查看
主机6379：
从机6380：
从机6381：
主从复制细节问题1：从机可以执行写命令吗？
在从机6380上进行写入操作
答案：不能！！！
主从复制细节问题2：从机切入点问题
slave是从头开始复制还是从切入点开始复制？
从机6381断开
主机6379写入数据
从机6380查看数据
从机6381上线，查看数据
主机6379再次写入数据，查看从机查看数据
结论：slave掉线后重启，会将master中的数据都拷贝过来，之后master写，slave跟着复制(先全量，后增量)
主从复制细节问题3：主机shutdown后，从机是否会上位成为主机
主机6379shutdown
从机6380查看数据是否丢失，查看主从关系
数据并没有丢，自己还是slave
从机6381查看数据是否丢失，查看主从关系
数据并没有丢，自己还是slave
结论：主机掉线，从机不动，原地待命，从机数据可以正常使用，等待主机重启归来
主从复制细节问题4：主机shutdown后，重启后主从关系还在吗?从机还能否顺利复制?
主机6379重启，使用命令 info replication 查看主从关系
插入数据
从机查看数据
结论：主机从新启动，主从关系还在，依旧能进行主从复制
前面的案例都是配置文件固定写死的，除此之外我们可以使用命令操作，手动指定
从机停机去掉配置文件中的配置项，3台目前都是主机状态，各不从属
现在使用命令 slaveof masterIP master端口 连接上主机
主从复制细节问题5：使用命令构建主从关系，从机重启后，关系还在吗？
结论：使用命令构建主从关系，从机重启后，关系不在
如果使用配置，持久稳定。
如果使用命令，只在当前会话生效
3.2 薪火相传
上一个slave可以是下一个slave的master，slave同样可以接收其他slaves的连接和同步请求，那么该slave作为了链条中下一个的master，可以有效减轻主master的写压力
例如从机6381使用命令 slaveof 让主机6380成为它的master
可以看到从机6380还是slave，虽然自己有salve，但自己也有对应的master
在主机6379中插入数据，查看其他从机数据是否同步
数据已同步
此时既是master，又是slave的主机6380能否写数据呢？
答案：不能，只有最上层的master才能进行数据的写入
3.3 反客为主
可以使用命令 slaveof no one 使当前数据库停止和其他数据库进行数据的交互，自立为王，农民翻身把歌唱
从机6381使用命令 slaveof no one
查看从机6380的主从关系
4、复制原理和工作流程
-
slave启动，同步初请
slave启动成功连接到master后会发送一个sync命令
slave首次全新连接master，一次完全同步 (全量复制)将被自动执行，slave自身原有数据会被master数据覆盖清除 -
首次连接，全量复制
master节点收到sync命令后会开始在后台保存快照(即RDB持久化，主从复制时会触发RDB)，同时收集所有接收到的用于修改数据集命令缓存起来，master节点执行RDB持久化完后，master将rdb快照文件和所有缓存的命令发送到所有slave，以完成一次完全同步。而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中，从而完成复制初始化 -
心跳持续，保持通信
主从关系的保持，是需要发心跳包的，每10秒钟发送一次
-
进入平稳，增量复制
master继续将新的所有收集到的修改命令自动依次传给slave，完成同步 -
从机下线，重连续传
master会检查backlog里面的offset，master和slave都会保存一个复制的offset还有一个masterId，offset是保存在backlog中的。master只会把已经复制的offset后面的数据复制给slave，类似断点续传
5、复制的缺点
-
复制延时，信号衰减
由于所有的写操作都是先在master上操作，然后同步更新到slave上，所以从master同步到slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，slave机器数量的增加也会使这个问题更加严重。
-
master挂了怎么办
默认情况下，从机等待，不会再slave节点中自动重选一个master，此时整个redis处于半瘫痪状态，只能读，不能写，只有人工干预，重启master