0 前言
就是主从复制,master以写为主,slave以读为主,当master数据变化的时候,自动将新的数据异步同步到其他的slave数据库。也就是redis主从复制异步同步数据的,所以在主从架构中使用分布式锁时,可能会出现单节点故障,因为master节点把锁信息同步到slave节点这个过程中,宕机了。最终没有完成数据同步,造成了多个线程持有锁,以至于线程不安全,这是后话了。
1.主从复制的功能
1.读写分离;
2.容灾恢复;
3.数据备份;
4.水平扩容支撑高并发;
2. 如何配置主从复制架构
2.1权限配置
master如果配置了requirepass参数,需要密码登录 ,那么slave就要配置masterauth来设置校验密码,否则的话master会拒绝slave的访问请求。
2.2基本操作命令
info replication :可以查看复制结点的主从关系和配置信息
replicaof 主库IP 主库端口 :一般写入进Redis.conf配置文件内,重启后依然生效
slave of 主库IP 主库端口 :每次与master断开之后,都需要重新连接,除非你配置进了redis.conf文件;在运行期间修改slave节点的信息,如果该数据库已经是某个主数据库的从数据库,那么会停止和原主数据库的同步关系 转而和新的主数据库同步,重新拜码头。
slave of no one :使当前数据库停止与其他数据库的同步,
转成主数据库,自立为王
\textcolor{red}{转成主数据库,自立为王}
转成主数据库,自立为王
2.2.1 实操演示
1.架构说明
一个Master两个Slave,三台虚拟机,每台都安装redis。拷贝多个redis.conf文件redis6379.conf、redis6380.conf、redis6381.conf。
2.2.2 配置细节以及注意哪些问题?
三台虚拟机需要能相互ping通且需要注意防火墙配置,如果有防水墙需要配置开放端口,在测试开发测试阶段关闭防火墙也可以。
1.开启daemonize yes。
2.注掉blind 127.0.0.1。
3.修改保护模式protected-mode no;
4.指定端口;
5.指定当前工作目录,dir。
6.pid文件名称,pidfile
7.log文件名称,logfile。
8.requirepass。
9.dump.rdp名称
10.aof文件,appendfilename,本步骤可选。
11.从机访问主机的通行密码masterauth,必须要配置,即在从机的redis配置文件上进行配置,主机不需要配置。
2.2.3 一主二从
1.方案1
配置文件执行:1.replicaof 主库IP 主库端口,具体详情在上一小节中的步骤11中 说明过;2.配从(库)不配(主)库:配置从机;3.先master后两台slave依次启动。4.主从关系查看。
连接成功以后,插卡安主机日志,复制主机数据,如下图所示:
从机日志,如下如所示:
在主机客户端中执行info replication
而在从机中执行,如下所示:
** 从机切入点问题**
1.
s
l
a
v
e
是从头开始复制还是从切入点开始复制
?
\textcolor{blue}{slave是从头开始复制还是从切入点开始复制?}
slave是从头开始复制还是从切入点开始复制? A:master启动,写到k3 slave1跟着master同时启动,跟着写到k3 slave2写到k3后才启动,那之前的是否也可以复制? 首次一次性全量复制到从节点,后续跟随,master写,slave跟随。
主机shutdown后,从机会上位吗?
1.从机不动,原地待命,从机数据可以正常使用,等待主机重启归来。
机shutdown后,重启后主从关系还在吗?从机还能否顺利复制?
1.主从关系依然存在,从机依旧是从机,可以顺利复制。
某台从机down后,master继续,从机重启后它能跟上大部队吗?
1.可以,类似于从机切入点问题。
2.2.4. 方案2:命令操作手动主从关系指令
1.从机停机去掉配置文件中的配置项,3台目前都是主机状态,各不从属。操作时,从机配置注释掉info replication。
2.3台master。
3.预设的从机上执行命令,salveof 主库IP 主库端口。
用命令使用的话,2台从机重启后,关系还在吗?不会存在了。
2.2.5 薪火相传
1.上一个slave可以是下一个slave的master,slave同样可以接收其他slaves的连接和同步请求,那么该slave作为了链条中下一个的master,可以有效减轻主master的写压力
2.中途变更转向:会清除之前的数据,重新建立主从关系并拷贝最新的
3.slaveof 新主库IP 新主库端口
2.2.6 反客为主
slaveof no one 使当前数据库停止与其他数据库的同步关系。
总结
lave启动,同步初请
1.slave启动成功链接到master后会发送一个sync命令。
2.slave首次全新连接master,一次完全同步(全量复制)将被自动执行,slave自身原有数据会被master数据覆盖清除。
首次连接,全量复制
1.master节点收到sync命令后会开始在后台保存快照(即RDB持久化,主从复制时会触发RDB),同时收集所有接收到的用于修改数据集的命令并缓存起来,master节点执行RDB持久化完后,master将RDB快照文件和所有缓存的命令发送到所有slave,以完成一次完全同步。
2.而slave服务在接收到数据库文件数据后,将其存盘并加载到内存中,从而完成复制初始化。
心跳持续,保持通信
repl-ping-replica-period 10
进入平稳,增量复制
master继续将新的所有收集到的修改命令自动依次传送给slave,完成同步。
从机下线,重连续传
master会检查backlog里面的offset,master和slave都会保存一个复制的offset还有一个masterId,offset是保存在backlog中的。 m a s t e r 只会把已经缓存的 o f f s e t 后面的数据复制给 s l a v e ,类似断点续传 \textcolor{red}{master只会把已经缓存的offset后面的数据复制给slave,类似断点续传} master只会把已经缓存的offset后面的数据复制给slave,类似断点续传
复制的缺点
复制延时,信号衰减
由于所有的写操作都是先在Master上操作,然后同步更新到Slave上,所以从Master同步到Slave机器有一定的延迟,当系统很繁忙的时候,延迟问题会更加严重,Slave机器数量的增加也会使这个问题更加严重。
master挂了怎么办?
默认情况下,不会在slave节点中自动选一个master。那每次都要人工干预? 这个是不现实的,无人值守变成刚需,由此引出了我们下一篇文章,Redis哨兵。