3

我工作的公司希望在我们支持 SQL Server 的应用程序中使用 Always on 可用性组架构。我们有 3 个数据库直接安装，其中一个是按配置分区的，我们目前使用 MSDTC 来协调这三个数据库之间的事务，即如果提交到数据库 A 和 B，并且 A 提交成功，B 上的失败意味着回滚A 和 B 而不是 B。

当我们看到这篇文章时遇到了一个问题

据我了解，这基本上意味着 MSDTC 在 Always on 可用性组模式中不受支持。我在 SQL Server 2012 中找不到替代品

所以我的问题是：

  1. 我们有哪些选择（搁置或开源产品/代码更改）？
  2. 在此设置中运行 MSDTC 的具体影响是什么（完全崩溃/丢失事务）？

在此先感谢，非常感谢您的帮助。多尔

4

1 回答 1

2

我最近问了一个类似的问题：https ://dba.stackexchange.com/questions/47108/alwayson-ag-dtc-with-failover

> 我们有哪些选择（搁置或开源产品/代码更改）？

我认为你有两个选择：

  1. 更改您的应用程序，使其不需要 DTC。
  2. 更改您的数据库设置，使其不使用可用性组。

在我的情况下，我们使用的是商业应用程序，因此选项 1 不可行。我们目前正在使用数据库镜像，根据最近的研究，我现在明白这也不支持。

我的收获是有可能让它发挥作用。但这并不简单，它会让你处于不受支持的境地——这对我们来说是不可接受的。因此，我计划着眼于利用日志传送，并从使用热备用（带镜像）或热备用（带日志传送）进行更改。

在此设置中运行 MSDTC 的具体影响是什么（完全崩溃/丢失事务）？

如果您决定将 DTC 与可用性组或镜像结合使用，您将面临在故障转移方案中数据损坏/不一致的风险。您引用的文章提供了一个很好的例子，说明了这种情况是如何发生的。

诚然，使用日志传送可能会出现同样的问题。我打算提出的论点是，通过日志传送，我们将能够滚动到特定的时间点，并且我们可以确保我们只移动到我们知道一切都是一致的时间点。

我们使用的商业应用程序不支持高可用性。这是我们试图使其高度可用的尝试。

于 2013-07-27T14:04:14.987 回答