如果 SQL Server 不可用，自动切换状态管理
这可能是一个愚蠢的问题，基于谷歌搜索失败的事实，我打赌答案是“不”，但我想我会问以防其他人已经弄清楚了。
我们最终将我们的网站放在服务器场上，这意味着我们无法使用 InProc 会话管理。我们改用 SQLServer 模式，但我们遇到了 SQL 集群崩溃的情况。在此期间，由于无法连接到会话数据库，我们的新 Web 应用程序均无法加载。
那么问题来了：是否可以自动回退到不同的会话管理（例如 StateServer）或动态更改连接字符串以便我们可以使用备份 Sql Server？
目前，我们的计划是使用 DNS，如果主 SQL 集群发生故障，只需将 DNS 切换到备份，但这是一项手动任务，并且需要一些时间。我们希望有某种自动故障转移。
This may be a dumb question, and based on the fact that googling has failed me I'm betting the answer is "no", but I thought I'd ask in case someone else has figured it out.
We're finally putting our website on a server farm, which means we can't use InProc session management. We're using SQLServer mode instead, but we had a situation where our SQL Cluster crashed. During this time, none of our newer web apps were able to load because of an inability to connect to the session database.
So here's the question: Is it possible to automatically fall back to a different session management (StateServer for example) or dynamically change the connectionstring so that we can use a backup Sql Server?
For now, our plan is to use DNS and if the main SQL Cluster fails, simply switch the DNS to a backup, but that's a manual task, and takes some time. We were hoping to have some sort of automatic failover.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
恐怕是没有办法了。此外，切换会话状态模式也会使您的应用程序崩溃，因为用户将无法找到存储在其会话中的数据。因此，我可以给您的建议如下：为会话使用专用 SQL 服务器，不要使用与提供应用程序数据的服务器相同的服务器。如果可以的话，逐步开始更新您的应用程序，使其使用越来越少的会话，存储非常少量的数据，直到完全摆脱它。使其无状态。那么你的应用程序将变得非常可扩展。
I am afraid that there is no way. Also switching the session state mode would also make your application crash because users won't be able to find the data that was stored in their sessions. So an advice I can give you is the following: use a dedicated SQL server for the sessions, don't use the same server as the one serving your application data. And if you can, progressively start to update your application so that it uses less and less sessions, store very small amounts of data until you completely get rid of it. Make it stateless. Then your application will become very scalable.