Redis基础（六）—— 主从复制

最新推荐文章于 2023-05-31 17:23:59 发布

子ぐ非鱼

最新推荐文章于 2023-05-31 17:23:59 发布

阅读量453

点赞数 1

分类专栏： Linux redis 数据库文章标签：分布式数据库 redis linux java

本文链接：https://blog.csdn.net/baidu_39560928/article/details/119559691

版权

redis 同时被 3 个专栏收录

8 篇文章 0 订阅

订阅专栏

数据库

6 篇文章 0 订阅

订阅专栏

Linux

5 篇文章 0 订阅

订阅专栏

概念

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

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

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

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

主从复制，读写分离.

作用

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

一主二从

默认情况下（配置前），每台 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

配置文件配置从机

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

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

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

主机断开

主机服务器关闭，从机仍然存在，只是连接状态 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 实例。

这里的哨兵有两个作用：

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

多哨兵模式

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

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

配置

创建 sentinel.conf 文件

配置信息

# 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

启动 redis-sentinel

[root@wrkq1njujislh7mx redis]# ./bin/redis-sentinel sentinel.conf

模拟主机宕机

现在我们将主机关闭

127.0.0.1:6379> shutdown
not connected> exit
[root@wrkq1njujislh7mx redis]#

再观察一下它的两个从机的状态（这里尽量快一点，不然哨兵就已经更换主机了）

等待片刻，我们可以看到哨兵的日志文件发生变化：
此时，哨兵已经选好了新的主机，端口号为6380的Redis服务器，我们再次查看下6380和6381的服务器的状态：

此时新的主从机关系已经重新建立了，那么，如果之前那个主机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

查看哨兵日志：

优点

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

缺点

Redis 不好在线扩容，集群容量一旦到达上限，在线扩容就十分麻烦；
实现哨兵模式的配置复杂繁琐（以上的配置信息，只是哨兵模式运行起来的简单配置）

子ぐ非鱼

关注

1
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Redis基础（六）—— 主从复制

概念主从复制，是指将一台 Redis 服务器的数据，复制到其他的Redis服务器。前者称为主节点 (master/leader)，后者称为从节点 (slave/follower)，数据的复制是单向的，只能由主节点到从节点。Master以写为主，Slave以读为主。默认情况下，每台 Redis 服务器都是主节点，且一个主节点可以有零个或多个从节点，但一个从节点只能由一个主节点。主从复制，读写分离.作用数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式；故障恢复：当主节点
复制链接

扫一扫