架构更改会“破坏”可用性组还是透明处理？

Question

我的组织正计划采用 SQL Server 2012 可用性组，我正在尝试了解它将对我们的应用程序升级过程产生什么影响（如果有）。

我们每 8 周发布一次应用程序更新，任何发布都可能包括架构更改和/或数据迁移。

我想了解的是 HA/DR 解决方案是否透明地处理架构更改（新列、索引被添加到辅助节点），或者是否需要手动干预在每个实例上创建架构然后重新打开 Always On。

我假设的数据迁移部分是透明处理的，但也想确认一下。

我想我也做了一个笼统的假设，即基于可用性组配置的这些行为没有区别，这也可能是错误的。请告诉我。

简而言之; 在我的应用程序的任何给定版本中，我可能会通过向其中添加列来更改非常大的表（数百万条记录的数十到数百条记录）。某些列可能是“全新的”，因此它们可以使用 Enterprise Online 架构更改功能。其他列可能是现有列的重构（全名被拆分为名字和姓氏），并且将为表中的每一行运行迁移以填充这些字段。这些行为中的任何一个是否需要 DBA 更改 AlwaysOn 配置，或者这是默认处理的，并且所有辅助节点都“免费”获得 DDL 和 DML 语句？

感谢您提供的任何清晰度。

Answer 1

架构更改和数据更改本质上是相同的。它像今天的传统镜像一样工作：主要日志中发生的事情发生在次要镜像上。并非在维加斯发生的一切都必须留在维加斯。:-)

您可能需要小心的地方是，当您有一个指向主的应用程序，并且您更新它以匹配架构更改时。但是您可能有一个指向次要的不同应用程序（例如具有只读意图），并且该应用程序更改也必须同步。

另一个潜在问题是，作为可用性组一部分的数据库引用了其他数据库中的对象（例如，存储在实用程序数据库中的静态查找表）。如果这些更改并且 AG 依赖于这些对象，则您必须手动推送这些更改。作业、服务器级登录、链接服务器等也是如此——任何存在于数据库之外和/或不可交易的东西。数据库用户可能会被孤立（除了包含的用户）。我知道这可能很明显，但为了完整起见，我想明确列出它。