1

我从未使用过镜像、集群或其他故障转移技术。但是我正在研究调整我的 DAL 是多么容易，以便如果我的客户决定使用带或不带见证的镜像，SQLNativeClient 透明客户端重定向将为我们工作。

有人可以解释可能位于数百个桌面上的客户端应用程序的实用过程，这些桌面将连接到镜像并可能故障转移的实例？

我正在考虑为这 100 台台式机提供零维护方法。我目前的想法是，如果发现过程不是自动的，我将必须有一个 Internet/Intranet 文件/服务来描述哪个服务器是主体，哪个是镜像，应用程序可以从中读取。

背景：我已经阅读了多篇关于使用 SQL_COPT_SS_FAILOVER_PARTNER 连接属性的文章，并且您必须在连接字符串中指定镜像以允许 SQLNCLI 透明客户端重定向，但这一切似乎有点回到前面。为什么程序员或最终用户必须参与其中？网络基础设施可能会发生变化。

我希望尝试连接到主体或镜像或见证将我重新路由到正确的主体并且只是“知道”镜像是什么。我知道见证人可以管理多个数据库镜像会话，因此可能需要其他东西。

那么，我如何发现镜像或原则服务器开始呢？我不希望用户输入它，因为它可能会改变。我必须先连接到正在运行的主体，从主体中提取注册的镜像，然后使用这些参数重新连接，还是可以稍后设置连接属性？

我期待一些启示！

4

1 回答 1

6

首先让我们将见证人从 SQL 客户端等式中剔除。见证只是参与镜像的两个伙伴之间的事务，不必接受客户端连接。让见证人接受客户端连接并适当地“重定向”将需要在见证人上设置整个客户端连接基础架构（主要是登录名和权限），并且需要客户端可以访问见证人（在 IP 级别） . 如果您认为设置登录名和权限是微不足道的，那么请考虑一下为什么 MSDN 有一篇关于此主题的专门文章：为数据库镜像设置登录帐户（提示：“孤立用户”）。

接下来让我们考虑客户端如何到达主体 OR 镜像。假设您只在客户端连接中指定一个服务器名称，即主体，然后您连接到它，他会将您重定向到“镜像”（实际上，由于角色交换了新主体，他现在是“镜像” ）。这会起作用，但仅适用于最无趣的情况：当主体和镜像都在线并且具有交换角色时。这不是灾难恢复方案，有趣的情况是主体发生灾难性故障并且不可用。在这种情况下，前任主体无法访问并且尝试连接的客户端只会返回板球唧唧喳喳，那里根本没有听众可以将他重定向到前镜像（当前委托人）。这就是为什么客户端必须知道主体和镜像的名称。

话虽如此，当然没有什么可以阻止您拥有镜像对的中央存储库并让客户端首先连接到存储库并检索主体和镜像的名称。您剩下的任务是发现存储库以及保持存储库最新的任务（可以通过利用数据库镜像状态更改事件上的事件通知来实现（EN 可以远程交付到中央存储库，请参阅路由））。最后一项任务是使存储库具有高可用性，并且再次镜像是可能的解决方案。

于 2012-02-03T18:04:29.150 回答