小编Kei*_*thS的帖子

我的公司有一对 SQL Server 2005 实例的故障转移对，它们为 UL 许可的警报/呼叫中心提供数据库可用性，其中正常运行时间和可用性对生命安全至关重要。

下面是来自其中一个关键业务应用程序的 connectionStrings 的示例行（为了我们的保护而进行了消毒）：

<add name="MyCompany.MyApp.Properties.Settings.MyDbConnectionString"
 connectionString="Data Source=Principal-DB;Failover Partner=Mirror-DB;
 Initial Catalog=MyDb; Integrated Security=True; Persist Security Info=True;"
 providerName="System.Data.SqlClient" />

大约半小时前，这是我们认为的场景：

1. DBA 在指定时间向所有用户报告 Principal-DB 服务器上的硬件维护需求，并建议他们在遇到数据库连接问题时关闭并重新启动客户端应用程序。
2. DBA 从主体数据库故障转移到镜像数据库。客户端应用程序不受影响。
3. DBA 关闭 Principal-DB 服务器。
4. 某些客户端应用程序开始在池连接上超时（正如预期的那样）。遇到这些错误的用户按照 DBA 的建议关闭并重新启动。
5. 由于无法从数据库接收响应，这些客户端应用程序现在无法完全启动。
6. 欢闹随之而来。

我们的理论是，因为主要-DB不在状态，以响应连接请求在所有的，当它通常会迅速地拒绝这样的连接，如果它是在恢复状态，客户端应用程序结束了等待整个分配连接超时（默认为 20 秒）让主服务器响应，然后返回超时错误，而无需尝试连接到列出的故障转移伙伴。

快速修复是将更新推送到包含交换数据源和故障转移伙伴实例的 App.config 的客户端应用程序，因此 Mirror-DB 现在是应用程序首先尝试连接的服务器。当我们故障恢复到 Principal-DB 时，我们将不得不使用另一个应用程序更新来撤消此更改。

我需要一个更永久的修复。这不是故障转移对的预期行为，并且不允许再次发生。必须有一种方法来配置客户端应用程序，以便它在返回错误之前在这种情况下正确尝试连接到故障转移伙伴。

简而言之，我们有几个数据库在两个故障转移实例之间同步。主要包含映射到数据库中用户的登录名，并且一切都很正常。但是，我没有意识到服务器登录不会在故障转移实例之间同步，因此当故障转移到备份时，没有人可以登录。关键是虽然我可以在备份上创建登录，但我不能t 将登录作为用户映射到数据库，因为具有该名称的数据库用户已经存在，并且登录不会使用现有用户，因此登录仍然失败，因为登录没有连接到数据库的权限。

我认为我必须做的是修改备份的主数据库中的登录名，使其与主数据库的登录名具有相同的 GUID，并在备份端手动创建登录名和用户之间的链接，从而“欺骗”备份实例认为在主服务器上创建的用户也是它自己的映射登录名。然而，我不知道我将如何去做这件事，而且我们在这个问题上遇到了足够多的麻烦，而我却没有为此烦恼。

帮助？