我们在前几天在我们的詹金斯工作中失败了,当我们查看数据库时,发现该脚本已应用,但脚本的“schema_version”表中未创建条目。我们知道这个脚本需要很长时间才能应用(修改一个包含大约70M行的表),并且我们使用了SQL语法,至少使得这个修改不会被阻塞(对于mysql,ALGORITHM = INPLACE)。然而,当脚本完成后,flyway返回失败jenkins并且没有运行任何脚本。Flyway虚假失败
我们通过gradle插件(版本3.2.1)运行flyway并使用ansible来调用gradle任务。詹金斯称这种称之为飞行路线的gradle具有可靠性。不知道这是由于飞路超时或者可能导致的。我们希望在生产中不会再发生这种情况。
我们的解决方法是手动将条目置入schema_version,以便脚本不会重新运行,然后重新应用迁移,以便脚本运行后运行。
我们看了一下db,同时出现了一个巧合的连接尖峰,所以它可能会遇到连接限制,但我想如果连接运行脚本,连接就已经打开了。
从詹金斯消毒,输出的是如下:
TASK: [flyway | run flywayMigrate] ********************************************
<db.server> REMOTE_MODULE command gradle -b /opt/product/rc/flyway-17.5.32.37534.d2bac4a/extracted/flyway.gradle flywayMigrate
failed: [db.server] => {"failed": true, "parsed": false}
invalid output was: SUDO-SUCCESS-plqsdlxwlfkdsujlxdafldpasvtllis
MySQL是否启用了某种日志记录?复制/增量备份最有可能会是binlog。如果是,请检查MySQL日志(例如,binlog使用'mysqlbinlog'实用程序来转储它),并尝试了解当时MySQL正在执行的操作。请注意,binlog只会记录实际修改内容的更新,因此这不会给您提供完整图片,但可能会提供一些线索。 –
感谢您的提示。由于这只发生在我们的生产服务器上,我实际上没有访问权限(为了安全起见锁定)。脚本在我有权访问的CERT环境中成功,所以这没有用。我可能可以让某人登录到生产环境,但这是令人惊讶的挑战哈哈。 – gnomed