弹性豆茎领导者选举问题

Question

我们有一个 Rails 应用程序，几个月来一直运行良好。今天我们发现了领导人选举的一些不一致之处。主要是：

su - "leader_only bundle exec rake db:migrate" webapp

经过几个小时的反复试验（以及数十次部署），我们的开发应用程序中的任何实例都无法运行此迁移。/usr/bin/leader_only查找从未在任何实例上设置的环境变量（开发应用程序只有一个实例）。

将应用程序部署一次设置为 1 个实例并提供/usr/bin/leader_only期望的环境变量值是可行的，但不是现在和应该的那样。（现在所有实例都是领导者，因此它们将徒劳地运行 db:migrate 并且一次只有 1 个，因此如果我们有很多实例，这会减慢我们的速度）

我们认为这可能是由于代码和/或应用程序的一些问题造成的，所以我们重新构建了它。不用找了。

我什至克隆了我们的测试应用程序的 RDS 服务器，并从保存的配置创建了一个新应用程序，部署了一个新的 git 哈希，但它也从未运行 db:migrate。它尝试并显示leader_only行，但它从未运行。这就排除了代码、配置、工件。

另外，就其价值而言，它从未说过由于 RAILS_SKIP_MIGRATIONS 跳过迁移，该迁移的值为 false。这意味着它实际上正在尝试运行 db:migrate，但这并不是因为没有被描述为领导者。

Answer 1

我们一直在与 AWS 支持团队进行沟通。看来 EB 领导人选举非常脆弱。根据技术：

另外，如前所述（Leader 是自动缩放组中的第一个实例，如果将其删除，我们将失去领导者，甚至在 container_commands 中使用leader_only : true，db:migrate 也不起作用。）

发生的事情是我们丢失了所有实例。领导者选举一次，并通过实例轮换传递。如果您没有丢失所有实例，则一切都很好。

我没有提到细节。我们有许多非生产环境，通过 Elastic beanstalk 自动缩放设置，我们使用定时缩放在晚上将实例计数设置为 0，并在白天备份到预期的 1-2 数量。我们为我们的开发、测试和 UAT 环境执行此操作，以确保我们不会 24/7 全速运行。正因为如此，我们失去了领导者，再也没有找回来。

根据技术的跟进：

我们有一个功能请求来解决删除第一个实例时失去领导者的问题。