Redis简单介绍4-主从复制&哨兵监控&集群分片

Posted 2023-03-30 心流时间

文章目录

• 1. 主从复制
• • 1.1 定义
  • 1.2 作用
  • 1.3 配置策略
  • 1.4 基本操作命令
  • • 1.4.1 info replication 可以查看复制节点的主从关系和配置信息
    • 1.4.2 replicaof 主库ip 主库端口 ：配置文件中设置，给从库设置主库
    • 1.4.3 slaveof 主库ip 主库端口 ：命令设置，给从库设置主库
    • 1.4.4 salveof no one 从库变成主库
  • 1.5 演示案例
  • • 1.5.1 一主二仆
    • • 1.5.1.1 使用VMware创建三台虚拟机
      • 1.5.1.2 配置文件redis.cof修改
      • 1.5.1.3 systemctl stop firewalld 关闭主库防火墙，从库不需要，不然从库连接不上主库，无法做到主从复制
      • 1.5.1.4 主库从库启动命令
      • 1.5.1.5 查看主从日志文件
      • 1.5.1.6 info replication 查看主从关系信息
      • 1.5.1.7 查看主从效果
      • 1.5.1.8 从库不可写
      • 1.5.1.9 主从库启动顺序不同是否会造成数据不同步
      • • 1.5.1.9.1 从机切入点问题，从机启动之前的主机设置的key是否可查到
        • 1.5.1.9.2 先启动从机，再启动主机，从机能否查到值
        • 1.5.1.9.3 结论：主机宕机时从机依然可用，但仍是从机阶段，仍不可写；先启动主机和先启动从机，都启动好后没有区别，但是刚开始还是应该先启动主机
      • 1.5.1.10 slaveof 主库ip 主库端口：命令式声明自己成为某台机器的从机
    • 1.5.2 薪火相传
    • 1.5.3 反客为主
  • 1.6 主从复制原理和工作流程
  • • 1.6.1 slave启动，同步初请
    • 1.6.2 首次连接，全量复制
    • 1.6.3 心跳持续，保持通信
    • 1.6.4 进入平稳，增量复制
    • 1.6.5 从机下线，重连续传
  • 1.7 主从复制的缺点
  • • 1.7.1 复制延时，信号衰减
    • 1.7.2 master宕机后，从机默认情况下原地待命，只可读，不会变成主机，这时候只能人为干预，重新使主机恢复正常
• 2. 哨兵监控
• 3. 集群分片

1. 主从复制

1.1 定义

就是主从复制，master以写为主，slave以读为主，当master数据变化的时候，自动将新的数据异步同步到其他slave数据库

1.2 作用

1. 读写分离
2. 容灾恢复
3. 数据备份
4. 水平扩容支撑高并发

1.3 配置策略

1. 配从（库）不配主（库）
2. 从库中主要配置哪个是mater，以及访问master的密码
   

1.4 基本操作命令

1.4.1 info replication 可以查看复制节点的主从关系和配置信息

1.4.2 replicaof 主库ip 主库端口 ：配置文件中设置，给从库设置主库

一般写入进redis.conf配置文件内

1.4.3 slaveof 主库ip 主库端口 ：命令设置，给从库设置主库

每次与master断开之后，都需要重新连接，除非你配置进redis.conf文件；
在运行期间修改slave节点的信息，如果该数据库已经是某个主数据库的从数据库，那么会停止和原主数据库的同步关系转而和新的主数据库同步，重新拜码头

1.4.4 salveof no one 从库变成主库

使当前数据库停止与其他数据库的同步，转成主数据库，自立为王

1.5 演示案例

1.5.1 一主二仆

1.5.1.1 使用VMware创建三台虚拟机

1. 创建一台虚拟机，安装好redis
2. 完整克隆两台虚拟机。由于刚克隆出来的虚拟机ip跟之前的一样，所以需要修改ip，修改方式如下：

su root
vim /etc/sysconfig/network-scripts/ifcfg-ens33

# 重启网络
service network restart

查看ip（阿里云外网的ip是ping不通这个内网ip的）：

3. 更改三台虚拟机redis配置文件名称
   主库：redis6379.conf，主机名为centos7-1
   从库：redis6380.conf、redis6381.conf，主机名为centos7-2、centos7-3
   
   

1.5.1.2 配置文件redis.cof修改

# 策略是不同的机器，redis使用不同的端口，其实完全可以使用相同的端口，为了区分度好演示才这样做
vim /myredis/redis6379.conf

1. 开启daemonize yes
   
2. 注释掉bind 127.0.0.1 ，或者将ip修改为本机网卡所对应的真正的ip，否则别的机器识别不了127.0.0.1这个localhostip
   
3. protected-mode no 设置为yes是保护模式，不允许其他机器访问
   
4. （主从不同）指定端口
   
5. 指定当前工作目录，dir
   
6. （主从不同）pid文件名字，pidfile
   
7. （主从不同）log文件名字，logfile
   
8. requirepass 配置密码
   
9. （主从不同）rdb持久化文件名字
   
10. aof设置
    
11. （主从不同）从机访问主机的通行密码masterauth，主机不需要设置
    
    从库配置：
    

1.5.1.3 systemctl stop firewalld 关闭主库防火墙，从库不需要，不然从库连接不上主库，无法做到主从复制

1.5.1.4 主库从库启动命令

1.5.1.5 查看主从日志文件

主：/myredis/6379.log 其中包含从库的连接情况

从：/myredis/6380.log、/myredis/6381.log 其中包含跟主库的连接情况

1.5.1.6 info replication 查看主从关系信息

主：

从：

1.5.1.7 查看主从效果

主赋值：

从1可直接查到主库的值：

从2也可直接查到主库的值：

1.5.1.8 从库不可写

1.5.1.9 主从库启动顺序不同是否会造成数据不同步

1.5.1.9.1 从机切入点问题，从机启动之前的主机设置的key是否可查到

1. 将从机进程杀掉
   

2. 主机写入值
   

3. 启动从机，查看从机能否查到master的值-可以
   

1.5.1.9.2 先启动从机，再启动主机，从机能否查到值

1. 干掉主从机
   
   
2. 先启动从机，从机仍可以正常使用，显示主机下线
   
3. 再启动主机
   
4. 查看此时的从机是否同步到新值-是
   

1.5.1.9.3 结论：主机宕机时从机依然可用，但仍是从机阶段，仍不可写；先启动主机和先启动从机，都启动好后没有区别，但是刚开始还是应该先启动主机

1.5.1.10 slaveof 主库ip 主库端口：命令式声明自己成为某台机器的从机

1. 将配置文件的主机配置注释
   
2. 启动后编程master
   
3. slaveof 192.168.122.1 6379 指定主机
   
4. 重启从机，查看命令式配置会不会失效-会
   
5. 恢复配置文件

1.5.2 薪火相传

上一个slave可以是下一个slave的master，slave同样可以接收其他slaves的连接和同步请求，那么该slave作为了链条中下一个的master,可以有效减轻主master的写压力

1. 现在192.168.122.2作为192.168.122.1的slave，作为192.168.122.3的master
2. 由于192.168.122.2作为192.168.122.3的master，需要关闭192.168.122.2的防火墙，这也告诉我们一个道理，主从复制，其实是从向主发送请求拉数据，不然为何从不需要关闭防火墙

systemctl stop firewalld

3. 配置：
   在192.168.122.3中执行slaveof 192.168.122.2 6380
4. 结果：
   192.168.122.1：
   
   192.168.122.2：仍然不可编辑
   

192.168.122.3：

1.5.3 反客为主

使当前数据库停止与其他数据库的同步，转成主数据库

1. 在192.168.122.3中执行slaveof no one

slaveof no one

2. 结果
   192.168.122.1：
   

192.168.122.2：

192.168.122.3：

1.6 主从复制原理和工作流程

1.6.1 slave启动，同步初请

slave启动成功连接到master后会发送一个sync命令；
slave首次全新连接master,一次完全同步（全量复制)将被自动执行，slave自身原有数据会被master数据覆盖清除

1.6.2 首次连接，全量复制

master节点收到sync命令后会开始在后台保存快照(即RDB持久化，主从复制时会触发RDB)，
同时收集所有接收到的用于修改数据集命令缓存起来，master节点执行RDB持久化完后，
master将rdb快照文件和所有缓存的命令发送到所有slave,以完成一次完全同步,
而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中，从而完成复制初始化

1.6.3 心跳持续，保持通信

repl-ping-replica-period 10

1.6.4 进入平稳，增量复制

master继续将新的所有收集到的修改命令自动依次传给slave，完成同步

1.6.5 从机下线，重连续传

master会检查backlog里面的offset，master和slave都会保存一个复制的offset还有一个masterId，offset是保存在backlog中的。Master只会把已经复制的offset后面的数据复制给Slave，类似断点续传

1.7 主从复制的缺点

1.7.1 复制延时，信号衰减

1.7.2 master宕机后，从机默认情况下原地待命，只可读，不会变成主机，这时候只能人为干预，重新使主机恢复正常

2. 哨兵监控

3. 集群分片

Redis集群模式1-主从复制+哨兵机制

参考技术A

单个Redis服务如果宕机的话，服务就不可用了，为了解决这种问题，redis也提供有集群服务。传统的Redis集群采用的主从复制模式，一般为一主多从，主节点有读写权限，但是从节点只有读的权限。主节点会定期将数据同步到从节点中，保证数据一致性的问题。这种集群方式在运行时存在一些问题：

Redis的哨兵机制就是解决主从复制存在缺陷（选举问题），解决问题保证我们的Redis高可用，实现自动化故障发现与故障转移。
要使用哨兵机制，除了启动Redis服务以外，还要启动哨兵服务来进行监控，会介绍详细步骤。哨兵服务的工作原理如下：

演示集群采用1主2从，采用伪集群，在一台虚拟机中启动，端口暂定6381、6382、6383，集群结构可以选择下面2种，因为数量较少，此次采用普通样式。

主节点配置文件和单机的时候一样，主要修改以下几点

基本和主节点差不多，但要加上 slaveof 配置和主节点账号密码。

哨兵配置文件是 sentinel.conf ，因为有3个redis服务，所以启动3个哨兵服务，对应的配置文件分别为： sentinel_26381.conf 、 sentinel_26382.conf 、 sentinel_26383.conf

Redis服务和哨兵服务都启动了，可以测试哨兵的自动选举了，将6381沙雕，等几秒，再查看6382,6382的主从信息

注意：这个时候如果去看redis的配置文件，会发现配置文件中已经自动改好了主节点为6383了；而且哨兵的配置文件中，也改了主节点为6383了。这些都是哨兵帮我们做的

因集群中已有了新主节点，所以6381再启动只能作为从节点。此时6381启动，需要在配置文件中加入主节点信息：