Redis的主从复制&哨兵模式

一、概述

二、集群搭建（单机伪集群）——一主二从

（一）创建和修改启动配置文件
1. 复制多份配置文件
[root@izwz93jpghqh4vdu29xzxkz redisConfig]# cp redis.conf redis79.conf
[root@izwz93jpghqh4vdu29xzxkz redisConfig]# cp redis.conf redis80.conf
[root@izwz93jpghqh4vdu29xzxkz redisConfig]# cp redis.conf redis81.conf
[root@izwz93jpghqh4vdu29xzxkz redisConfig]# ls -l
total 256
-rw-r--r-- 1 root root 61798 Aug  8 20:34 redis79.conf
-rw-r--r-- 1 root root 61798 Aug  8 20:34 redis80.conf
-rw-r--r-- 1 root root 61798 Aug  8 20:34 redis81.conf
-rw-r--r-- 1 root root 61798 Aug  1 23:25 redis.conf
2. 修改配置文件参数
pidfile /var/run/redis_6380.pid  -- 修改pid文件生成路径，避免冲突
logfile "redis80.log"  -- 设置日志的文件名
dbfilename dump80.rdb  -- 设置rdb文件文件名
port 6380  -- 配置端口号，防止冲突
bind 127.0.0.1  -- 如果是多台服务器的话，需要配置ip，这里的话因为是单机多服务，所以不用配

依次修改3份配置文件

vim redis79.conf
vim redis80.conf
vim redis81.conf
（二）启动3个Redis服务
 redis-server redisConfig/redis79.conf
redis-server redisConfig/redis80.conf
 redis-server redisConfig/redis81.conf
 ps -ef | grep redis  -- 查看redis是否正常启动
root     12251     1  0 20:52 ?        00:00:00 redis-server 127.0.0.1:6379
root     12260     1  0 20:52 ?        00:00:00 redis-server 127.0.0.1:6380
root     12267     1  0 20:52 ?        00:00:00 redis-server 127.0.0.1:6381
root     12274 11879  0 20:52 pts/0    00:00:00 grep --color=auto redis

使用info replication命令查看某个redis服务的情况

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:0
master_replid:2e34fdd82a027914f4555458a1ba3bef78104b99
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服务启动的时候，默认自己就是一台主机（master）

（三）配置主从（通过命令行）

由于redis在启动的时候已经默认自己为一台主机，所以我们配置主从的时候，只需要手动配置从节点即可。

127.0.0.1:6380> SLAVEOF 127.0.0.1 6379
OK
 同理，配置6381的主节点为6379端口的redis服务

使用info replication查看是否绑定成功

127.0.0.1:6381> info replication
# Replication
role:slave  -- 可以看到，此处的role角色已经变为slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:6
master_sync_in_progress:0
slave_repl_offset:154
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:e959acf39a0370252e92e1df83509d5d46e3035c
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:154
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:141
repl_backlog_histlen:14

主节点info信息如下：

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2  -- 可以看到，主节点下有两个从节点
slave0:ip=127.0.0.1,port=6380,state=online,offset=378,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=378,lag=1
master_replid:e959acf39a0370252e92e1df83509d5d46e3035c
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:378
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:378
（四）验证主从服务器的读写是否同步

主服务器

127.0.0.1:6379> set name xiaoming
OK

从服务器

127.0.0.1:6381> get name  --从服务器可以拿到master存储的value值
"xiaoming"
127.0.0.1:6381> set age 18 -- slave服务不能执行写操作
(error) READONLY You can't write against a read only replica.

注意，在真实的开发过程中，基本都是通过配置文件的方式，写入集群主从节点的相关配置，在服务启动的过程中根据配置文件内容进行配置。我们通过命令行的方式只是暂时配置，服务一关就没了
需要配置的内容为：

replicaof <masterip> <masterport> -- 配置主服务器的ip和端口
 masterauth <master-password> -- 如果主服务器有密码，需要配置一下密码
（五）主从机的宕机问题

问题1：主机挂了，（未配置哨兵模式的话）从节点会怎么样呢？

127.0.0.1:6379> shutdown  --关闭主机
not connected>

从机仍然保留slave的角色

127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:down
master_last_io_seconds_ago:-1
master_sync_in_progress:0
slave_repl_offset:2594
master_link_down_since_seconds:199
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:e959acf39a0370252e92e1df83509d5d46e3035c
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:2594
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:2594

同时，重启主机后，从机仍然可以获取到主机新存入的值

问题2：如果是从机挂了，重启后还是slave角色吗
如果没有预先在配置文件配置且启动，只是通过命令行方式启动的话，从机将恢复原样，即变为主机。

-- 主机现在变为只有一个slave
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6381,state=online,offset=294,lag=0
master_replid:2e915314bd2cf2bf8525989adc52aac97728b272
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:294
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:294

问题3：当恢复master的服务重新绑定为slave时，可以获取到主机原有的值吗
答： 可以

复制原理
Slave 启动成功连接到master后会发送一个sync同步命令
Master街道命令，启动后台的存盘进程，同时手机所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave，并完成一次完全同步。
全量复制：slave服务在接收到数据库文件数据后，将其存盘并加载带内存中
增量复制：master继续将新的所有搜集到的修改命令依次传给slave，完成同步
只要是重新连接master，一次完全同步（全量复制）将被自动执行

三、哨兵模式

（一）前言

通过前面的实验我们可以知道，当主节点挂掉后，从节点并不能自动的转为主节点，redis集群不能再执行写操作（因为从节点只可以读），我们只能手动切换从服务器为master

127.0.0.1:6380> SLAVEOF no one --使用该命令解绑原主机
OK
127.0.0.1:6381> SLAVEOF 127.0.0.1 6380 --给原从服务器配置新的主节点
OK
（二）哨兵模式概述

其实简单理解的话，哨兵模式就是用于处理主节点宕机后从节点自动升级为主节点的解决方案。当主节点挂掉后，我们不需要再手工的再去配置新的主节点（当集群中节点数量比较大的情况下，手动配置效率不高，而且我们也不知道什么时候主机会挂掉）
哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行，其原理是哨兵通过发送命令，等待redis服务器响应，从而监控运行多个redis实例

image.png

这里的哨兵有两个作用

通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。

当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

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

用文字描述一下故障切换（failover）的过程。假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。这样对于客户端而言，一切都是透明的。
[图片上传中...(image.png-f08408-1596898798891-0)]

（三）哨兵模式配置
1. 新增（修改）配置文件sentinel.conf
# sentinel monitor  主机名（可以随意取） ip号 port号 1  -- 1表示，当主机挂掉后，由slave投票选举出一个从机来当主机
sentinel monitor master 127.0.0.1 6379 1
2. 启动哨兵进程
redis-sentinel redisConfig/sentinel.conf
-- 启动后，状态如下：

14189:X 08 Aug 2020 22:36:44.813 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
14189:X 08 Aug 2020 22:36:44.813 # Redis version=5.0.5, bits=64, commit=00000000, modified=0, pid=14189, just started
14189:X 08 Aug 2020 22:36:44.813 # Configuration loaded
                _._
           _.-``__ ''-._
      _.-``    `.  `_.  ''-._           Redis 5.0.5 (00000000/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._
 (    '      ,       .-`  | `,    )     Running in sentinel mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 26379
 |    `-._   `._    /     _.-'    |     PID: 14189
  `-._    `-._  `-./  _.-'    _.-'
 |`-._`-._    `-.__.-'    _.-'_.-'|
 |    `-._`-._        _.-'_.-'    |           http://redis.io
  `-._    `-._`-.__.-'_.-'    _.-'
 |`-._`-._    `-.__.-'    _.-'_.-'|
 |    `-._`-._        _.-'_.-'    |
  `-._    `-._`-.__.-'_.-'    _.-'
      `-._    `-.__.-'    _.-'
          `-._        _.-'
              `-.__.-'

14189:X 08 Aug 2020 22:36:44.814 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
14189:X 08 Aug 2020 22:36:44.817 # Sentinel ID is 6cacca8ab85d59be701c1992e62bfc004529a28e
14189:X 08 Aug 2020 22:36:44.817 # +monitor master master 127.0.0.1 6380 quorum 1
-- 下面的信息显示了一共有几个从节点
14189:X 08 Aug 2020 22:36:44.817 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ master 127.0.0.1 6380   
14189:X 08 Aug 2020 22:36:44.820 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ master 127.0.0.1 6380

关闭主节点后，哨兵进程显示选举过程如下

14189:X 08 Aug 2020 22:38:31.021 # +sdown master master 127.0.0.1 6380
14189:X 08 Aug 2020 22:38:31.021 # +odown master master 127.0.0.1 6380 #quorum 1/1
14189:X 08 Aug 2020 22:38:31.021 # +new-epoch 1
14189:X 08 Aug 2020 22:38:31.021 # +try-failover master master 127.0.0.1 6380
14189:X 08 Aug 2020 22:38:31.023 # +vote-for-leader 6cacca8ab85d59be701c1992e62bfc004529a28e 1
14189:X 08 Aug 2020 22:38:31.023 # +elected-leader master master 127.0.0.1 6380
14189:X 08 Aug 2020 22:38:31.023 # +failover-state-select-slave master master 127.0.0.1 6380
14189:X 08 Aug 2020 22:38:31.079 # +selected-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ master 127.0.0.1 6380
14189:X 08 Aug 2020 22:38:31.079 * +failover-state-send-slaveof-noone slave 127.0.0.1:6381 127.0.0.1 6381 @ master 127.0.0.1 6380
14189:X 08 Aug 2020 22:38:31.138 * +failover-state-wait-promotion slave 127.0.0.1:6381 127.0.0.1 6381 @ master 127.0.0.1 6380
14189:X 08 Aug 2020 22:38:32.084 # +promoted-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ master 127.0.0.1 6380
14189:X 08 Aug 2020 22:38:32.084 # +failover-state-reconf-slaves master master 127.0.0.1 6380
14189:X 08 Aug 2020 22:38:32.140 * +slave-reconf-sent slave 127.0.0.1:6379 127.0.0.1 6379 @ master 127.0.0.1 6380
14189:X 08 Aug 2020 22:38:33.088 * +slave-reconf-inprog slave 127.0.0.1:6379 127.0.0.1 6379 @ master 127.0.0.1 6380
14189:X 08 Aug 2020 22:38:33.088 * +slave-reconf-done slave 127.0.0.1:6379 127.0.0.1 6379 @ master 127.0.0.1 6380
14189:X 08 Aug 2020 22:38:33.170 # +failover-end master master 127.0.0.1 6380
-- 选举出了6381端口的服务作为最新的主节点
14189:X 08 Aug 2020 22:38:33.170 # +switch-master master 127.0.0.1 6380 127.0.0.1 6381
14189:X 08 Aug 2020 22:38:33.170 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ master 127.0.0.1 6381
14189:X 08 Aug 2020 22:38:33.170 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ master 127.0.0.1 6381
14189:X 08 Aug 2020 22:39:03.184 # +sdown slave 127.0.0.1:6380 127.0.0.1 6380 @ master 127.0.0.1 6381

问题：如果原有的主节点恢复后，会重新回到集群中作为主节点吗
答：不会，原有的主节点已经被替换为其他节点了，当79服务重启后，将不会有其他从节点
（四）哨兵模式优缺点小结
优点：

  1. 哨兵集群给予主从复制模式，所有主从配置优点，其都具备（就是高可用）
  2. 哨兵模式实现了自动化的主从复制，更加方便和自动化
    缺点：
  3. redis的在线扩容比较麻烦，集群容量一旦达到上限，在线扩容就十分麻烦
  4. 需要自己配置好哨兵的相关配置（如果有哨兵集群的话，需要配置的就更多了）

关于多哨兵模式详情，可以参考：https://www.jianshu.com/p/06ab9daf921d

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