Redis 主从复制与哨兵

原文:Redis 主从复制与哨兵

Redis 可以使用从属服务器来实现读写分离提高吞吐量或在主服务器故障时接替主服务器以提高可用性。

每个 Redis 服务器实例都可以配置多个 slave 节点,slave 服务器也可以拥有次级 slave 节点, 可以组织成复杂的树状结构(虽说生产环境下极少有人这么做)。

配置主从复制

为了尝试配置主从复制,我们至少需要两个 redis 服务器实例。最简单的方法是在 redis 官网下载 redis-server 二进制可执行文件,分别放在 master 和 slave 目录中。

在每个目录中分别创建 redis.conf 配置文件。master 实例的配置文件采用默认即可, 在 slave 实例中进行主从复制配置:

# 和主服务器 6379 区分
port 6380

# 主服务器 ip 端口
slaveof 127.0.0.1 6379

# 如果主服务器配置了密码请写在这个配置项中
# masterauth <master-password>

##
## 接下来的选项保留默认配置即可,这里仅做介绍
##

# 当与 master 断开连接或正在进行同步时
# yes: 仍然正常响应客户端请求,但可能返回过时数据
# no: 除 INFO 和 SLAVEOF 命令正常外,其它命令均返回 SYNC with master in progress 错误
slave-serve-stale-data yes

# 从服务器只读
slave-read-only yes

使用redis-server redis.conf 命令分别启动 redis-server 实例。 使用redis-cli -p 6380命令连接从服务器:

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:16
master_sync_in_progress:0
slave_repl_offset:3640
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:0b4e100aa9e9fda54aeba2bc110316d811ac2ff6
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:3640
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:3640
127.0.0.1:6380> get a
1
127.0.0.1:6380> set a 2
(error) READONLY You can't write against a read only slave.

SLAVEOF host port 可以动态改变从服务器所属的 master 节点。SLAVEOF NO ONE 关闭复制功能,并从 slave 服务器转变回 master 服务器,原来同步所得的数据集不会被丢弃。在当主服务器故障时,可以使用SLAVEOF NO ONE命令将 slave 服务器提升为 master。

主从复制原理

SYNC

在 Redis 2.8 之前的版本里,Redis 仅支持全量复制不支持增量复制,这极大的影响了主从同步的性能。

Redis 2.8 之前的版本主从复制流程如下:

  1. slave 发送 SYNC 命令给 master
  2. master 执行 bgsave 命令生成 rdb 文件。于此同时,所有新的写命令都将被写入复制缓冲区内
  3. master 将 rdb 文件发送给 slave
  4. master 将缓冲区中的命令同步给 slave, 完成一次主从同步

PSYNC

Redis 2.8 开始使用 PSYNC 命令代替 SYNC 命令, PSYNC 具有全量复制和增量复制功能。

master 和 slave 节点均拥有一个 runid 作为自己的唯一标识。

master 和 slave 会各自维护一个复制偏移量,在增量复制时标识同步进度。

master 会维护一个 FIFO 的复制缓冲区(replication backlog),默认大小 1mb。

# 复制缓冲区大小
repl-backlog-size 1mb

# 当 master 不再与任何 slave 保持连接时,复制缓冲区可能被清空
# repl-backlog-ttl 用于配置从断开连接到清空缓冲区间隔的秒数
# 0 表示永不清除缓冲区
repl-backlog-ttl 3600

接下来我们可以开始说明 PSYNC 命令执行的流程:

  1. slave 向 master 请求同步

    1. 若 slave 未与任何 master 同步过或执行了 SLAVEOF NO ONE 命令,则向 master 发送 PSYNC ? -1命令要求进行全量同步。
    2. 否则,则向 master 发送 psync <runid> <offset>命令要求增量同步,其中 runid 是上次同步的主服务器的ID,offset 是同步偏移量
  2. master 响应同步请求
    1. 若 slave 请求增量同步且满足:1. runid 与自身相同;2. 同步偏移量处于自身复制缓冲区内,则响应+continue将复制缓冲区内的数据同步到 slave
    2. 若 slave 请求增量同步但不同时满足上述两个条件或 slave 请求全量同步, 则响应+fullresync <runid> <offset> 执行全量同步,其中 runid 是自身ID, offset 是自身同步偏移量。
  3. 若自身版本过低不支持PSYNC命令则响应 error, slave 会尝试使用 SYNC 命令进行同步。

哨兵

简单的主从复制架构在 master 故障后会不可用,Redis 官方提供了哨兵(sentinel)机制自动实现主备切换保证高可用。

哨兵机制通过一组哨兵节点监控主从节点的运行状态,并在主节点故障后选举新的主节点。

哨兵节点定时执行3个任务:

  • 哨兵节点每隔10s向主从节点发送INFO命令以更新拓扑图,自动感知新的 slave 节点。
  • 哨兵节点每隔1s向主从节点发送PING命令进行心跳检测。
  • 哨兵节点每隔2s向__sentinel__:hello频道发送自身哨兵节点信息和自身了解的 master 信息。所有哨兵节点均会订阅该频道,并以此更新哨兵集群信息。

若哨兵节点发现 master 节点心跳响应超时,则认为 master 主观下线。此时,master 可能真的已经崩溃也可能仅仅是此哨兵节点与 master 之间出现网络故障。

认为 master 主观下线的哨兵会向其它哨兵发送sentinel is-master-down-by addr询问 master 是否下线。若半数以上的哨兵认为 master 已经下线则认为 master 客观下线。

哨兵节点会选举自己第一个收到的 is-master-down-by 命令的发送者为哨兵领导者。若某一个节点得到过半投票则会成为哨兵领导者,若没有节点得到半数以上票则会进入下一轮投票。此选举流程与 Paxos 算法类似。

哨兵领导者负责选择一个slave节点提升为新 master 节点, 选择逻辑为:

  1. 过滤掉不健康的 slave 节点
  2. 选择 slave-priority 配置值最小的从节点。若有多个从节点 slave-priority 最小且相同则进入下一步
  3. 选择复制偏移量最大的从节点,这意味着这个从节点上面的数据最完整。若仍有多个 slave 节点偏移量相同则进入下一步
  4. 选择 runid 最小的从节点

新的 master 节点选出后会执行提升流程:

  1. 向新选出的 master 节点发出 SLAVEOF NO ONE 命令,提升为新的 master 节点
  2. 向其它 slave 节点发出 SLAVEOF 命令跟随新的 master 节点
  3. 在哨兵集群中将下线的 master 节点更新为下线的 slave 节点,在其回复后命令其跟随新的 master

原文地址:https://www.cnblogs.com/lonelyxmas/p/10891652.html

时间: 2024-10-11 20:46:51

Redis 主从复制与哨兵的相关文章

redis学习三,Redis主从复制和哨兵模式

Redis主从复制 java架构师项目实战,高并发集群分布式,大数据高可用,视频教程 1.Master可以拥有多个slave 2.多个slave可以连接同一个Master外,还可以连接到其他的slave 3.主从复制不会阻塞Master在主从复制时,Master可以处理client请求. 4.提供系统的伸缩性. 主从复制的过程 1.slave与Master建立连接,发送sync同步命令. 也就是说当用户在Master写入一条命令后,他们之间会通过一些算法把数据同步到每一个slave上. 2.Ms

Redis系列八:redis主从复制和哨兵

一.Redis主从复制 主从复制:主节点负责写数据,从节点负责读数据,主节点定期把数据同步到从节点保证数据的一致性 1. 主从复制的相关操作 a,配置主从复制方式一.新增redis6380.conf, 加入 slaveof 192.168.1.111 6379, 在6379启动完后再启6380,完成配置:b,配置主从复制方式二.redis-server --slaveof 192.168.1.111 6379 临时生效 c,查看状态:info replicationd,断开主从复制:在slave

Redis主从复制、哨兵模式

1.部署主从 环境:主IP:10.0.0.15,端口6379;从IP:10.0.0.16,端口6379. 原理:基于RDB持久化的功能来实现主从复制的功能. a.linux-redis1(10.0.0.15) cd /usr/local/redis/ grep "^[a-Z]" redis.conf # 列出几个修改过的配置 bind 10.0.0.15 protected-mode no port 6379 daemonize yes loglevel notice logfile

Redis主从复制和哨兵机制

1 启动三个不同端口号的redis 2 先把6377端口号的redis设为主  所以首先修改6378端口号的redis.conf文件 3 打开并修改6379端口的redis.conf文件 4 现在我们查看主节点redis的info信息 5 查看6378端口的redis   info信息 6 6379端口redis info信息同上 7 在6377端口redis中添加一个String 类型值其两台从机也会同步 8 6378端口和6379端口也同步 9 哨兵机制:随便自选一个redis  6378 

Redis主从复制之哨兵模式(sentinel)

介绍:反客为主的自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库 调整结构:6379带着80.81 自定义的/myredis目录下新建sentinel.conf文件,名字绝不能错 配置哨兵,填写内容,sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 6379 1 ,上面最后一个数字1,表示主机挂掉后salve投票看让谁接替成为主机,得票数多少后成为主机 启动哨兵 正常主从演示 主机master挂了 投票选取 选81为主机  问题:如果

redis如何实现高可用【主从复制、哨兵机制】

原创itcats_cn 最后发布于2018-09-05 21:07:27 阅读数 5135 收藏展开实现redis高可用机制的一些方法:保证redis高可用机制需要redis主从复制.redis持久化机制.哨兵机制.keepalived等的支持. 主从复制的作用:数据备份.读写分离.分布式集群.实现高可用.宕机容错机制等. redis主从复制原理首先主从复制需要分为两个角色:master(主) 和 slave(从) ,注意:redis里面只支持一个主,不像Mysql.Nginx主从复制可以多主多

四、redis系列之主从复制与哨兵机制

1. 绪言 在现实应用环境中,出于数据容量.容灾.性能等因素的考虑,往往不会只使用一台服务器,而是使用集群的方式.Redis 中也有类似的维持一主多从的方式提高 Redis 集群的高可用性的方案,而其中不可避免的则是如何保证主从实例间的数据一致性,复制(Replication)是其解决办法.本篇介绍redis的主从复制及哨兵机制. 2. redis主从复制 2.1 主从拓扑 Redis 支持简单且易用的主从复制(master-slave replication)功能, 这一功能可以让从服务器(s

redis的主从复制,哨兵值守

环境: 主服务器:192.168.10.10    Centos 7  redis-5.0.4 从服务器:192.168.10.129  Centos 7  redis-5.0.4 从服务器:192.168.10.130  Centos 7  redis-5.0.4 关于如何安装redis不再本文讨论范围内,不过您可以参考https://www.cnblogs.com/caesar-id/p/10846541.html 1.自定义192.168.10.10主服务器配置文件 [[email pro

Redis 主从复制机制(集群)与 哨兵机制

1,什么是redis 主从复制 支持多个数据库之间的数据同步.只能一个主数据库(master),可以一个或者多个从数据库(slave) 主数据库,可以读写 从数据库,只可以读 当主数据库,做写的操作的时候,写完,redis会从给数据库发送信号,并将数据信息发送给从数据库,从数据库备份. 过程: 1:当一个从数据库启动时,会向主数据库发送sync命令, 2:主数据库接收到sync命令后会开始在后台保存快照(执行rdb操作),并将保存期间接收到的命令缓存起来 3:当快照完成后,redis会将快照文件