Redis主从和HA配置

 

1同步原理

摘自：http://www.cnblogs.com/stephen-liu74/archive/2012/03/30/2364717.html

 

“下面的列表清楚的解释了Redis Replication的特点和优势。

   1). 同一个Master可以同步多个Slaves。

   2). Slave同样可以接受其它Slaves的连接和同步请求，这样可以有效的分载Master的同步压力。因此我们可以将Redis的Replication架构视为图结构。

   3). Master Server是以非阻塞的方式为Slaves提供服务。所以在Master-Slave同步期间，客户端仍然可以提交查询或修改请求。

   4). Slave Server同样是以非阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis则返回同步之前的数据。

   5). 为了分载Master的读操作压力，Slave服务器可以为客户端提供只读操作的服务，写服务仍然必须由Master来完成。即便如此，系统的伸缩性还是得到了很大的提高。

   6). Master可以将数据保存操作交给Slaves完成，从而避免了在Master中要有独立的进程来完成此操作。

 

    在Slave启动并连接到Master之后，它将主动发送一个SYNC命令。此后Master将启动后台存盘进程，同时收集所有接收到的用于修改数据集的命令，在后台进程执行完毕后，Master将传送整个数据库文件到Slave，以完成一次完全同步。而Slave服务器在接收到数据库文件数据之后将其存盘并加载到内存中。此后，Master继续将所有已经收集到的修改命令，和新的修改命令依次传送给Slaves，Slave将在本次执行这些数据修改命令，从而达到最终的数据同步。

    如果Master和Slave之间的链接出现断连现象，Slave可以自动重连Master，但是在连接成功之后，一次完全同步将被自动执行。”

2主从配置

Redis的主从Replication配置非常简单，只需将原配置文件新拷贝一份后，做少量修改。

         cpredis.conf redis-2.conf

         viredis-2.conf

默认端口号为6379，修改端口号为6381。

假设Master为本机端口6380上的服务，加入配置：

                  slaveof 127.0.0.1 6380

 

这样新建立的6381端口上的服务就作为6380的slave了。

3测试验证

可以在redis-cli中执行info replication来查看Replication信息。下面来测试一下：

在6380上set的键值对会同步到6381上。

 

但是在6381上执行set命令时会报错，因为slave默认是只读的。

4 RedisHA

4.1手动切换

下面手动实现一下当Master挂机时，从Slave中选举出一个Redis服务切换成Master。

首先再配置一个6382服务，同样将6380作为Master。

 

杀掉6380服务的进程后，只剩6381和6382两个Slave了。在6381客户端上执行slaveof no one，在6382客户端上执行slaveof 127.0.0.1 6381。这样新的主从关系就建立了。

 

如果原master恢复服务了，可以在原master上执行slaveof 127.0.0.1 6381，这样原master就变成现在master的slave了。

4.2自动切换

Redis 2.4+自带了一个HA实现Sentinel。下面是简单介绍：

“Redis-sentinel是Redis的作者antirez在今年6月份完成的，因为Redis实例在各个大公司的应用，每个公司都需要一个Redis集群的管理工具，被迫都自己写管理工具来管理Redis集群，antirez考虑到社区的急迫需要(详情)，花了几个星期写出了Redis-sentinel。”

 

首先启动三个Sentinel实例都去监听Master的状态。

sentinel.conf配置文件为：

port 26379

sentinel monitormymaster 127.0.0.1 6380 2

sentinel down-after-milliseconds mymaster 30000

sentinel can-failover mymaster yes

sentinel parallel-syncs mymaster 1

sentinel failover-timeout mymaster 900000

另两个sentinel.conf配置除了port为26479和26579外，其他四项配置完全相同。

 

选举算法如下：

“每个sentinel实例都持有其他的sentinels信息，在Leader选举过程中(当为leader的sentinel实例失效时，有可能master server并没失效，注意分开理解)，sentinel实例将从所有的sentinels集合中去除“can-failover = no”和状态为SDOWN的sentinels，在剩余的sentinels列表中按照runid按照“字典”顺序排序后，取出runid最小的sentinel实例，并将它“投票选举”为Leader，并在其他sentinel发送的“is-master-down-by-addr”指令时将推选的runid追加到响应中。每个sentinel实例都会检测“is-master-down-by-addr”的响应结果，如果“投票选举”的leader为自己，且状态正常的sentinels实例中，“赞同者”的自己的sentinel个数不小于(>=) 50% + 1,且不小与<quorum>，那么此sentinel就会认为选举成功且leader为自己。

在sentinel.conf文件中，我们期望有足够多的sentinel实例配置“can-failoveryes”，这样能够确保当leader失效时，能够选举某个sentinel为leader，以便进行failover。如果leader无法产生，比如较少的sentinels实例有效，那么failover过程将无法继续。

在Leader触发failover之前，首先wait数秒(随即0~5)，以便让其他sentinel实例准备和调整(有可能多个leader??),如果一切正常，那么leader就需要开始将一个salve提升为master，此slave必须为状态良好(不能处于SDOWN/ODOWN状态)且权重值最低(redis.conf中)的，当master身份被确认后，开始failover”

 

可以看到三个Sentinel都监听到Master和Slave，并且三者之间也建立了通信。

 

现在手动杀掉6380进程，可以看到三个Sentinel实例都监测到了Master挂掉，并通过投票选举出新的Master。

 

第一个Sentinel的详细输出如下：

[19247] 11 Sep 21:29:37.321 * +sentinelsentinel 127.0.0.1:26479 127.0.0.1 26479 @ mymaster 127.0.0.1 6380

[19247] 11 Sep 21:29:56.603 * +sentinelsentinel 127.0.0.1:26579 127.0.0.1 26579 @ mymaster 127.0.0.1 6380

[19247] 11 Sep 21:31:50.737 # +sdown mastermymaster 127.0.0.1 6380

[19247] 11 Sep 21:31:50.938 # +odown mastermymaster 127.0.0.1 6380 #quorum 3/2

[19247] 11 Sep 21:31:51.041 #+failover-triggered master mymaster 127.0.0.1 6380

[19247] 11 Sep 21:31:51.041 # +failover-state-wait-startmaster mymaster 127.0.0.1 6380 #starting in 7113 milliseconds

[19247] 11 Sep 21:31:58.200 #+failover-state-select-slave master mymaster 127.0.0.1 6380

[19247] 11 Sep 21:31:58.301 #+selected-slave slave 127.0.0.1:6382 127.0.0.1 6382 @ mymaster 127.0.0.1 6380

[19247] 11 Sep 21:31:58.301 *+failover-state-send-slaveof-noone slave 127.0.0.1:6382 127.0.0.1 6382 @mymaster 127.0.0.1 6380

[19247] 11 Sep 21:31:58.403 *+failover-state-wait-promotion slave 127.0.0.1:6382 127.0.0.1 6382 @ mymaster127.0.0.1 6380

[19247] 11 Sep 21:31:59.011 #+promoted-slave slave 127.0.0.1:6382 127.0.0.1 6382 @ mymaster 127.0.0.1 6380

[19247] 11 Sep 21:31:59.011 #+failover-state-reconf-slaves master mymaster 127.0.0.1 6380

[19247] 11 Sep 21:31:59.111 * +slave-reconf-sentslave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380

[19247] 11 Sep 21:32:00.019 *+slave-reconf-inprog slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.16380

[19247] 11 Sep 21:32:00.019 *+slave-reconf-done slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.16380

[19247] 11 Sep 21:32:00.117 # +failover-endmaster mymaster 127.0.0.1 6380

[19247] 11 Sep 21:32:00.117 #+switch-master mymaster 127.0.0.1 6380 127.0.0.1 6382

[19247] 11 Sep 21:32:00.219 * +slave slave127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6382

[19247] 11 Sep 21:32:00.828 * +sentinelsentinel 127.0.0.1:26579 127.0.0.1 26579 @ mymaster 127.0.0.1 6382

[19247] 11 Sep 21:32:01.029 * +sentinelsentinel 127.0.0.1:26479 127.0.0.1 26479 @ mymaster 127.0.0.1 6382

 

现在操作新Master 6382保存键值对，就可以同步到6381了。

参考资料

1 Sentinel官方网址

http://redis.io/topics/sentinel

 

2 Redis核心解读–集群管理工具(Redis-sentinel)

http://www.wzxue.com/redis%E6%A0%B8%E5%BF%83%E8%A7%A3%E8%AF%BB-%E9%9B%86%E7%BE%A4%E7%AE%A1%E7%90%86%E5%B7%A5%E5%85%B7redis-sentinel/

 

3 Redis Sentinel：集群Failover解决方案

http://shift-alt-ctrl.iteye.com/blog/1884370