redis主从哨兵搭建

比眉伴天荒 2021-11-27 02:48 481阅读 0赞

**1. 为什么要有哨兵机制**

哨兵机制是对Redis系统的运行情况的监控，解决主从复制的缺点的。

原理：当主节点出现故障时，由Redis Sentinel自动完成故障发现和转移，并通知应用方，实现高可用性。

作用：

a、 监控主数据库和从数据库是否运行正常；

b、 主数据出现故障后自动将从数据库转化为主数据库

**2.redis Sentinel模式配置**

一主(master)二从(slave)三哨兵(sentinel)的配置目标

sentinel    master    6380

sentinel    slave       6381

sentinel    slave       6382

***2.1  复制3个哨兵节点***

cp -a /usr/local/redis40/sentinel.conf /usr/local/redis-sentinel/sentinel-6380.conf

cp -a /usr/local/redis40/sentinel.conf /usr/local/redis-sentinel/sentinel-6381.conf

cp -a /usr/local/redis40/sentinel.conf /usr/local/redis-sentinel/sentinel-6382.conf

***2.2 conf配置项***

（1）下面3项,务必在每个**redis.conf**里进行修改,在每个**sentinel.conf**里新增(默认没有)

#支持内网/本地访问,比如 bind 192.168.1.100/127.0.0.1
    bind 127.0.0.1
    #支持后台运行,默认值为no
    daemonize yes
    #日志文件,比如redis.log、sentinel.log
    logfile xxx.log

（2）在Slave的redis.conf配置文件中新增加指定的master

#指定master
    slaveof 127.0.0.1 6380

（3）在每个sentinel的配置增加指定监控的master

#指定监控的master,最后一位表示quorum(法人数量),即认定master'客观下线'成立的最低票数
    sentinel monitor mymaster 127.0.0.1 6380 2

***2.3 启动事例***

分别启动主从redis, 验证没问题,再分别启动哨兵

(1)启动redis事例

src/redis-server /usr/local/Master-Slave/redis-master/master.conf
    src/redis-server /usr/local/Master-Slave/redis-slave/slave.conf 
    src/redis-server /usr/local/Master-Slave/redis-slave2/slave2.conf

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lpeWlqaWFueGlhbg_size_16_color_FFFFFF_t_70][]

(2)连接客户端查看主从配置信息

启动三个redis客户端

[root@localhost redis40]# ./src/redis-cli -h 127.0.0.1 -p 6380
    [root@localhost redis40]# ./src/redis-cli -h 127.0.0.1 -p 6381
    [root@localhost redis40]# ./src/redis-cli -h 127.0.0.1 -p 6382

（3）查看主从信息   info replication

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lpeWlqaWFueGlhbg_size_16_color_FFFFFF_t_70 1][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lpeWlqaWFueGlhbg_size_16_color_FFFFFF_t_70 2][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lpeWlqaWFueGlhbg_size_16_color_FFFFFF_t_70 3][]

(4)测试主从同步

在6380上写入信息

![20190727234225365.png][]

分别在6381和6382上取数据

![20190727234356662.png][]

![20190727234342249.png][]

***2.4 运行哨兵***

./src/redis-sentinel /usr/local/redis-sentinel/sentinel-26380.conf
    ./src/redis-sentinel /usr/local/redis-sentinel/sentinel-26381.conf
    ./src/redis-sentinel /usr/local/redis-sentinel/sentinel-26382.conf

![2019072922272691.png][]

![2019072922322777.png][]

![20190729223259269.png][]

查看哨兵监控日志(26380,26381,26382)

![20190729223502226.png][]

![20190729223418614.png][]

![20190729223533150.png][]

***2.5故障转移***

模拟故障发生, 进入master主机127.0.0.1:6380, kill掉redis-server进程.

![20190729223800742.png][]

查看各个哨兵的日志, 哨兵的工作过程, 如下

**1, 主观下线(sdown)**

当某个哨兵心跳检测master超时后,则认定其sdown

\+sdown master mymaster 127.0.0.1 6380

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lpeWlqaWFueGlhbg_size_16_color_FFFFFF_t_70 4][]

**2, 客观下线(odown)**

当认定sdown的哨兵数>=quorum时,则master下线事实最终成立,即odown

+odown master mymaster 172.31.175.142 6380 \#quorum 2/2

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lpeWlqaWFueGlhbg_size_16_color_FFFFFF_t_70 5][]

**3, 选举哨兵leader**

各哨兵协商,选举出一个leader,由其进行故障转移操作

\+vote-for-leader a30f83f1c2cd2c71beba4d390cf670c7b83c77f1 1

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lpeWlqaWFueGlhbg_size_16_color_FFFFFF_t_70 6][]

**4, 故障转移**

选择一个slave作为新的master, 并将其他节点设置为新master的slave (刚才已下线的老master的配置文件也会被设置slaveof...)

\+switch-master mymaster 127.0.0.1 6380 127.0.0.1 6382

当故障转移成功后, redis就是一主一从, 如下

<table> 
 <tbody> 
  <tr> 
   <td><strong>主机&nbsp;</strong></td> 
   <td><strong>角色</strong></td> 
  </tr> 
  <tr> 
   <td>6380</td> 
   <td>哨兵、master</td> 
  </tr> 
  <tr> 
   <td>6381</td> 
   <td>哨兵、slave</td> 
  </tr> 
  <tr> 
   <td>6382</td> 
   <td> <p>哨兵、slave&nbsp;-&gt;&nbsp;master</p> </td> 
  </tr> 
 </tbody> 
</table>

进入新的master 127.0.0.1:6382, 查看redis的主从信息, 还剩一从127.0.0.1:6381

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lpeWlqaWFueGlhbg_size_16_color_FFFFFF_t_70 7][]

2.6故障恢复

模拟故障恢复,进入老的master 127.0.0.1:6380, 重启刚才kill掉的redis, 之后查看其主从信息, 发现老的master已经变成slave了,如下

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lpeWlqaWFueGlhbg_size_16_color_FFFFFF_t_70 8][]

*因为172.0.0.1:6380的redis.conf在故障转移时被修改了,所以重启之后就直接成了slave*

进入新的master 127.0.0.1:6382下,再去查看最新的主从信息, 发现加入了新的slave, 如下

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lpeWlqaWFueGlhbg_size_16_color_FFFFFF_t_70 9][]

故障恢复之后, redis恢复到了一主二从三哨兵, 只不过master/*slave*换了地方, 如下

sentinel    slave    6380

sentinel    master    6382

sentinel    slave     6381

*注：若此时想要调整master/slave, 则需要手工操作, 所以为了方便起见, 建议在故障转移之前备份配置文件.*

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lpeWlqaWFueGlhbg_size_16_color_FFFFFF_t_70]: /images/20211126/b06fc75e1f514f4698f462dd588b41bf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lpeWlqaWFueGlhbg_size_16_color_FFFFFF_t_70 1]: /images/20211126/e5501ac0a3bb4037b4619fd38f1b4a91.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lpeWlqaWFueGlhbg_size_16_color_FFFFFF_t_70 2]: /images/20211126/9a45f86f6e2c42c9be5f8e8696df4a7f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lpeWlqaWFueGlhbg_size_16_color_FFFFFF_t_70 3]: /images/20211126/05bae6ec13284cbd9a20a01192109b41.png
[20190727234225365.png]: /images/20211126/288cabaecee44dbbb35bee5d2add0db2.png
[20190727234356662.png]: /images/20211126/90c1b129246f4ac592d49f266f4ff11a.png
[20190727234342249.png]: /images/20211126/8118ac06113c4b8aacb1ed5637a27b4f.png
[2019072922272691.png]: /images/20211126/88d41b9bc0374fe0a229da50d3f1e717.png
[2019072922322777.png]: /images/20211126/9067d145da5c46c69ac6594a8f378ec7.png
[20190729223259269.png]: /images/20211126/25b56fa1e1f44a7ebaf2dd4f8766fd5e.png
[20190729223502226.png]: /images/20211126/bf1d2cfa0af347f78cccc2d68757cbf9.png
[20190729223418614.png]: /images/20211126/085f07ea79eb4b2ea905335d05bc0fde.png
[20190729223533150.png]: /images/20211126/0cbbf5f177b24ea6b5e624e4c000626d.png
[20190729223800742.png]: /images/20211126/0cffe85ffb064d3c989ac874795efb2e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lpeWlqaWFueGlhbg_size_16_color_FFFFFF_t_70 4]: /images/20211126/84081854c40940fb833767e0c4f3e08f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lpeWlqaWFueGlhbg_size_16_color_FFFFFF_t_70 5]: /images/20211126/49983fc37ac042fe9e2eee852d1c7410.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lpeWlqaWFueGlhbg_size_16_color_FFFFFF_t_70 6]: /images/20211126/319539ebcc76479c8eb1c9cf74885488.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lpeWlqaWFueGlhbg_size_16_color_FFFFFF_t_70 7]: /images/20211126/4856461967834a72b67dcd80d992c780.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lpeWlqaWFueGlhbg_size_16_color_FFFFFF_t_70 8]: /images/20211126/05df0985cd9a4416aa622b8ef6808ceb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lpeWlqaWFueGlhbg_size_16_color_FFFFFF_t_70 9]: /images/20211126/19c925163bb64cffa0cad0613938f35b.png