对于我们的db和sidentitydbcontext（aspnet Identity），Azure故障转移组有一个奇怪的问题。
如果将连接字符串设置为故障转移组，则会在日志中收到登录失败错误，但是，如果我直接连接到主服务器或辅助服务器，则登录成功。
另一个奇怪的部分是，这似乎仅在IdentityDbContext中发生。如果我仅使用普通的DB上下文进行测试，则登录可与故障转移组连接字符串一起工作，如果我使用新的SQLConnection，它也可以正常工作，但是当我尝试使用IdentityDbContext->登录失败时。
> 。我知道当从SSMS连接到故障转移组时，您需要指定默认DB，因为它无法访问主DB，但是在我的连接字符串中，我指定了一个DB，因此我不确定是否可以是问题。
其他人遇到过吗？我觉得这只会发生在我自己身上很奇怪。
这在.NET 4.6.1中，最新版本的Microsoft.aspnet.Identity（2.2.1）
根据您的描述，我在我这一边创建了一个测试演示，效果很好。
我使用故障转移组URL作为连接字符串，它可以成功登录和注册用户。
我想您可能会设置错误的连接字符串。
我建议您可以在下面的连接串下进行测试。
Server=tcp:{yourfailover group name}.database.windows.net,1433;Initial Catalog={the database name};Persist Security Info=False;User ID={user name};Password={password};MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;
我还使用身份2.2.1和NET 4.6.1 MVC应用程序。
最后，由于此博客文章，我找到了这个问题：
http://www.morganskinner.com/2014/04/optimizing-aspnet-sideity-database.html
尽管从技术上讲，博客文章与故障转移组无关，但它确实指出了以下事实：IdentityDbContext对Sys.Databases和其他" Master" DB操作进行检查，而故障转移组不可用。
因此，它可以使用普通的dbcontexts，而SQLConnections是因为没有执行隐藏的检查。
由于我不需要IdentityDbContext进行这些检查，只需将基本调用的第二个参数设置为 false ，以通过传递此功能解决了问题。
ex： public AuthenticationContext(): base(<connection string id>,false)