Redis一主二从、哨兵机制，模拟故障转移

Redis下载安装请参考redis安装。

 

一、环境搭建

1、配置文件，一主二从

#redis-16379.conf
port 16379
daemonize yes
bind 0.0.0.0
logfile "16379.log"
dbfilename "dump-16379.rdb"



#redis-16380.conf
port 16380
daemonize yes
bind 0.0.0.0
logfile "16380.log"
dbfilename "dump-16380.rdb"
slaveof 188.188.23.183 16379



#redis-16381.conf
port 16381
daemonize yes
bind 0.0.0.0
logfile "16381.log"
dbfilename "dump-16381.rdb"
slaveof 188.188.23.183 16379

 2、启动服务

./src/redis-server ./redis-16379.conf

./src/redis-server ./redis-16380.conf

./src/redis-server ./redis-16381.conf

info replication 查看主节点信息

 

主从复制原理：

1、当从服务器连接上主服务器时，从服务器向主服务器发送要进行数据同步的消息

2、主服务器接收到从服务器的请求，把主服务器的数据进行持久化，rdb文件，把rdb文件发送到从服务器，从服务器拿到rdb文件进行数据同步

3、每次主服务器进行写操作之后，主动和从服务器进行数据同步

从服务器只在第一次主动向主服务器发送数据同步请求，之后都是主服务器主动向从服务器发送数据同步。

 

3、搭建哨兵，配置文件

#sentinel-26379.conf
port 26379
daemonize yes
logfile "26379.log"
sentinel monitor mymaster 188.188.23.183  16379 2




#sentinel-26380.conf
port 26380
daemonize yes
logfile "26380.log"
sentinel monitor mymaster 188.188.23.183  16379 2




#sentinel-26381.conf
port 26381
daemonize yes
logfile "26381.log"
sentinel monitor mymaster 188.188.23.183  16379 2

4、服务启动

./src/redis-sentinel ./sentinel-26379.conf

./src/redis-sentinel ./sentinel-26380.conf

./src/redis-sentinel ./sentinel-26381.conf

 info Sentinel查看详情

---

 二、模拟故障转移

1、关闭主节点

主配置文件发生了一些变化

其中，dir只是显式声明了数据和日志所在的目录（在哨兵语境下只有日志）；known-slave和known-sentinel显示哨兵已经发现了从节点和其他哨兵；带有epoch的参数与配置纪元有关（配置纪元是一个从0开始的计数器，每进行一次领导者哨兵选举，都会+1；领导者哨兵选举是故障转移阶段的一个操作，在后文原理部分会介绍）。

2、这时候主节点已经变成了16381，如果此时立即在哨兵节点中使用info Sentinel命令查看，会发现主节点还没有切换过来，因为哨兵发现主节点故障并转移，需要一段时间。

同时可以发现，哨兵节点认为新的主节点仍然有2个从节点，这是因为哨兵在将6380切换成主节点的同时，将6379节点置为其从节点；虽然6379从节点已经挂掉，但是由于哨兵并不会对从节点进行客观下线（其含义将在原理部分介绍），因此认为该从节点一直存在。当6379节点重新启动后，会自动变成6380节点的从节点。下面验证一下。

 

在故障转移阶段，哨兵和主从节点的配置文件都会被改写。

对于主从节点，主要是slaveof配置的变化：新的主节点没有了slaveof配置，其从节点则slaveof新的主节点。

对于哨兵节点，除了主从节点信息的变化，纪元(epoch)也会变化，下图中可以看到纪元相关的参数都+1了。

 

当主节点宕机，选举从节点为主节点的规则

1、replica-priority 100 值越小优先级越高，多从服务器时，根据该参数的大小选举主节点

2、根据偏移量，也就是从节点数据最全的

3、选择runid最小的从服务，runid是redis实例启动随机生成的一个40位大小的runid

 

 

三、总结

哨兵系统的搭建过程，有几点需要注意：

• 哨兵系统中的主从节点，与普通的主从节点并没有什么区别，故障发现和转移是由哨兵来控制和完成的。

• 哨兵节点本质上是Redis节点。

• 每个哨兵节点，只需要配置监控主节点，便可以自动发现其他的哨兵节点和从节点。

• 在哨兵节点启动和故障转移阶段，各个节点的配置文件会被重写（Config Rewrite）。

• 本章的例子中，一个哨兵只监控了一个主节点；实际上，一个哨兵可以监控多个主节点，通过配置多条sentinel monitor即可实现。

• 缺点：复制延迟，所有操作都是在master节点，然后同步更新到slaver节点，当系统繁忙或者slaver节点过多，延迟更严重