数据库迁移“失败”有什么意义？

Question

由于所有数据库都应该是，我们的源代码使用源代码控制进行版本控制。使用由Red Gate的比较工具生成的一系列SQL脚本升级数据库，这与在最近涌现的众多数据库迁移框架中的“向上”迁移基本相同。

但是这些框架中“向下”迁移的重点是什么？通常，“向上”迁移的代码非常复杂（通常随着功能的发展而进行复杂的数据迁移），我很难看到为“向下”迁移而必须反向编写它的目的。这当然是我从未感受到的东西。我在这里错过了什么......？

Answer 1

这里的相关问题似乎是：

• 为什么脚本回滚会比升级前的备份完全恢复数据库更好？

我可以想到几个原因：

1. 数据库非常大 - 比如几百GB - 而且您的公司无法承担完全恢复所涉及的停机时间和/或管理开销。

2. 引入了一个错误，直到生产一两周才发现。如果您以前从未体验过这一点，那么您很幸运。一旦您在新数据库中获得了一周的交易，您就可以忘记从备份中恢复。

3. 直到发布时月才发现该错误。换句话说，您甚至不再拥有备份，并且您正式处于损害控制/灾难恢复模式。我从来没有经历过这个，但我听过故事。这是一个可怕的想法 - 你如何撤消所做的所有损害？在这种情况下，您的降级可能并不完美，但它可能仍然比替代方案更好。

4. 相比之下，数据库更改可能很简单 - 在这里添加几行，在那里添加几个触发器。在这种情况下，脚本化回滚将比恢复时间少 。有些事情需要花费数小时才能升级 - 例如创建新索引或添加新列 - 可能只需要几秒钟就可以降级（丢弃）。

5. 您正在部署到客户站点。他们中的一些可能根本没有备份（是的，这很可怜，但你无能为力）。如果其中一个需要回滚，这是您唯一的选择。

降级脚本可能还有其他原因 - 这只是我的头脑。

Answer 2

客户：“我们不喜欢新版本，想要回到旧版本。”

Answer 3

1. 回滚。你把所有东西都投入到生产中，并且它会逐渐减少迁移，这是一个很好的回滚安全网。
2. 或者您正在使用多个代码分支进行开发 - 您可以在不同版本之间来回切换内容。

Answer 4

如果升级，随后将数据添加到要保留的数据库中，则回滚脚本（只要它设计为这样）应该实现此目的，而如果您只是恢复备份，则会丢失它

但是你可以通过恢复备份并使用SQL数据比较来复制其他数据来实现上述目标。