不停止更新生产IIS网站和SQL Server数据库

Question

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

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

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

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

我们以为使用发布候选网站。我们计划暂时使用这个RC网站。首先，我们更新RC站点，然后交换RC和生产网站之间的绑定。但是这次数据库是问题。因为我们可以更改数据库模式，而旧数据库不能使用新数据库。所以，如果我们使用临时数据库的临时站点，将会有数据丢失。另外，如果临时站点使用旧生产数据库，则更新后的网站将无法与旧数据库一起使用。所以我需要一个可靠的解决方案来解决这个问题。

Answer 1

这比你想象的更复杂的订单。这个具体是关于HA的而不是，也不关于连续整合。这些都不会提供你需要的东西，它们只是更复杂的难题的一部分。

简而言之，就是不可能以透明的方式编写代码更改/忘记模式更改，因为它们发生在。充其量，您可以用支持v。N和v。N + 1架构的方式编写代码，这本身就是一个很大的挑战。但是不可能以支持模式的方式编写代码，因为它将从v.N转换到v.N + 1。由部署引发的模式更改对于在模式上运行的代码必须是原子的。由于模式更改本身不可能是原子级的，因此升级有两种可能的途径：

• 在模式更改期间使代码脱机。这就是你现在正在做的，并且是最安全的方法。当然，这意味着服务可用性停机时间和运行风险，您已经体验过（升级失败，长时间升级等）。这种方法的一个变种是将服务重定向到只读的数据副本，并提供降级的服务体验（停机期间不可能进行更改），这可能会或可能不会被接受，具体取决于业务细节。

• 待机升级。这意味着您可以拍摄服务数据的快照（各种HA解决方案可以提供即装即用的备用快照，例如日志传送）。升级快照，然后将发生在实际服务数据上的所有事务应用到升级后的快照。这总是很棘手，因为它需要一种技术来检测，捕获和应用更改（例如更改跟踪，复制，自定义解决方案等）。和需要将每个更改转换为新的升级架构。一旦升级后的模式与来自主服务的更改保持同步，服务就可以重定向到升级后的模式。这种重定向也比听起来复杂得多。对于选择切断旧架构并停止接受新更改的时刻，同时确保将全部更改应用于新升级的架构数据库本身就是一项挑战。另一个挑战是解决代码理解升级前和升级后模式版本的冲突。正如我所说，开发处理两者的代码是有问题的和容易出错的，所以一种解决方案是再次使服务在短时间内脱机并替换代码。另一种解决方案是备用服务，运行代码处理升级后数据库模式并连接到升级后数据库，并将活动请求重定向到您的备用升级服务。

而且我甚至没有触及服务交互的棘手问题，当一个更大的部署的解决方案的一个特定的服务必须进行升级。这是当service API protocol back compatibility扮演主角时允许升级后服务与其对等服务一起玩。

最终没有任何银弹。我见证了单机大型数据库部署需要花费周才能推出N + 1版本，并通过转录复制将升级后的数据库架构与升级前数据库中的更改连续提供。我目睹了成千上万台部署N + 1版本的机器的分阶段部署，这是一段复杂的舞蹈，它可以在几天内改变代码和数据的变化，以实现升级后的全部功能。这个问题只是简单的硬。

Answer 2

描述高可用性解决方案（HA）。 HA解决方案非常昂贵，并且很快就会过度消耗。您需要为您的应用程序和数据库服务器提供冗余，这意味着要设置一个数据库集群。所有这些都会增加您花费部署更改的时间，但是权衡是您的应用始终可用。

部署的主要内容是具有可重复的过程。所以我最好的建议是尽可能地编写脚本或自动化。

Answer 3

这就是Azure所擅长的。 Azure云平台允许登台服务器和生产服务器。您可以对其进行设置，以便在您将更改提交到Git或TFS时自动将其推送到分段或生产服务器。您也可以设置为手动推送更改。像Entity Framework这样的大多数ORM库都有迁移支持。

有大量的详细信息那里关于这一主题，如： Azure seamless upgrade when database schema changes Staging or Production Instance?