Redis主从和哨兵部署

1. Redis编译

发行版：CentOS Linux release 7.5.1804 (Core)
内核：3.10.0-862.el7.x86_64

1.1 下载Redis

前往http://download.redis.io/releases/选择合适的版本，然后使用命令下载：

$ cd /usr/local/etc
$ wget http://download.redis.io/releases/redis-4.0.11.tar.gz
$ tar -zxf redis-4.0.11.tar.gz

1.2 编译Redis

$ cd redis-4.0.11
$ make
cd src && make all
make[1]: 进入目录“/usr/local/etc/redis-4.0.11/src”
    CC Makefile.dep
make[1]: 离开目录“/usr/local/etc/redis-4.0.11/src”
make[1]: 进入目录“/usr/local/etc/redis-4.0.11/src”
... 这里省略n行
Hint: It's a good idea to run 'make test' ;)

make[1]: 离开目录“/usr/local/etc/redis-test/redis-4.0.11/src”

注1：上面的运行脚本，如果make失败，一般是系统中还未安装gcc,那么可以通过yum安装：yum install gcc

注2：编译到最后，看到一句提示：Hint: It's a good idea to run 'make test' ;)，是建议我们使用命令make test，该命令会在编译前会先进行test、check，当结果成功，即error为0，再进行编译。不过运行该命令时，需要安装tcl。

编译完成后，可在目录/usr/local/etc/redis-4.0.11/src下看到可执行的二进制文件，如redis-server、redis-cli等：

$ cd src
$ ll | grep redis
-rw-rw-r--. 1 root root    2417 8月   3 18:44 redisassert.h
-rwxr-xr-x. 1 root root 2451272 9月   4 14:36 redis-benchmark
-rw-rw-r--. 1 root root   29605 8月   3 18:44 redis-benchmark.c
-rw-r--r--. 1 root root  109144 9月   4 14:36 redis-benchmark.o
-rwxr-xr-x. 1 root root 5774416 9月   4 14:36 redis-check-aof
-rw-rw-r--. 1 root root    7143 8月   3 18:44 redis-check-aof.c
-rw-r--r--. 1 root root   28656 9月   4 14:36 redis-check-aof.o
-rwxr-xr-x. 1 root root 5774416 9月   4 14:36 redis-check-rdb
-rw-rw-r--. 1 root root   13898 8月   3 18:44 redis-check-rdb.c
-rw-r--r--. 1 root root   62808 9月   4 14:36 redis-check-rdb.o
-rwxr-xr-x. 1 root root 2617320 9月   4 14:36 redis-cli
-rw-rw-r--. 1 root root  100621 8月   3 18:44 redis-cli.c
-rw-r--r--. 1 root root  396784 9月   4 14:36 redis-cli.o
-rw-rw-r--. 1 root root   21758 8月   3 18:44 redismodule.h
-rwxr-xr-x. 1 root root 5774416 9月   4 14:36 redis-sentinel
-rwxr-xr-x. 1 root root 5774416 9月   4 14:36 redis-server
-rwxrwxr-x. 1 root root   65991 8月   3 18:44 redis-trib.rb

2. Redis主从和哨兵部署

2. 1 准备工作

2.1.1 拷贝二进制文件

$ cd /etc/local
$ mkdir redisDB
$ cd redisDB
$ cp /usr/local/etc/redis-4.0.11/src/redis-server ./
$ cp /usr/local/etc/redis-4.0.11/src/redis-cli ./
$ cp /usr/local/etc/redis-4.0.11/src/redis-sentinel ./

2.1.2 创建conf、data、logs目录

$ mkdir conf
$ mkdir data
$ mkdir logs

2.2 Redis主从部署

2.2.1 主节点部署

$ cd conf
$ touch redis.conf # 创建redis.conf文件
主节点配置文件 —— redis.conf
# 守护进程模式
daemonize yes

# pid file
pidfile "/var/run/redis.pid"

# 监听端口
port 6379

# TCP接收队列长度，受/proc/sys/net/core/somaxconn和tcp_max_syn_backlog这两个内核参数的影响
tcp-backlog 511

# 一个客户端空闲多少秒后关闭连接(0代表禁用，永不关闭)
timeout 0

# 如果非零，则设置SO_KEEPALIVE选项来向空闲连接的客户端发送ACK
tcp-keepalive 60

# 指定服务器调试等级
# 可能值：
# debug （大量信息，对开发/测试有用）
# verbose （很多精简的有用信息，但是不像debug等级那么多）
# notice （适量的信息，基本上是你生产环境中需要的）
# warning （只有很重要/严重的信息会记录下来）
loglevel notice

# 指明日志文件名
logfile "/usr/local/redisDB/logs/redis-6379.log"

# 设置数据库个数
databases 16

# 会在指定秒数和数据变化次数之后把数据库写到磁盘上
# 900秒（15分钟）之后，且至少1次变更
# 300秒（5分钟）之后，且至少10次变更
# 60秒之后，且至少10000次变更
save 900 1
save 300 10
save 60 10000

# 默认如果开启RDB快照(至少一条save指令)并且最新的后台保存失败，Redis将会停止接受写操作
# 这将使用户知道数据没有正确的持久化到硬盘，否则可能没人注意到并且造成一些灾难
stop-writes-on-bgsave-error yes

# 当导出到 .rdb 数据库时是否用LZF压缩字符串对象
rdbcompression yes

# 版本5的RDB有一个CRC64算法的校验和放在了文件的最后。这将使文件格式更加可靠。
rdbchecksum yes

# 持久化数据库的文件名
dbfilename "dump-6379.rdb"

# 工作目录
dir "/usr/local/redisDB/data"

# 当master服务设置了密码保护时，slav服务连接master的密码
masterauth "abc"

# 当一个slave失去和master的连接，或者同步正在进行中，slave的行为可以有两种：
#
# 1) 如果 slave-serve-stale-data 设置为 "yes" (默认值)，slave会继续响应客户端请求，
# 可能是正常数据，或者是过时了的数据，也可能是还没获得值的空数据。
# 2) 如果 slave-serve-stale-data 设置为 "no"，slave会回复"正在从master同步
# （SYNC with master in progress）"来处理各种请求，除了 INFO 和 SLAVEOF 命令。
slave-serve-stale-data yes

# 你可以配置salve实例是否接受写操作。可写的slave实例可能对存储临时数据比较有用(因为写入salve
# 的数据在同master同步之后将很容易被删除
slave-read-only yes

# 是否在slave套接字发送SYNC之后禁用 TCP_NODELAY？
# 如果你选择“yes”Redis将使用更少的TCP包和带宽来向slaves发送数据。但是这将使数据传输到slave
# 上有延迟，Linux内核的默认配置会达到40毫秒
# 如果你选择了 "no" 数据传输到salve的延迟将会减少但要使用更多的带宽
repl-disable-tcp-nodelay no

# slave的优先级是一个整数展示在Redis的Info输出中。如果master不再正常工作了，哨兵将用它来
# 选择一个slave提升=升为master。
# 优先级数字小的salve会优先考虑提升为master，所以例如有三个slave优先级分别为10，100，25，
# 哨兵将挑选优先级最小数字为10的slave。
# 0作为一个特殊的优先级，标识这个slave不能作为master，所以一个优先级为0的slave永远不会被
# 哨兵挑选提升为master
slave-priority 100

# 密码验证
# 警告：因为Redis太快了，所以外面的人可以尝试每秒150k的密码来试图破解密码。这意味着你需要
# 一个高强度的密码，否则破解太容易了
requirepass "abc"

# redis实例最大占用内存，不要用比设置的上限更多的内存。一旦内存使用达到上限，Redis会根据选定的回收策略（参见：
# maxmemmory-policy）删除key
maxmemory 3gb

# 最大内存策略：如果达到内存限制了，Redis如何选择删除key。你可以在下面五个行为里选：
# volatile-lru -> 根据LRU算法删除带有过期时间的key。
# allkeys-lru -> 根据LRU算法删除任何key。
# volatile-random -> 根据过期设置来随机删除key, 具备过期时间的key。
# allkeys->random -> 无差别随机删, 任何一个key。
# volatile-ttl -> 根据最近过期时间来删除（辅以TTL）, 这是对于有过期时间的key
# noeviction -> 谁也不删，直接在写操作时返回错误。
maxmemory-policy volatile-lru

# 默认情况下，Redis是异步的把数据导出到磁盘上。这种模式在很多应用里已经足够好，但Redis进程
# 出问题或断电时可能造成一段时间的写操作丢失(这取决于配置的save指令)。
#
# AOF是一种提供了更可靠的替代持久化模式，例如使用默认的数据写入文件策略（参见后面的配置）
# 在遇到像服务器断电或单写情况下Redis自身进程出问题但操作系统仍正常运行等突发事件时，Redis
# 能只丢失1秒的写操作。
#
# AOF和RDB持久化能同时启动并且不会有问题。
# 如果AOF开启，那么在启动时Redis将加载AOF文件，它更能保证数据的可靠性。
appendonly no

# aof文件名
appendfilename "appendonly.aof"

# fsync() 系统调用告诉操作系统把数据写到磁盘上，而不是等更多的数据进入输出缓冲区。
# 有些操作系统会真的把数据马上刷到磁盘上；有些则会尽快去尝试这么做。
#
# Redis支持三种不同的模式：
#
# no：不要立刻刷，只有在操作系统需要刷的时候再刷。比较快。
# always：每次写操作都立刻写入到aof文件。慢，但是最安全。
# everysec：每秒写一次。折中方案。
appendfsync everysec

# 如果AOF的同步策略设置成 "always" 或者 "everysec"，并且后台的存储进程（后台存储或写入AOF
# 日志）会产生很多磁盘I/O开销。某些Linux的配置下会使Redis因为 fsync()系统调用而阻塞很久。
# 注意，目前对这个情况还没有完美修正，甚至不同线程的 fsync() 会阻塞我们同步的write(2)调用。
#
# 为了缓解这个问题，可以用下面这个选项。它可以在 BGSAVE 或 BGREWRITEAOF 处理时阻止主进程进行fsync()。
#
# 这就意味着如果有子进程在进行保存操作，那么Redis就处于"不可同步"的状态。
# 这实际上是说，在最差的情况下可能会丢掉30秒钟的日志数据。（默认Linux设定）
#
# 如果你有延时问题把这个设置成"yes"，否则就保持"no"，这是保存持久数据的最安全的方式。
no-appendfsync-on-rewrite yes

# 自动重写AOF文件
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# AOF文件可能在尾部是不完整的（这跟system关闭有问题，尤其是mount ext4文件系统时
# 没有加上data=ordered选项。只会发生在os死时，redis自己死不会不完整）。
# 那redis重启时load进内存的时候就有问题了。
# 发生的时候，可以选择redis启动报错，并且通知用户和写日志，或者load尽量多正常的数据。
# 如果aof-load-truncated是yes，会自动发布一个log给客户端然后load（默认）。
# 如果是no，用户必须手动redis-check-aof修复AOF文件才可以。
# 注意，如果在读取的过程中，发现这个aof是损坏的，服务器也是会退出的，
# 这个选项仅仅用于当服务器尝试读取更多的数据但又找不到相应的数据时。
aof-load-truncated yes

# Lua 脚本的最大执行时间，毫秒为单位
lua-time-limit 5000

# Redis慢查询日志可以记录超过指定时间的查询
slowlog-log-slower-than 10000

# 这个长度没有限制。只是要主要会消耗内存。你可以通过 SLOWLOG RESET 来回收内存。
slowlog-max-len 128

# redis延时监控系统在运行时会采样一些操作，以便收集可能导致延时的数据根源。
# 通过 LATENCY命令 可以打印一些图样和获取一些报告，方便监控
# 这个系统仅仅记录那个执行时间大于或等于预定时间（毫秒）的操作,
# 这个预定时间是通过latency-monitor-threshold配置来指定的，
# 当设置为0时，这个监控系统处于停止状态
latency-monitor-threshold 0

# Redis能通知 Pub/Sub 客户端关于键空间发生的事件，默认关闭
notify-keyspace-events ""

# 当hash只有少量的entry时，并且最大的entry所占空间没有超过指定的限制时，会用一种节省内存的
# 数据结构来编码。可以通过下面的指令来设定限制
hash-max-ziplist-entries 512
hash-max-ziplist-value 64

# 与hash似，数据元素较少的list，可以用另一种方式来编码从而节省大量空间。
# 这种特殊的方式只有在符合下面限制时才可以用
list-max-ziplist-entries 512
list-max-ziplist-value 64

# set有一种特殊编码的情况：当set数据全是十进制64位有符号整型数字构成的字符串时。
# 下面这个配置项就是用来设置set使用这种编码来节省内存的最大长度。
set-max-intset-entries 512

# 与hash和list相似，有序集合也可以用一种特别的编码方式来节省大量空间。
# 这种编码只适合长度和元素都小于下面限制的有序集合
zset-max-ziplist-entries 128
zset-max-ziplist-value 64

# HyperLogLog稀疏结构表示字节的限制。该限制包括
# 16个字节的头。当HyperLogLog使用稀疏结构表示
# 这些限制，它会被转换成密度表示。
# 值大于16000是完全没用的，因为在该点
# 密集的表示是更多的内存效率。
# 建议值是3000左右，以便具有的内存好处, 减少内存的消耗
hll-sparse-max-bytes 3000

# 启用哈希刷新，每100个CPU毫秒会拿出1个毫秒来刷新Redis的主哈希表（顶级键值映射表）
activerehashing yes

# 客户端的输出缓冲区的限制，可用于强制断开那些因为某种原因从服务器读取数据的速度不够快的客户端
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60

# 默认情况下，“hz”的被设定为10。提高该值将在Redis空闲时使用更多的CPU时，但同时当有多个key
# 同时到期会使Redis的反应更灵敏，以及超时可以更精确地处理
hz 10

# 当一个子进程重写AOF文件时，如果启用下面的选项，则文件每生成32M数据会被同步
aof-rewrite-incremental-fsync yes
测试
$ ../redis-server redis.conf # 使用redis.conf配置启动redis
$ ../redis-cli -p 6379 -a abc
Warning: Using a password with '-a' option on the command line interface may not be safe.
127.0.0.1:6379> set name zhangsan
OK
127.0.0.1:6379> get name
"zhangsan"
127.0.0.1:6379> quit

至此，redis主节点启动成功且可以读写数据。

2.2.2 从节点部署

从节点的配置和主节点的配置基本一致，只需修改pidfile、端口、日志文件名、持久化数据库文件名，还有主节点的地址和认证密码。

$ mkdir slave
$ cd slave
$ cp ../redis.conf slave-6380.conf # 拷贝主节点配置，然后修改不一样的配置
从节点配置文件 —— slave-6380.conf

（以下只列出与主节点配置不一样的地方）

# pid file
pidfile "/var/run/redis-6380.pid"

# 监听端口
port 6380

# 指明日志文件名
logfile "/usr/local/redisDB/logs/redis-6380.log"

# 持久化数据库的文件名
dbfilename "dump-6380.rdb"

# 设置当本机为slave服务时，设置master服务的IP地址及端口，在Redis启动时，它会自动从master进行数据同步
slaveof 127.0.0.1 6379

# 当master服务设置了密码保护时，slave服务连接master的密码
masterauth "abc"
启动slave并查看数据同步情况
$ cd /usr/local/redisDB
$ ./redis-server ./conf/slave/slave-6380.conf
$ ./redis-cli -p 6380
127.0.0.1:6380> auth abc
OK
127.0.0.1:6380> get name
"zhangsan"

可以看到，已经将数据从master复制过来了。

2.3 Redis哨兵部署

2.3.1 主从复制的问题

上面一节讲了如何使用主从模式部署，虽然主从模式一定程度上提高了redis的高可用性，此时从节点有如下作用：

  • 一旦主节点宕机，从节点作为主节点的备份可以随时顶上来
  • 扩展主节点的读能力，分担主节点读压力

但是新的问题随之而来：一旦主节点宕机，从节点晋升成主节点，同时需要修改应用方的主节点地址，还需要命令所有从节点去复制新的主节点，整个过程需要人工干预。而接下来介绍的哨兵模式就可以有效解决该问题。

2.3.2 高可用的哨兵(Sentinel)模式

简介

Redis 的 Sentinel 系统用于管理多个 Redis 数据库， 该系统执行以下三个任务：

  • 监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
  • 提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过API 向管理员或者其他应用程序发送通知。
  • 自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。

Redis Sentinel其实是一个分布式系统，包含若干个Sentinel节点和Redis数据节点，每个Sentinel节点会对数据节点和其余Sentinel节点进行监控，当发现节点不可达时，会对节点做下线标识。

如果被标识的是主节点，他还会选择和其他Sentinel节点进行“协商”，当大多数的Sentinel节点都认为主节点不可达时，他们会选举出一个Sentinel节点来完成自动故障转移工作，同时将这个变化通知给Redis应用方。

整个过程完全自动，不需要人工介入，所以可以很好解决Redis的高可用问题。

接下来我们就通过部署一个Redis Sentinel实例来了解整体框架。

三哨兵架构
$ cd conf
$ mkdir sentinel
$ touch sentinel-26379.conf
哨兵一配置 —— sentinel-26379.conf
# port <sentinel-port>
port 26379

# 守护进程模式
daemonize yes

# 指明日志文件名
logfile "/usr/local/redisDB/logs/sentinel-26379.log"

# 工作路径，sentinel一般指定/tmp比较简单
dir "/usr/local/redisDB/data"

# sentinel monitor <master-name> <ip> <redis-port> <quorum>
# 哨兵监控这个master，在至少quorum个哨兵实例都认为master down后把master标记为O_DOWN(Objectively Down)状态。另外，slaves是自动发现，所以没必要明确指定slaves。
sentinel monitor mymaster 127.0.0.1 6379 2

# 设置master和slaves验证密码
sentinel auth-pass mymaster abc

# 每个Sentinel节点都要定期PING命令来判断Redis数据节点和其余Sentinel节点是否可达，如果超过指定时间（默认30000ms）且没有回复，则判定不可达
sentinel down-after-milliseconds mymaster 1500

# 当Sentinel节点集合对主节点故障判定达成一致时，Sentinel领导者节点会做故障转移操作，选出新的主节点，原来的从节点会向新的主节点发起复制操作，限制每次向新的主节点发起复制操作的从节点个数为1
sentinel parallel-syncs mymaster 1

# 若sentinel在该配置值内未能完成failover操作（即故障时master/slave自动切换），则认为本次failover失败。默认为：180000ms。
sentinel failover-timeout mymaster 30000

其它两个哨兵的配置sentinel-26380.conf、sentinel-26381.conf的配置与sentinel-26379.conf的配置基本一样，只需将端口和日志文件名改成对应的端口即可。

使用如下命令拷贝两份配置文件，然后将端口和日志文件名修改。

$ cp sentinel-26379.conf  sentinel-26380.conf
$ cp sentinel-26379.conf sentinel-26381.conf
哨兵二配置 —— sentinel-26380.conf
# port <sentinel-port>
port 26380

# 指明日志文件名
logfile "/usr/local/redisDB/logs/sentinel-26380.log"
哨兵三配置 —— sentinel-26381.conf
# port <sentinel-port>
port 26381

# 指明日志文件名
logfile "/usr/local/redisDB/logs/sentinel-26381.log"
启动Sentinel节点
$ cd /usr/local/redisDB/
$ ./redis-sentinel ./conf/sentinel/sentinel-26379.conf
$ ./redis-sentinel ./conf/sentinel/sentinel-26380.conf
$ ./redis-sentinel ./conf/sentinel/sentinel-26381.conf
$ ps axu | grep redis
root      3155  0.2  0.5 147356  9780 ?        Ssl  18:35   0:07 redis-server *:6379
root      3160  0.1  0.5 147356  9716 ?        Ssl  18:36   0:05 redis-server *:6380
root      5522  0.3  0.4 145308  7748 ?        Ssl  19:32   0:00 ./redis-sentinel *:26379 [sentinel]
root      5527  0.3  0.4 145308  7752 ?        Ssl  19:32   0:00 ./redis-sentinel *:26380 [sentinel]
root      5544  0.3  0.4 145308  7712 ?        Ssl  19:34   0:00 ./redis-sentinel *:26381 [sentinel]
root      5549  0.0  0.0 112720   984 pts/1    R+   19:34   0:00 grep --color=auto redis

当全部Rentinel节点启动完毕后，使用命令ps axu | grep redis可以看到当前已部署的 一主一从三哨兵 5个基点。

在sentinel中查看所监控的master和slave节点
$ ./redis-cli -p 26379
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=1,sentinels=3

观察最后一行，可以看出，该sentinel节点监控的包括一个master节点（名为mymaster，该名字是之前在sentinel-*中定义的别名）和一个slave节点(slaves=1)；而最后的sentinels=3则代表一共启动了3个sentinel节点对master slave节点进行监控。

# 查看监控的master节点
127.0.0.1:26379> sentinel masters
1)  1) "name"
    2) "mymaster"
    3) "ip"
    4) "127.0.0.1"
    5) "port"
    6) "6379"
    7) "runid"
    8) "33588ab0ca65129a348eb2cee5411f5723ea60fd"
    9) "flags"
   10) "master"
   ...
   37) "failover-timeout"
   38) "180000"
   39) "parallel-syncs"
   40) "1"

# 查看监控的slaves节点
127.0.0.1:26379> sentinel slaves mymaster
1)  1) "name"
    2) "127.0.0.1:6380"
    3) "ip"
    4) "127.0.0.1"
    5) "port"
    6) "6380"
    7) "runid"
    8) "8c094210e972a14ec9dfbc48d17d70825d9f42db"
    9) "flags"
   10) "slave"
   ...
   33) "master-host"
   34) "127.0.0.1"
   35) "master-port"
   36) "6379"
   37) "slave-priority"
   38) "100"
   39) "slave-repl-offset"
   40) "210450

# 查看当前的master
127.0.0.1:26379> sentinel get-master-addr-by-name mymaster
1) "127.0.0.1"
2) "6379"
提醒

当部署完sentinel节点后，会有如下变化：

  • sentinel节点自动发现了主节点、从节点，还有其余sentinel节点；
  • 去掉了默认配置，例如：parallel-syncs、failover-timeout；
  • 新添加了纪元（*-epoch）参数。

拿端口为26379的sentinel节点为例，启动所有sentinel和主从节点后，配置文件如下：

# port <sentinel-port>
port 26379

# 守护进程模式
daemonize yes

# 指明日志文件名
logfile "/usr/local/redisDB/logs/sentinel-26379.log"

# 工作路径，sentinel一般指定/tmp比较简单
dir "/usr/local/redisDB/data"

# sentinel monitor <master-name> <ip> <redis-port> <quorum>
# 哨兵监控这个master，在至少quorum个哨兵实例都认为master down后把master标记为O_DOWN(Objectively Dow    n)状态。另外，slaves是自动发现，所以没必要明确指定slaves。
sentinel myid b0513df38b1950395928489c17680197894b5a25

# 设置master和slaves验证密码
sentinel deny-scripts-reconfig yes

# 每个Sentinel节点都要定期PING命令来判断Redis数据节点和其余Sentinel节点是否可达，如果超过指定时间（
默认30000ms）且没有回复，则判定不可达
sentinel monitor mymaster 127.0.0.1 6380 2

# 当Sentinel节点集合对主节点故障判定达成一致时，Sentinel领导者节点会做故障转移操作，选出新的主节点>    ，原来的从节点会向新的主节点发起复制操作，限制每次向新的主节点发起复制操作的从节点个数为1
sentinel auth-pass mymaster abc

# 若sentinel在该配置值内未能完成failover操作（即故障时master/slave自动切换），则认为本次failover失>    败。默认为：180000ms。
sentinel config-epoch mymaster 1

# Generated by CONFIG REWRITE
sentinel leader-epoch mymaster 1
# 发现了一个从节点（注释）
sentinel known-slave mymaster 127.0.0.1 6379 
# 发送了两个Sentinel节点（注释）
sentinel known-sentinel mymaster 127.0.0.1 26381 7c24453d22995acd3396dab5553d01bf44511ba6
sentinel known-sentinel mymaster 127.0.0.1 26380 2a41d1b8c44b9d4b6b46fa86a61c0c4865627e60
sentinel current-epoch 1

注：上面的配置由于去掉了某些配置，所以部分配置的注释会对不上。

故障转移测试
$ redis-cli -a abc -p 6379 shutdown # 退出master节点
$ redis-cli -h 127.0.0.1 -p 26379 
127.0.0.1:26379> sentinel get-master-addr-by-name mymaster
1) "127.0.0.1"
2) "6380"
127.0.0.1:26379> sentinel masters
1)  1) "name"
    2) "mymaster"
    3) "ip"
    4) "127.0.0.1"
    5) "port"
    6) "6380" 
    7) "runid"
    8) "8c094210e972a14ec9dfbc48d17d70825d9f42db"
    9) "flags"
   10) "master"  # 6380端口的节点已经成为主节点
   ...
127.0.0.1:26379> sentinel slaves mymaster
1)  1) "name"
    2) "127.0.0.1:6379"
    3) "ip"
    4) "127.0.0.1"
    5) "port"
    6) "6379"
    7) "runid"
    8) ""
    9) "flags"
   10) "s_down,slave,disconnected" # 端口6379的原主节点已经断开了连接
   ...

可以看到master节点已经转移到之前的从节点上。

重启之前的master节点
$ redis-server ./conf/redis.conf
$ redis-clii -p 26379
127.0.0.1:26379> sentinel slaves mymaster
1)  1) "name"
    2) "127.0.0.1:6379"
    3) "ip"
    4) "127.0.0.1"
    5) "port"
    6) "6379"
    7) "runid"
    8) "558e5783a8a4f8f1fb16bfaad258ec91c9d46290"
    9) "flags"
   10) "slave" # 6379端口的节点重启后，变成了"活"的从节点
   ...

可以看出，6379端口的节点重启后变成端口6380的从节点。

3. 附：目录结构

[root@centos-linux redisDB]# tree
.
├── conf
│   ├── redis.conf
│   ├── sentinel
│   │   ├── sentinel-26379.conf
│   │   ├── sentinel-26380.conf
│   │   └── sentinel-26381.conf
│   └── slave
│       └── slave-6380.conf
├── data
│   ├── dump-6379.rdb
│   └── dump-6380.rdb
├── logs
│   ├── redis-6379.log
│   ├── redis-6380.log
│   ├── sentinel-26379.log
│   ├── sentinel-26380.log
│   └── sentinel-26381.log
├── redis-cli
├── redis-sentinel
└── redis-server

5 directories, 15 files

相关链接：Redis 配置

完！！！

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 203,098评论 5赞 476
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 85,213评论 2赞 380
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 149,960评论 0赞 336
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 54,519评论 1赞 273
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 63,512评论 5赞 364
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 48,533评论 1赞 281
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 37,914评论 3赞 395
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 36,574评论 0赞 256
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 40,804评论 1赞 296
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,563评论 2赞 319
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,644评论 1赞 329
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 33,350评论 4赞 318
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 38,933评论 3赞 307
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,908评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,146评论 1赞 259
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 42,847评论 2赞 349
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 42,361评论 2赞 342

推荐阅读更多精彩内容

  • Redis主从同步与集群管理
    1.主从同步原理像MySQL一样，Redis是支持主从同步的，而且也支持一主多从以及多级从结构。主从结构，一是为了...
    码出高效阅读 2,181评论 0赞 1
  • Redis主从+哨兵环境搭建
    架构 OS：Centos6.8 Redis01：172.17.100.130（sentinel-1，sentine...
    飞翔的Tallgeese阅读 619评论 0赞 2
  • Redis集群
    单机/单点 单点故障/瓶颈：多个节点负载：面向数据：一变多（一致性<弱一致，最终一致性>）》可用性最终一致性：一部...
    壹点零阅读 784评论 0赞 3
  • 深入学习Redis：主从复制
    在Redis的持久化中曾提到，Redis高可用的方案包括持久化、主从复制（及读写分离）、哨兵和集群。其中持久化侧重...
    不变甄心阅读 1,493评论 0赞 5
  • 古井无波
    光阴一老，心如古井。古井般的心，清明纯净，宁静从容，不再颠沛流离，不再辗转浮沉。刻满沧桑，不动声色，静水流...
    冰夫阅读 713评论 0赞 1