Last week I kicked off a survey about network latencies and database mirroring. See here for the original post.
Here are the results of the survey:
I was really interested to see whether the proportion of people doing asynchronous mirroring became higher as the network latency increased. Although this isn't a statistically valid sampe by any means, it does show that the answer is no. However, we're missing some data that would help explain what we see here: how long are the average transactions and is there a response time SLA?
The latency between the principal and the mirror is a big deal for synchronous mirroring, because a transaction on the principal cannot be acknowledged to the user/app as having committed until all of it's log records have been written to the mirror database's log drive.
NOTE: the transaction does NOT have to be replayed/committed on the mirror, simply the log records have to be durable to guarantee the transaction is durable if the principal has a disaster. This is a very common misconception.
If the average transaction length is quite long, say 20 seconds, then the addition of another 500ms of latency when the commit is issued is not a big deal. But if the average transaction length is 100ms then an extra 500ms is a *very* big deal. This is when using asynchronous mirroring starts being considered – as transactions on the principal do NOT have to wait, but at the expense of potential data loss if the principal experiences a disaster. However, if there is no response time SLA, then the company may be fine with the extra delay with synchronous mirroring to guaranteezero data loss (as long as the mirror session stays SYNCHRONIZED).
As always, the choice of HA and DR technology comes down to analyzing requirements and limitations before choosing a technology. I go into this in more detail in the whitepaper I wrote in 2009 for Microsoft: High Availability with SQL Server 2008. There is also an excellent whitepaper on database mirroring: Database Mirroring Best Practices and Performance Considerations.
If you're one of the people who responded that you don't know your network latency even though you're using mirroring, check out the post I wrote last week: Importance of monitoring a database mirroring session.
3 thoughts on “Importance of network latency when using database mirroring”
In our situation with Windows 2003, high latency affects bandwidth (http://en.wikipedia.org/wiki/TCP_window_scale_option), so even Asynchronous Mirroring is affected. Perhaps that explains why many people prefer Asynchronous Mirroring with lower latency connections.
We have a database mirroring setup. There was a issue we faced last week. The translog were not being commited on the Mirrored server. On observation of mirroring status, using sp_dbmmonitorresults database_name, i found the unsent_log showed around 300gb of unsent log. the send_rate rate came down to 0 every 30-45 sec…
My doubt is, does disk compression has any effect in logs being applied on the mirrored database.
Nope – shouldn’t be causing what you’re experiencing.