首先,我们必须将用户重定向到维护页面,因此网站暂停了一段时间.
其次,如果在更新时出现问题,我们必须回到旧网站,因为我们不能长时间将网站置于维护模式.
因此,我正在寻找一个可靠的解决方案来更新IIS网站和sql Server数据库,而不会丢失数据并使用维护模式.有没有办法做到这一点？大型网站如何做到这一点,没有数据丢失和暂停.
我们曾想过使用候选发布网站.我们计划暂时使用这个RC网站.首先,我们更新RC站点,然后交换RC和生产网站之间的绑定.但这次数据库出了问题.因为我们可以更改数据库架构,而旧版本无法使用新数据库.因此,如果我们使用临时数据库的临时站点,则会丢失数据.此外,如果临时站点使用旧的生产数据库,则更新的网站将无法与旧数据库一起使用.所以我需要一个可靠的实用解决方案来解决这个问题.
解决方法
根本无法以对模式更改透明/无视的方式编写代码更改.在最好的情况下,您可以以支持v.N和v.N 1的架构的方式编写代码,这本身就是一个很大的挑战.但是,当它从v.N过渡到v.N时,以支持模式的方式编写代码是不可能的.部署引起的模式更改对于在模式上运行的代码必须是原子的.由于架构更改本身不能是原子的,因此升级有两种可能的途径：
>在架构更改期间使代码脱机.这就是您现在正在做的事情,也是最安全的方法.当然,它意味着服务可用性停机并运行您已经遇到的风险(升级失败,冗长升级等).此方法的一种变体是将服务重定向到数据的只读副本,并提供降级的服务体验(在停机期间无法进行更改),这可能是也可能是不可接受的,具体取决于业务细节.
>待机升级.这意味着您可以拍摄服务数据的快照(各种HA解决方案可以提供开箱即用的备用快照,例如日志传送).升级快照,然后将实际服务数据上发生的所有事务应用于升级后的快照.这总是很棘手,因为它需要一种技术来检测,捕获和应用更改(例如,更改跟踪,复制,自定义解决方案等),并且需要将每个更改转换为新的升级模式.一旦升级的模式与主服务的更改保持同步,就可以将服务重定向到升级的模式.这种重定向也比听起来要复杂得多.对于选择切断旧架构并停止接受新更改的时刻,同时确保所有更改都应用于新升级的架构DB本身就是一项挑战.另一个挑战是解决代码理解升级前和升级后架构版本的冲突.正如我所说,开发处理这两者的代码是有问题且容易出错的,因此一种解决方案是再次使服务脱机并更换代码.另一种解决方案是使用备用服务,运行代码来处理升级后的数据库架构并连接到升级后的数据库,并将实时请求重定向到备用,升级的服务.
当一个更大的部署解决方案的特定服务必须升级时,我甚至没有触及服务交互的棘手主题.这是service API protocol back compatibility扮演主要角色,允许升级后服务与其对等服务一起发挥作用.
最终,没有任何银弹.我目睹了单机大型数据库部署,花了数周时间推出版本N 1,转录复制通过升级前数据库的更改连续提供升级后的数据库架构.我目睹了数千台机器分阶段部署N1版本的部署,作为在几天内实现代码和数据更改的复杂舞蹈,以实现升级后的全部功能.这个问题很难解决.
