April 9, 2009 at 10:25 am
I've built an Active/Passive failover cluster using MS Cluster Services and SQL 2K5 and am surprised/concerned by SSMS' response when I test failovers. I'm hoping someone can confirm they get similar behavior with their A/P cluster.
Here's the behavior I'm seeing:
- connect to the virtual SQL Name
- run a simple query in SSMS, it works
- via cluadmin, move the SQL instance to the other node
- go back to SSMS, attempt to run the same query - it fails with "network transport error"
- if I right-click, connect and re-execute the query, it works just fine.
On the one hand, this makes sense - but on the other hand, I'm surprised SSMS isn't cluster aware. Is this typical behavior?
Thanks in advance!
April 9, 2009 at 10:29 am
keep in mind that as part of moving from one instance to the other, the SQL service was stopped and restarted. So - the error you got ultimately had nothing to do with cluster-aware, but had to do with your connection being cleared as part of the rollover/failover process. It's the same reaction if you restarted the SQL Service on a single machine without exiting SSMS.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
April 9, 2009 at 10:39 am
Thanks for the quick response Matt.
I've only been testing w/ pings, queries and reporting services reports pointing at the cluster and so far so good. I was just concerned that the first/best tool I'll use to monitor the instance couldn't handle it when the virtualized instance was moved.
The application this database will support is cluster-aware (per the marketing folks), so I can't wait to test failovers and see how the app handles it.
Thanks again,
Z.
April 9, 2009 at 11:36 am
DotNet allows applications to be fail-over aware where if you have database mirroring setup you could put the names of the primary and secondary server in the connection string and it will pick up the connection to the secondary server in case of a fail-over or a failback.
Maybe they are using the same principle and setting the primary and secondary server to be the same virtual name.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply