從schema_version刪除行是正確的做法嗎？

Question

我們使用Flyway 4通過Java API針對MySQL 5.6（不支持事務性DDL）。我們偶然遇到遷移失敗的情況，有時候會出現邏輯錯誤，有時候是因爲某人被數據庫弄得一團糟，而且事情並沒有處於正確的狀態。

所以我想知道，在這種情況下，我們是否應該從schema_version刪除行，並讓遷移重新運行，修復遷移或修復數據庫？我們通常在遷移之前運行修復以修復任何失敗的遷移，但是會添加一個新的遷移。

參見：Should I be worried about creating idempotent migrations while using Flyway?

Answer 1

我一直在使用遷飛3在過去的幾年中，並剛剛升級到4日前。到目前爲止，它已成功地管理了大約30個不同的項目，並很好地適應了交付渠道。

在這兩年的時間裏，我們肯定經歷了一些遷移，使它脫離了我們希望從歷史中消除的開發人員機器。在這些情況下，從schema_version刪除一行通常是答案 - 它比repair更快，更少流程密集，並且在我們的情況下風險較低。這就是說，它只是在開發/測試環境方面做得很好 - 所以總是存在一個不受歡迎的環境，它只接受工作遷移，沒有失敗/不受歡迎的環境。

我們絕對的目標是讓失敗的遷移成爲構建時間問題。因此遷移版本將得到驗證，遷移本身將被執行，並且一個組件將作爲組件構建的一部分針對該遷移的數據庫運行。我認爲這在很大程度上解決了我們在處理如此大量的移植管理項目時遇到的問題。

我不記得我在哪裏閱讀它，如果它是在Flyway的上下文中，但它是沿着The price we pay for this kind of automation is discipline的行 - 因此聽到類似「有人用數據庫手動」的東西肯定會是一個紅色我的標誌。

總之...

儘量減少失誤，我認爲機會是關鍵。但是，如果發生故障，將策略定義爲符合可接受的風險級別是最好的選擇 - repair和刪除schema_version都有其缺陷。