既然我们设置了nopreempt，那么在启动keepalived的时候就有启动的顺序问题了，我们把Redis的master和keepalived的master(虽然配置文件中都是backup，但是我们是想让26这台做master的)默认设置在同一台机器上，由于在keepalived的master上面设置了nopreempt参数，所以在启动keepalived服务的时候，一定要先启动redis master的那台，因为在设置了nopreempt了，keepalived在启动后都是先进入backup状态，而脚本又设置了进入backup状态后，会连接新的对方进行数据同步，所以，在启动keepalived之前还有一个条件就是redis的master和slave中的数据必须一致。这样先启动redis的master那台的keepalived，虽然redis master会连接到redis slave同步数据，但是两边数据在刚开始的时候是一致的，并不会产生什么问题。
1 先启动26和27上的redis服务，配置27从26上面同步数据，同步完毕后，取消27的同步机制。
这个就是在27的redis上面执行slaveof 10.20.112.26 6379，等待数据同步完毕后再执行slaveos on one，让26和27的redis都保持master状态
2 接着启动26的keepalived，不要启动27的keepalived，在26和27上面各开启三个终端，观察自定义日志和系统日志状态
26的syslog
红框 19秒keepalived启动后，由于设置了不抢占，且起始状态都是backup，所以启动后keepalived先进入backup状态，进入bankup状态后，成功的执行了redis_backup.sh脚本
绿框 34秒的时候，keepalived开始向master状态转变，注意：这个时间很重要，为什么是34秒呢？默认是3秒后就开始向master状态转变，由于我们设置了advert_int 5，默认检测三次，所以15秒之后才向master转变，为什么设置间隔这么长时间呢？是为了让redis_backup.sh脚本有充足的时间执行完毕。39秒的时候成功的转变为master状态，这时候会执行redis_master.sh脚本。
26的redis-state.log
过程解释：
红框 确实如系统日志表现的那样，19秒的时候先进入backup状态，执行redis_backup.sh脚本。redis_backup是keepalived进入到backup状态时执行的脚本。进入到banckup状态，说明自身以前是master状态或者无状态，这时候会等待两秒种，让之前的slave把数据同步完，2秒钟在数据大的时候有些短，其实是可以设置的，只要小于3倍的advert_int时间就行，因为3倍的时间之后会转为master状态的。 2秒钟之后我们的redis连接到27上面(27这时候充当master)，开始进行正常的master/slave机制同步数据，也就是红框中21秒的时候。到此为止，redis_backup.sh执行完毕。
绿框 由于设置了不抢占，所以过了3倍的advert_int时间之后，开始向master状态转变，这个转变过程需要的时间是不固定的，在上面的日志中需要5秒，正式的成为master状态，这时候会执行redis_master.sh脚本，脚本指定需要到27的redis上同步数据(27在红框中的时候是充当master的)，你可以看到已经有连接了，那是因为在红框中已经连接过一次了，我设置的是同步10秒钟之后断开和27的连接，可以看到49秒的时候执行了slaveof no one命令，断开了和27的连接，把26自身的redis提升为master，这时候数据也是最新的了。
3 待26的各项进程都ok后，我们开始启动27上面的keepalived服务
27的syslog
红框 40秒的时候启动27的keepalived，由于默认都是backup，所以直接进入backup状态，由于27的优先级比26低，所以27并不会过度到master状态，这时候26是master状态了。在backup状态执行了redis_backup.sh脚本。
27的redis-state.log
红框 在进入backup状态后，默认之前是master状态或者无状态，所以等待15秒，让26把数据同步完(26这时候充当backup)，在15秒之后，开始向backup转变，开始执行slaveof 10.20.112.26 6379，作为26的slave。
下面要模拟故障3：
1 kill掉26的redis进程，保持keepalived进程。(模拟3)
26的syslog
红框 可以看到检测脚本chk_redis发现redis已经宕掉，降低了26的keepalived的优先级，导致26进入backup状态，开始执行redis_backup.sh监控脚本
26的redis-state.log
红框 由于redis我是kill掉的，所以必然不能进行数据同步了，不过这并不影响使用。
27的syslog
绿框 可以看到27转变到master状态，并且执行了redis_master.sh脚本
27的redis-state.log
绿框 由于26的redis是kill掉的，所以��使27转变到master状态也不能去26同步数据，当然27也等不到26连接上来，不过并不影响我们使用。
下面要模拟故障2：
2 kill掉26的keepalived进程，保持redis进程。(模拟2)
26的syslog
红框 是keepslived的启动过程，在模拟3中已经详细分析过
绿框 是kill掉keepalived进程后的日志。
26的redis-state.log
红框 是keepalived启动过程中执行的监控脚本日志，前面模拟3中已经详细分析过
绿框 是keepalived进程kill掉之后，执行的监控脚本日志，在等待27同步完数据后，作为27的slave连接上去。
26的redis info
可以看到master/slave的转变过程
27的syslog
红框 是keepalived作为backup的启动过程，在模拟3中已经分析过。
绿框 是kill掉26的keepalived进程后，27转变为master时的日志，执行了redis_master.sh脚本。
27的redis-state.log
红框 是keepalived启动时执行的监控脚本日志，由于开始是backup的，所以没有过多的状态切换过程。
绿框 是26的keepalived进程被kill掉之后，27转变为master时执行的脚本日志，由于keepalived挂了，但是26的redis进程还在，所以先和26进行数据同步，完成之后再把自己提升为redis master。
27的redis info
可以看到redis的master/slave变化过程
以上就是我所能想到的keepalived+redis HA方案中需要注意的地方。