You will get disconnected as it shuts down on the active node and then starts up on the other node. It goes through complete crash recovery. To ensure very little downtime, typically about 30 seconds, make sure you don't have too many VLFs. Should be in the hundreds at a maximum.
I always thought if I'm connected and failover happens I will remain connected, it happened to me 3 years ago once and I'm pretty sure I remained connected. So what is the point of having it clustered if when Im deleting records and i get disconnected. I will lost track of the records or if I have several monitors showing extremely crucial data to save a patient life and all of the suddent it failsover and the app is disconnected and by the time i connect everything back it will be too late for the patient.
You didn't stay connected. What is more likely is that the failover occurred quickly enough so that the application didn't time out, or there was an automatic retry in the program code. Your deleted rows will roll back on failover and you'll most likely get an error message.
None of Microsoft's built-in high availability features can transition connections to the new server. The application has to be written to tolerate temporary interruptions, hence the default timeout for ADO connections.
The "point" of clustering/mirroring/Availability Groups is to provide secondary hardware to perform the same function as the primary hardware in case of failure, as quickly and automatically as possible. The alternatives are:
1. to set up a brand new machine from scratch (if one doesn't already exist) 2. restore all databases on this new machine from backups 3. change all applications to use this new machine, or 3a. modify DNS to point the old server name to the new physical server
I always thought if I'm connected and failover happens I will remain connected, it happened to me 3 years ago once and I'm pretty sure I remained connected. So what is the point of having it clustered if when Im deleting records and i get disconnected. I will lost track of the records or if I have several monitors showing extremely crucial data to save a patient life and all of the suddent it failsover and the app is disconnected and by the time i connect everything back it will be too late for the patient.
An unexpected failover is an extremely rare event. And when it does happen, it means something is wrong in your environment that needs to be addressed ASAP. Make sure you have monitoring in place to page the on-call DBA when an unexpected failover occurs. Root cause analysis needs to be found and the problem fixed.
failov3r clustering
Posted - 03/07/2013 : 16:24:59
