Question

我们的导轨应用程序已经运行了好几个月。今天我们发现了一些与领导人选举不一致的问题。主要有：

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

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

一次将应用程序部署设置为1个实例，并提供/usr/bin/leader_only期望作为env var的值，但不是原来的，应该如此。（现在所有的实例都是领导者，所以他们将毫无结果地运行db：migrate并且它一次只运行1个，所以如果我们有很多实例，这将减慢我们的速度）

我们认为可能是由于代码和/或应用程序的一些问题，所以我们重建了它。没变。

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

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

Answer 1

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

另外，如前所述（领导者是第一个自动缩放组，如果它被删除我们松散领导甚至使用leader_only：true在container_commands中，db：migrate不会的工作。）

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

我没有提到细节。我们有许多非生产环境，通过弹性beanstalk自动缩放设置，我们使用定时缩放将我们的实例计数设置为夜间0，并在白天恢复到预期的1-2量。我们为开发，测试和UAT环境执行此操作，以确保我们不会全天候全速运行。因此，我们失去了领导者，从未得到回报。

根据技术的跟进：

我们有一个功能要求，以克服失去的问题第一个实例被删除时的领导者。

Answer 2

＆＃34; Elastic Beanstalk使用领导者选举来确定中的哪个实例您的工作环境将定期任务排队。每个实例尝试通过写入DynamoDB表成为领导者。首先成功的实例是领导者，必须继续写信该表保持领导者地位。如果领导者离开了服务，另一个实例迅速取而代之。＆＃34;

Answer 3

在Elastic Beanstalk中，您可以将命令运行到单个＆＃34;领导者＆＃34;实例。只需创建一个包含container_commands的.ebextensions文件，然后进行部署即可。确保将leader_only值设置为true。

例如：

<强> .ebextensions / 00_db_migration.config

container_commands:
  00_db_migrate:
    command: "rake db:migrate"
    leader_only: true

此命令的工作目录将是您的新应用程序。

leader实例环境变量将由Elastic Beanstalk代理在更新时设置。它不会导出到普通的ssh shell。