March 29, 2011 at 1:27 pm
I have been given the task of figuring out mirroring and disaster recovery.
I managed to get a 2 servers set-up with high safety without a witnes and I can fail them over and back without a problem.
The issue I'm having is that I cannot find information the shows exactly what you would need to do to:
1. Recover the transaction logs from the dead primary server
2. Compare them to what is on the mirror server (now the primary)
3. Get the missing info into the database.
Does anyone know of any books/articles/videos of how do this?
Thanks
March 29, 2011 at 7:41 pm
With high safety mode - which is a two-phase commit, there would not be anything in the primary log files to recover. That is because nothing gets committed on the primary node until it has committed on the secondary.
In a crash scenario, any transactions that are in the mirroring queue are not going to get to the secondary. This will be a very small amount of transactions and wouldn't be recoverable in a cluster failover or single server scenario either.
This is the whole purpose of high safety - which insures that all transactions are committed on the mirror before they are committed on the primary system. This is also why you must make sure you have a good network connection between the two servers.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
March 29, 2011 at 10:00 pm
It's two-phase commit, but if the mirror is unavailable, the transactions will still be committed as far as the principal is concerned, they'll just be queued in the transaction log, ready to be applied on the mirror when it's available again.
I can think of a situation where you might have to bring the mirror online when it was out of synch - say if the network failed for a few minutes, allowing transactions to queue up on the principal, and then at that point the principal fails. This would mean committed transactions on the principal that didn't exist on the mirror. If it had failed to the point where it would require some work to bring it back up again, then you'd most likely bring the mirror online and worry about retrieving the data later on. Depending on the complexity of the application, this could be tricky!
If you can bring the principal online long enough to synch it with the mirror, then you should be able to get a clean failover. I was trying to work out if you'd ever need to backup the tail of the log (removing mirroring first) but I can't think of a scenario where this would apply - if you can get the the server to backup the log, then presumably you can allow the mirror to synchronize. I suppose if you lost the network on the principal, then you might need to but that'd be a pretty unusual situation.
April 1, 2011 at 7:14 am
Thanks for the information.
Sorry I didn't reply sooner, I had to spend a few days at one of our customers sites.
Viewing 4 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply