redis哨兵故障转移后返回老主人答案

【问题标题】：Return old master after redis sentinel failoverredis哨兵故障转移后返回老主人
【发布时间】：2018-07-05 15:45:51
【问题描述】：

我有 3 盒 redis sentinel 设置：

 CLIENT (connects to S1)
          |
          ↓
       +----+
       | M1 | us-east-1
       | S1 |
       +----+
          |
+----+    |    +----+
| R2 |----+----| R3 |
| S2 |         | S3 |
+----+         +----+
us-east-2      us-west-2

M1 - Master
S1 - Sentinel 1
S2 - Sentinel 2
S3 - Sentinel 3
R2 - First slave (R=replica)
R3 - Second slave

在我的主人去世后，哨兵故障转移到 R2。我将 M1 带回联机（清除了一些磁盘空间），现在 M1 还活着并且很好，但它是 R2 的奴隶。是否有一种自动方式（或半自动方式）让 M1 再次成为主服务器，R2 成为 M1 的从属设备，我的流量再次使用 M1 作为主 redis 实例？

基本上我想恢复到故障转移之前的状态。

目前发生的情况是它选择 R2 作为主设备并将其重新配置为：

CLIENT (connects to S1)
          |
          ↓
       +----+
       |[R2]| us-east-2
       | S2 |
       +----+
          |
+----+    |    +----+
|[M1]|----+----| R3 |
| S1 |         | S3 |
+----+         +----+
us-east-1      us-west-2

当我手动进行故障转移时，它会将 R3 提升为主服务器。（这是意料之中的）。

但是当我再次手动进行故障转移时，它会提升 R2，但我希望它会提升 M1。

所有连续的故障转移都在 R2 和 R2 之间轮换（同时始终保持 M1 作为其中任何一个的从属）。

我的 M1 从属优先级未指定，因此这意味着它是默认值 100。我的 R2 从属优先级是 200，R2 是 300。这让我认为它应该旋转所有 3 个盒子，但在初始故障转移后它只旋转 R2 和 R3。

在我看来，这就像一个哨兵错误

【问题讨论】：

您找到解决方案了吗？我有同样的问题，但我尝试停止新的 Master 和 Slave 以将其强制到原来的 master，但随后哨兵说“failover-abort-no-good-slave master mymaster”我怀疑这是仲裁的问题，所以我尝试杀死原来的主人，看看杀死另一个主人是否也无法找到剩下的奴隶，但它奏效了。所以出于某种原因，原来的主人不再被视为一个好奴隶。我怀疑你可能有同样的情况。
@Adriaan 我还没有找到解决方案，我只是运行旧设置。每当发生故障转移时，它都会选择一个新的主节点。我希望它可以在 Redis 5 中运行，但没有机会尝试。
我在这个设置中运行 Redis 5，但我遇到了原始 master 没有被选举的问题。太奇怪了。这一定是一个配置问题，因为对于 Redis 或 Sentinel 来说，特定的 Redis 实例最初是主实例确实不应该产生影响。我将不得不再次分析所有实例的配置文件...
我发现了我的问题……正如我所料，这是一个配置问题。我为每个节点设置了一个密码——我测试了原始设置，并且从服务器很好地复制了。但是我从未在原始主机上设置 masterauth “PASSWRD” - 所以当它成为从机时它没有正确复制，这就是为什么 Sentinel（明智地）拒绝将它提升为主机的原因。我建议您检查您的原始 master 是否正确复制。

标签： redis high-availability redis-sentinel

【解决方案1】：

我认为 Kiddorails 的回答是正确的，但很可能您遇到了与我类似的问题，由于某种原因，您的原始主人没有正确复制。一旦我解决了我的复制问题，我可以通过发出SENTINEL FAILOVER mymaster 来循环访问我的主人。最初它只会在两个原始奴隶之间反弹，但现在我的原始主人正在正确复制，它正在循环通过所有 3 个。因此，我建议在故障转移后检查原始主服务器的复制。如果您确定它正在工作，您还可以停止另一个从属服务器，然后使用SENTINEL FAILOVER mymaster 命令强制故障转移到原始主服务器。如果失败，您就知道复制肯定有问题。

【讨论】：

这是正确的，通过日志文件我认为没有复制，因为我错过了主服务器上的masterauth：9047:S 12 Nov 16:22:30.995 * (Non critical) Master does not understand REPLCONF listening-port: -NOAUTH Authentication required，一旦我修复它并且复制发生故障转移工作！

【解决方案2】：

我不确定你为什么要首先这样做。 Redis 故障转移到 R2 并使用 at 作为 master 现在应该可以像正常的 M1 实例一样完美地工作。如果不是这样，您实际上并没有正确使用 Sentinel 来实现高可用性。

您可以使用SENTINEL failover R2 触发手动故障转移。它应该切换到 M1 或 R3。

【讨论】：

从我的图表中可以看出，R2 在俄亥俄州，而 M1 在西弗吉尼亚州。我想取回它以减少延迟@kiddorails