amazon-web-services - 弹性 beantalk 领导人选举的问题

Question

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

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

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

将应用程序部署设置为一次 1 个实例，并提供 /usr/bin/leader_only 期望的值作为 env var 工作，但不是过去和应该的那样。 (现在所有实例都是领导者，所以它们将毫无结果地运行 db:migrate 并且一次为 1，所以如果我们有很多实例，这会减慢我们的速度)

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

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

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

Answer 1

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

Also, as explained before(Leader is the first instance in an auto-scaling group and if it is removed we loose the leader and even using the leader_only : true in container_commands, db:migrate doesn't work.)

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

我没有提到一个细节。我们有很多非生产环境，通过elastic beanstalk autoscaling settings，我们使用timed scaling将我们的实例计数在晚上设置为0，并在白天备份到预期的1-2个数量。我们为我们的开发、测试和 UAT 环境执行此操作，以确保我们不会全天候 24/7 运行。因此，我们失去了领导者，再也没有找回来。

根据技术人员的跟进:

We have a feature request in place to overcome the issue of losing the leader when very first instance is deleted.