一、课程目录
- 什么是主从复制
- 全量复制和部分复制
- 复制的配置
- 故障处理
- 开发运维常见问题
二、什么是主从复制
一主一从
主从复制的作用:
- 数据副本
- 扩展读性能
【总结】
- 一个master可以有多个slave
- 一个slave只能有一个master
- 数据流向是单向的,master到slave
三、 runid和复制偏移量
每个redis在启动的时候都会有一个随机地runid,来表示redis的标志
四、全量复制
全量复制过程:
- 【步骤一】如果设置了一个Slave,无论是第一次连接还是重连到Master,它都会发出一个PSYNC命令‘
- 【步骤二】当Master收到SYNC命令手,会做两个事情:
- Master执行BGSAVE,即在后台保存数据到磁盘(RDB快照文件)
- Master同时将新收到的写入和修改数据集的命令存入缓冲区(非查询类)
- 【步骤三】当Master在后台把数据保存到快照文件完成之后,Master会把这个快照文件传送给Slave,而Slave则把内存清空后,加载该文件到内存中
- 【步骤四】而Master/Slave此后会不断通过异步的方式进行命令的同步,达到最终的数据同步一致
先将RDB文件同步给slave,然后在同步RDB期间,再有向master中写入的数据就单独记录下来,然后当RDB复制完后,观察master和slave的偏移量。
在全量复制的时候,如果发生了网络抖动,那么连接可能会发生断开。
部分复制的过程
- 【步骤一】当Master和Slave之间的连接断开之后,他们之间可以采用持续复制处理方式代替采用全量同步
- 【步骤二】Master端为复制刘维护一个内存缓冲区,记录最近发送的复制流命令;同时,Master和Slave之间都维护一个复制偏移量(replication offset)和当前Master服务器ID(Master run id)。当网络断开,Slave尝试重连时:
- 如果MasterID相同(即仍是断网前的Master服务器),并且从断开时到当前时刻的历史命令依然在Master的内存缓存区中存在,则Master会将缺失的这段时间的所有命令发送给Slave执行,然后复制工作就可以继续执行了。
- 否则,依然需要全量复制操作。
五、故障处理
当出现故障的时候,我们希望故障可以自动转移。
六、主从复制常见问题
- 读写分离:读流量分摊到从节点
- 可能遇到问题
- 复制数据延迟
- 读到过期数据
- 从节点故障
6.2 配置不一致
- 例如maxmemory不一致:丢失数据
6.3 规避全量复制
-
第一次全量复制
- 第一次不可避免
- 小主节点:即maxmemory不要设置的过大。低峰:在用户比较少的时候,比如夜间
-
节点运行ID不匹配
- 主节点重启(运行runID变化)
- 采取措施:故障转移,例如哨兵或者集群
-
复制积压缓冲区不足
- 网络中断,部分复制无法满足
- 采取措施:增大复制缓冲区配置:
rel_backlog_size
,网络“增强”。
6.4 规避复制风暴
当master挂了很多slave的时候,master宕机了,这个时候所有的slave都需要重新全量复制。
- 单主节点复制风暴:
- 问题:主节点重启,多从节点复制
- 解决:更换复制拓扑
可以更改为右边的架构,但是还是有一个问题,当slave1出现问题了,那么怎么解决。
- 单机器复制风暴
- 机器宕机后,大量全量复制