单数据库升级(从应用程序端)，它是“始终打开”的一部分

Question

我们有一项任务要根据应用程序规划一个始终处于数据库上的升级(模式升级)。作为应用程序升级的一部分，连接的应用程序将执行很少的模式更改。

数据库大小: 450 GB

始终处于模式:同步(与自动故障转移)

1. 如果不把它从AG中移除，这能做到吗？(这是App side的请求)
2. 这会导致与次副本同步状态的任何问题吗？

我们必须给出一个适当的停机时间，取决于这一点，我们不想走一条路，走另一条路。

现在我们的计划是：

1. 从AG中删除Db。
2. 执行db升级(架构更改)。
3. 用新的备份将数据库添加回AG。

Answer 1

我不知道你为什么需要休息。除了隔离和模式锁之外，更改一个表与更改数据没有什么不同--它会被记录下来，发送到第二个文件，等等。这从来都不是即时的，但它往往非常接近，以至于应用程序根本不会注意到这一点。

除非两个副本是同步的，否则我们不允许应用程序继续运行。此外，我们也有点担心数据库的大小。如果是为了一个小的数据库，我们就会像你提到的那样直截了当。所以，在不破坏AG的情况下继续下去是可以的吗？

这是100%不可能在完全相同的时刻更新主和次要，所以让我们把这个要求立即抛出窗口。在这种情况下，应用程序可能需要停机时间，这可以通过其他方式完成，但我指的是数据库停机时间。我认为架构更改不一定需要从AG中提取数据库。除非您已经有其他配置/延迟问题，否则同步应该非常快，您能确切解释为什么有关副本同步和应用程序运行的规则吗？当然，在任何情况下，模式更改都是向后兼容的？

所以你是说我提到的步骤很好？是的，我的意思是停工时间也是一样的。这也是为自动故障转移设置的，这就是为什么我们希望在进行任何更改之前停止AG。

不，我仍然不知道为什么您的步骤包括从AG中删除数据库，并将其与一个新的备份一起放回。故障转移似乎是不相关的，除非您的架构更改非常糟糕，在部署更改时会导致故障转移。另外，一旦您将数据库添加回AG中，则辅助程序将不同步，直到它再次赶上，因此这似乎仍然违反了您关于保持应用程序运行的不必要规则。

拿到你的点亚伦了。我完全同意。这是一个关键的供应商管理的应用程序，我们不确定在升级过程中会发生什么样的模式更改。我们正在进行讨论，以最终确定一个完整的证明计划，以避免任何打嗝。万一他们想退却的话，次要的人可以救我们。这是我们想走那条路的另一个原因。

当然，在你目前的计划中，第二是帮不上忙的。如果将数据库从AG中提取出来，则没有第二次数据库。