我从未使用过镜像，群集或其他故障转移技术。但我正在调查调整我的DAL是多么容易，以便SQLNativeClient透明客户端重定向对我们有效，如果我的客户决定使用带或不带见证的镜像。
有人可以解释一个客户端应用程序的实用流程，该客户端应用程序可能位于数百个桌面上，这些桌面将连接到一个镜像并可能会故障转移的实例吗？
我正在考虑为这100台台式机提供零维护方法。 我目前的想法是，如果发现过程不是自动的，我将不得不有一个互联网/内联网文件/服务，描述哪个服务器是主体，哪个是镜像，哪些应用程序可以读取。
背景： 我已经阅读了多篇文章，涉及使用SQL_COPT_SS_FAILOVER_PARTNER连接属性，并且您必须在连接字符串中指定镜像到alllow SQLNCLI透明客户端重定向，但这一切似乎都有点回到前面。 为什么程序员或最终用户必须参与其中？网络基础设施可能会发生变化。
我希望尝试连接主要的OR镜像或见证会将我重新路由到正确的校长，然后“知道”镜像是什么。我知道见证人可以管理多个数据库镜像会话，因此可能需要其他内容。
那么，我如何发现镜像或主服务器开始？我不希望用户输入它，因为它可能会改变。我是否必须先连接到正在运行的主体，从主体中提取已注册的镜像，然后使用这些参数重新连接，或者我可以稍后设置连接attirbute吗？
我期待一些启发！
答案 0 :(得分：6)
首先让我们从SQL客户端方程中取出见证。证人只是参与镜像的两个合作伙伴之间的事情，并且不必接受客户联系。让见证人接受客户端连接并适当地“重定向”将要求在见证人（主要是登录和权限）上建立整个客户端连接基础结构，并且要求客户端可以访问证人（在IP级别） 。如果您认为设置登录和权限很简单，那么请考虑为什么MSDN有关于此主题的专门文章：Setting Up Login Accounts for Database Mirroring（提示：'孤儿用户'）。
接下来让我们考虑客户端如何到达主要OR镜像。假设您只在客户端连接中指定一个服务器名称，即主体，并且您连接到它，并且他会将您重定向到“镜像”（实际上，由于角色交换而导致新主体）他现在是'镜子'）。这样可行，但仅限于最无趣的情况：当主体和镜像都在线并具有交换器角色时。这不是灾难恢复方案，有趣的情况是当主体遭遇灾难性故障并且不可用时。在这种情况下，前任主体无法访问并且尝试连接的客户端将简单地回到板球唧唧声，那里根本没有一个侦听器将他重定向到前镜像（当前主体）。这就是客户端必须知道主体和镜像的名称的原因。
现在有人说，当然没有什么能阻止你拥有镜像对的中央存储库，并让客户端首先连接到存储库并检索主体和镜像的名称。您将完成发现存储库的任务模糊任务以及使存储库保持最新的任务（可通过Event Notifications事件利用Database Mirroring State Change来实现（EN可以远程传递到中央存储库，请参阅routing。。最后一项任务是使存储库高度可用，并且再次镜像是可能的解决方案。