redis sentinel auto-failover 由于配置文件导致的问题

昨天在给新环境搭建redis 集群环境时，遇到了一件乌龙事，浪费了整整一天时间，

原因是配置文件copy时，没有删掉其中一条主从关系造成的，觉得很有可能遇到

现在记录下：

环境：

1、 两台linux虚拟机，10.10.100.42,10.10.100.76，分别用42,76表示。

2、一共配置 三对主从实例，三个哨兵实例，3个sentinel都同时检测3对主从：

     master1: 10.10.100.76:38001

     对应的slave:10.10.100.76:38002、10.10.100.76:38003

     master2: 10.10.100.76:38004

     对应的slave:10.10.100.76:38005、10.10.100.76:38006

     master3: 10.10.100.42:38001

     对应的slave:10.10.100.42:38002、10.10.100.76:38003

     sentinel：

     10.10.100.76:39001、10.10.100.76:39002、10.10.100.42:39001

      

问题现象描述：

1、由于42上是原有就搭建的，所以一开始为了验证42上的是否正常，

 模拟了sentinel的自动故障转移，先在down掉了42上的38001实例，结果发现38002被提升为了主机；再启动38001，38001slaveof38002,自动故障转移成功。

2、照着原42上的配置，copy到76上，并该掉相应的端口，路径等。

    启动实例：

a) 为了检验76上master1这组主从是否正常自动故障转移，先down掉76上的38001，发现38002被提升为主机；再启动38001，38001slaveof38002,自动故障转移成功。

b) 为了检验76上master2这组主从是否正常自动故障转移，先down掉76上的38004，自动故障转移失败。

3、由于master2自动故障转移失败，检查配置文件，没发现有什么问题，于是down掉了master2的两个从，并重启这三个实例，发现还是不行。

4、于是比较master1和master2的配置文件，未发现问题。

5、由于怕master1的成功是偶然的，于是再对master1做自动故障转移实验，down掉38002，结果发现自动故障转移失败。

。

。

。

6、接下来经过很久的问题查找，配置文件修改，路径修改，发现master1中38002的salveof存在，且是10.10.100.42。

原因：

出现这个问题，结果回想（由于一些配置文件和日志都被删掉），原因是

1、42上经过 auto-failover 后，主从关系配置文件为

      38001： slaveof 10.10.100.42:38002

      38003： slaveof 10.10.100.42:38002

2、由于一开始是 38001为master，我心里一直以为是，而且38001的slaveof是写在配置文件最下面，没有发现，就没有删除。

3、然后把这些配置文件cpoy到了76上，只改了一些地址和端口，最后这条主从关系没有删除，所以变成了主备-主备了

4、后来经过多次的重启，修改配置，结果变成了：

76下38001和76下38003属于 42下38002的slave，这个关系被记录在sentinel里

即使我在76的38001和38003配置文件里删掉主从关系，一旦这两个实例启动，都会被sentinel重写，维持这个关系。

教训：

1、sentinel启动时，根据master的名称、地址端口，将master的slaves都写到了sentinel的配置文件里，

如果需要手动修改主从关系，必须先停掉sentinel，再停掉需要修改的实例来修改配置文件。

不然即使修改好了，只要实例一启动，就会被sentinel发现，并重写主从关系。

2、由于集群，需要配置多个redis实例，实例的配置文件大同小异，一般都会copy,因此，在copy的时候：

 要检查：端口、路径、主从关系；

还要特别注意在最下面，被sentinel写入的一些配置。

3、不同主机上的实例最好把端口也配得不一样，因为第一次76故障转移虽然执行了，但是是和42上的38002执行的，因为我预期的结果是主机为38002，看到了端口号，没去注意host是10.10.100.42，导致之后的一系列问题，越改越麻烦了。