原因是配置文件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，导致之后的一系列问题，越改越麻烦了。
