sql-server - 在不停止的情况下更新生产IIS网站和SQL Server数据库

有一个使用测试数据库的测试服务器。我们在测试服务器上测试网站。如果可以，我们会将网站和数据库架构从测试服务器更新为生产服务器。但是这种方法非常痛苦且危险。

首先，我们必须将用户重定向到维护页面，因此网站暂停了一段时间。

其次，如果更新时出现问题，我们必须回到旧网站，因为我们不能长时间将网站置于维护模式。

因此，我正在寻求一种可靠的解决方案来更新IIS网站和Sql Server数据库，而又不会丢失数据并使用维护模式。有什么办法吗？大型网站如何做到这一点而又不会造成数据丢失和暂停。

我们考虑过使用候选发布网站。我们计划暂时使用此RC网站。首先，我们更新RC网站，然后在RC和生产网站之间交换绑定(bind)。但是这一次数据库出现问题了。因为我们可以更改数据库架构，所以旧的架构无法使用新的数据库。因此，如果我们使用带有temp db的临时站点，则会丢失数据。另外，如果临时站点使用旧的生产数据库，则更新的网站将无法使用旧的数据库。因此，我需要一个坚实而实用的解决方案。

最佳答案

这比您想象的要复杂几个数量级。具体而言，这与HA无关，也与连续集成无关。这些都不能满足您的需求，它们只是更复杂的难题的一部分。

根本不可能以对模式更改透明/忽略的方式编写代码更改。充其量，您可以以支持v。N和v。N + 1模式的方式编写代码，这本身就是一个很大的挑战。但是不可能以支持模式的方式编写代码，因为它从v。N过渡到v。N + 1。对于在该模式上运行的代码，由部署引起的模式更改必须是原子的。由于架构更改本身不能是原子的，因此可以认为升级有两种可能的途径:

在模式更改期间使代码脱机。这就是您现在正在做的，也是最安全的方法。当然，这意味着服务可用性将中断，并带来您已经遇到的风险(失败升级的回滚，冗长的升级等)。此方法的一种变体是将服务重定向到数据的只读副本，并提供降级的服务体验(在停机期间无法进行任何更改)，视业务具体情况而定，这可能是可接受的，也可能是 Not Acceptable 。

备用升级。这意味着您需要对服务数据进行快照(各种高可用性解决方案可能提供了现成的备用快照，例如日志传送)。升级快照，然后将在实际服务数据上发生的所有事务应用于已升级的快照。这总是棘手的，因为它需要一种技术来检测，捕获和应用更改(例如，更改跟踪，复制，自定义解决方案等)，并且需要将每个更改转换为新的，已升级的架构。一旦升级的架构是最新的，并且具有来自主服务的更改，则可以将服务重定向到升级的架构。这种重定向也比听起来复杂得多。对于选择何时切断旧模式并停止接受新更改的时刻，同时确保将所有更改都应用于新的升级模式数据库本身是一个挑战。另一个挑战是解决理解升级前和升级后架构版本的代码冲突。正如我所说，开发同时处理这两种代码的程序有问题且容易出错，因此一种解决方案是再次使服务脱机一小段时间并替换代码。另一个解决方案是拥有一个备用服务，该服务运行可处理升级后数据库架构并连接到升级后数据库的代码，并将实时请求重定向到您的备用，升级后的服务。

当必须升级更大部署的解决方案的特定服务时，我什至没有碰到服务交互的棘手问题。这是service API protocol back compatibility担当主要角色，以允许升级后的服务与其对等服务一起发挥作用的时候。

最终，没有任何 Elixir 。我目睹了单机大型数据库部署，历时数周才推出了N + 1版本，转录复制连续地为升级后DB架构提供了升级前DB的更改。我目睹了数以千计的机器分阶段部署N + 1版本的部署，这是在几天的时间内启用代码和数据更改以实现升级后的全部功能的复杂过程。这个问题仅仅是硬。

关于sql-server - 在不停止的情况下更新生产IIS网站和SQL Server数据库，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/11668971/