阅读 1368

Redis基础(七)—— 主从复制

这是我参与8月更文挑战的第10天,活动详情查看:8月更文挑战

概念

主从复制,是指将一台 Redis 服务器的数据,复制到其他的Redis服务器。

前者称为主节点 (master/leader),后者称为从节点 (slave/follower),数据的复制是单向的,只能由主节点到从节点

Master以写为主,Slave以读为主。

默认情况下,每台 Redis 服务器都是主节点,且一个主节点可以有零个或多个从节点,但一个从节点只能由一个主节点。

主从复制,读写分离.

作用

  1. 数据冗余:主从复制实现了数据的热备份,是持久化之外的一种数据冗余方式;
  2. 故障恢复:当主节点出现问题时,可以由从节点提供服务,实现快速的故障回复;实际上是一种服务的冗余;
  3. 负载均衡:在主从复制的基础上,配合读写分离,可以由主节点提供写服务,由从节点提供读服务(即写 Redis 数据时应用连接主节点,读Redis数据时应用连接从节点),分担服务器负载;尤其是在写少读多的场景下,通过多个节点分担读负载,可以大大提高Redis服务器的并发量;
  4. 高可用(集群)基石:除了上述作用意外,主从复制还是哨兵和集群能够实施的基础,因此说主从复制是Redis高可用的基础。

一般来说,要将 Redis 运用于工程项目中,只是用一台 Redis 是万万不能的(宕机),原因如下:

  • 从结构上,单个 Redis 服务器会发生单点故障,并且一台服务器需要处理所有的请求负载,压力较大;

  • 从容量上,单个 Redis 服务器内存容量有限,就算一台 Redis 服务器内存容量为 256GB,也不能将所有内存用作 Redis 存储内存,

    一般来说,单台 Redis 最大使用内存不应该超过 20GB。

环境配置

只配置从库,不用配置主库

 127.0.0.1:6379> info replication
 # Replication
 role:master     # 角色: master
 connected_slaves:0  # 没有从机
 master_replid:0d064ffd4a54a85fdd85637328e88d4abd05d8ac
 master_replid2:0000000000000000000000000000000000000000
 master_repl_offset:0
 second_repl_offset:-1
 repl_backlog_active:0
 repl_backlog_size:1048576
 repl_backlog_first_byte_offset:0
 repl_backlog_histlen:0
 127.0.0.1:6379> 
复制代码

因为我这里只用了一台服务器,所以我们配置一个伪集群环境,修改对应配置信息

  • port:进程占用端口号;
  • pidfile:记录进程的 ID,文件带有锁,可以防止程序的多次启动;
  • logfile:明确日志文件位置;
  • dbfilename:持久化文件位置

修改配置信息后,根据配置文件分别启动三个 Redis 服务

image-20210805175231969

一主二从

默认情况下(配置前),每台 Redis 服务器都是主节点;

只配置从库,不用配置主库

认主人:一主(6379)二从(6380、6381)

主机能读写,从机只能读不能写

重要!!!

如果主节点服务器有密码,作为从节点的服务器,要在配置文件中加入

 masterauth xxx(主节点连接密码)
复制代码

如:

6380端口的服务器,配置文件 redis80.conf,搜索配置参数 masterauth,修改为

 masterauth 6379
复制代码

配置前:

 127.0.0.1:6380> info replication
 # Replication
 role:master
 connected_slaves:0
 master_replid:f89b7907749c026069c80059a9d2cd41fae23e39
 master_replid2:0000000000000000000000000000000000000000
 master_repl_offset:0
 second_repl_offset:-1
 repl_backlog_active:0
 repl_backlog_size:1048576
 repl_backlog_first_byte_offset:0
 repl_backlog_histlen:0
复制代码

使用命令方式配置从机

 # 命令 主机地址 主机端口
 127.0.0.1:6380> SLAVEOF 127.0.0.1 6379
 OK
复制代码

从机配置后信息:

 127.0.0.1:6380> info replication
 # Replication
 role:slave
 master_host:127.0.0.1
 master_port:6379
 master_link_status:up
 master_last_io_seconds_ago:10
 master_sync_in_progress:0
 slave_repl_offset:14
 slave_priority:100
 slave_read_only:1
 connected_slaves:0
 master_replid:2382336ee0bd6abe27c267b35c827bcecbb3fa91
 master_replid2:0000000000000000000000000000000000000000
 master_repl_offset:14
 second_repl_offset:-1
 repl_backlog_active:1
 repl_backlog_size:1048576
 repl_backlog_first_byte_offset:1
 repl_backlog_histlen:14
复制代码

主机信息:

 127.0.0.1:6379> info replication
 # Replication
 role:master
 connected_slaves:1  # 多了从机的信息
 slave0:ip=127.0.0.1,port=6380,state=online,offset=798,lag=1
 master_replid:2382336ee0bd6abe27c267b35c827bcecbb3fa91
 master_replid2:0000000000000000000000000000000000000000
 master_repl_offset:798
 second_repl_offset:-1
 repl_backlog_active:1
 repl_backlog_size:1048576
 repl_backlog_first_byte_offset:1
 repl_backlog_histlen:798
复制代码

配置文件配置从机

真实的从主配置应该在配置文件中配置,这样才是永久的。我们这里使用的是命令来配置,是暂时的。

查看作为从节点的配置文件:

image-20210805185552384

  1. 配置主机的ip地址、端口号,这时启动服务器就是从节点的存在;
  2. 主机的密码

主机断开

主机服务器关闭,从机仍然存在,只是连接状态 master_link_status 变为 down

当主机服务器再启动时,主从关系仍然存在。

从机断开

1号从机断开,再启动后,1号从机变为新主机(没有在配置文件配置主机信息,之前使用的是命令的方式建立主从关系);

当1号从机再次和主机建立主从关系后,在1号从机断开期间,主机新写入的数据,1号从机仍然能够查询到。

复制原理

Slave 启动成功连接到 master 后会发送一个 sync 同步命令

Master 接收到命令,启动后台的存盘进程,同时收集所有接收到的用于修改数据集命令,在后台进程执行完毕之后,master 将传送整个数据文件到 slave,并完成一次完全同步

全量复制: 而 Slave 服务在接收到数据库文件数据后,将其存盘并加载到内存中;

增量复制: Master 继续将新的所有手机到的修改命令一次传给 Slave,完成同步;

但是只要是重新连接 Master,一次完全同步(全量复制)将被自动执行!

糖葫芦模式

A:主机;

B:从机;

C:从机;

A作为B的主机,B做C的主机。这时 B 在某种意义上来讲,既是从机又是主机,但是使用命令 info replication可以看到 B 仍是从机,它 只能读不能写

主从复制一直存在一个问题,那就是当主机宕机了,那么它的所有从机都没有多少意义了,它们只能读不能写,无法存储新的数据;

那么能不能,当主机宕机后,在它的从机里面选一个出来作为主机呢?

谋朝篡位

手动

当主机不存在了,我们选一个从机,手动输入命令:

 SLAVEOF no one
复制代码

使该从机变为主机,再手动操作其他从机,连接到最新的这个主节点。

 SLAVEOF 127.0.0.1 6388
复制代码

哨兵模式

主从切换技术的方法:当主服务器宕机后,需要手动把一台从服务器切换为主服务器,这就需要人工干预,费时费力,还会造成一段时间内服务不可用。这不是一种推荐的方式,更多时候,我们优先考虑 哨兵模式。Redis 从 2.8 开始正式提供了 Sentinel(哨兵)架构来解决这个问题。

谋朝篡位的自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库。

原理

哨兵模式是一种特殊的模式,首先 Redis 提供了哨兵的命令,哨兵是一个独立的进程,作为进程,它会独立运行。

其原理是哨兵通过发送命令,等待 Redis 服务器响应,从而监控运行中的多个 Redis 实例。

image-20210806142145713

这里的哨兵有两个作用:

  • 通过发送命令,让 Redis 服务器返回监控其运行状态,包括主服务器和从服务器;
  • 当哨兵监测到 Master 宕机,会自动将某个 Slave 切换成 Master,然后通过发布订阅通知其他的从服务器,修改配置文件,让他们切换主机。

多哨兵模式

一个哨兵进程对 Redis 服务器进行监控,可能会出现问题,为此,我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控,这样就形成了多哨兵模式。

image-20210806143700217

  1. 假设主机宕机了,哨兵1 先检测到这个结果,系统并不会马上进行 failover (故障转移)过程,仅仅是哨兵1 主观认为主服务器不可用,这个现象是主观下线
  2. 当后面的哨兵也监测到主服务器不可用,并且数量达到一定值时,那么哨兵之间就会进行一次投票,投票由一个哨兵发起,进行 failover(故障转移)操作;
  3. 切换成功后,就会通过 发布订阅模式,让各个哨兵把自己监控的从服务器实现切换主机,这个过程称为 客观下线

配置

  1. 创建 sentinel.conf 文件

  2. 配置信息

     # sentinel monitor 哨兵名称 监测主机IP地址 端口号 定值(当多少个哨兵监测到主机主观下线,才进行 failover 操作)
     sentinel monitor myredis 127.0.0.1 6379 1
     # 如果主机存在登录密码,需要配置以下信息
     # sentinel auth-pass 哨兵名称 主机密码(注意:因为哨兵不能分别为master和slave设置不同的密码,因此master和slave的密码应该设置相同。)
     sentinel auth-pass myredis 243600
    复制代码
  3. 启动 redis-sentinel

     [root@wrkq1njujislh7mx redis]# ./bin/redis-sentinel sentinel.conf
    复制代码

image-20210806162507446

模拟主机宕机

  1. 现在我们将主机关闭

     127.0.0.1:6379> shutdown
     not connected> exit
     [root@wrkq1njujislh7mx redis]# 
    复制代码
  2. 再观察一下它的两个从机的状态(这里尽量快一点,不然哨兵就已经更换主机了)

image-20210806162846646

  1. 等待片刻,我们可以看到 哨兵的日志文件发生变化:

    image-20210806163121048

  2. 此时,哨兵已经选好了新的主机,端口号为6380的Redis服务器,我们再次查看下6380和6381的服务器的状态:

    image-20210806163657329

  3. 此时新的主从机关系已经重新建立了,那么,如果之前那个主机6379再次回来了呢?

     [root@wrkq1njujislh7mx redis]# ./bin/redis-server redis79.conf 
     [root@wrkq1njujislh7mx redis]# ./bin/redis-cli -p 6379 -a 243600
     Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
     127.0.0.1:6379> ping
     PONG
    复制代码

    查看服务器状态(我这里命令输入慢了,快一点的话可以看到,此时的服务器还是Master,等到哨兵反应过来了,该服务器才变为从机的)

    此时的服务器自动变为了6380的从机,哨兵模式的规则。

     127.0.0.1:6379> info replication
     # Replication
     role:slave
     master_host:127.0.0.1
     master_port:6380
     master_link_status:down
     master_last_io_seconds_ago:-1
     master_sync_in_progress:0
     slave_repl_offset:1
     master_link_down_since_seconds:1628239308
     slave_priority:100
     slave_read_only:1
     connected_slaves:0
     master_replid:6de2947f7c68080c6bce977a0b4fca378ceb982b
     master_replid2:0000000000000000000000000000000000000000
     master_repl_offset:0
     second_repl_offset:-1
     repl_backlog_active:0
     repl_backlog_size:1048576
     repl_backlog_first_byte_offset:0
     repl_backlog_histlen:0
    复制代码

    查看哨兵日志:

    image-20210806164442140

优点

  1. 哨兵集群,基于主从复制,所有的主从配置优点,它都包含了;
  2. 主从可以切换,故障可以转移,系统的可用性就会更好;
  3. 哨兵模式就是主从复制模式的升级,手动到自动,整个架构更加健壮。

缺点

  1. Redis 不好在线扩容,集群容量一旦到达上限,在线扩容就十分麻烦;
  2. 实现哨兵模式的配置复杂繁琐(以上的配置信息,只是哨兵模式运行起来的简单配置)
文章分类
后端
文章标签