Flyway虛假失敗

我們在前幾天在我們的詹金斯工作中失敗了，當我們查看數據庫時，發現該腳本已應用，但腳本的「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

來源

2016-04-28 gnomed

MySQL是否啓用了某種日誌記錄？複製/增量備份最有可能會是binlog。如果是，請檢查MySQL日誌（例如，binlog使用'mysqlbinlog'實用程序來轉儲它），並嘗試瞭解當時MySQL正在執行的操作。請注意，binlog只會記錄實際修改內容的更新，因此這不會給您提供完整圖片，但可能會提供一些線索。 –

感謝您的提示。由於這隻發生在我們的生產服務器上，我實際上沒有訪問權限（爲了安全起見鎖定）。腳本在我有權訪問的CERT環境中成功，所以這沒有用。我可能可以讓某人登錄到生產環境，但這是令人驚訝的挑戰哈哈。 – gnomed

這是最有可能是由於遷徙路線使用的元數據表被你的基礎設施的某些部分關閉了連接（DB，代理，... ），導致Flyway在長時間遷移完成後無法將該行寫入表中。

來源

2016-05-02 06:26:27

Flyway虛假失敗

回答

相關問題