The case of the apparent log roll

“Log roll” is a technique used in Exchange 2007 CCR/SCR clusters to force replication between cluster members at times when not much activity is occurring on the servers. When servers are busy, log replication happens regularly as transactions fill the 1MB logs and force Exchange to close off the active log, create new logs, and replicate. It’s a virtuous cycle.

But when servers are inactive, a partially filled transaction log might be left “hanging.”  It contains a durable or hard commit operation marking the end of a transaction but cannot be replicated to servers holding copies of the database. No doubt you'll recall that the transactional data representing a single message can extend across several logs (obviously, if each log is just 1MB), and that the end of the transaction is marked with a hard commit. Therefore, those servers cannot learn that the transaction is complete and if a failure should occur at this point, the transaction might be lost. To solve the problem, if Exchange finds that the current transaction log is partially filled for 90 seconds, it closes the log off and forces replication. As Tim McMichael explains in his blog (referenced above), an Exchange 2007 SCR/CCR cluster might generate 960 log files daily even if it appeared not to be doing very much due to background maintenance or other reasons.

Exchange 2010 also uses log roll but it does so in a more constrained manner. On an inactive DAG member, log roll might happen every 15 minutes, meaning that only 96 log files will be created daily.

However, Exchange 2013 does not use log roll. I think that the introduction of block mode replication in Exchange 2010 SP1 and the proving of this mechanism since as a robust way to ensure that data is replicated as quickly as possible between DAG members is the reason that convinced the developers to remove log roll.

Exchange manages the transition between file mode replication (the normal state when starting) and block mode replication automatically. Administrators don’t get to vote whether a server should use block mode replication. It all happens in the background. The Replication service monitors replication health and if everything is going well (essentially, logs are not building up in copy and replay queues), then block mode replication is used. And when block mode is in use, transactions are shipped off to servers that host database copies as soon as they are complete in the log buffer. No delay occurs for 1MB of data to fill a transaction log.

Block mode replication works very well. File mode replication is always there as a backstop when network conditions or other reasons mean that block mode replication might be unreliable. Having the automatic switch between the two modes is a good situation to be in.

I knew that log roll had been removed in Exchange 2013 RTM but after applying a recent Exchange 2013 upgrade to a server, I noticed that databases seemed to be producing a log every 15 minutes, which is exactly what you’d expect to see when log roll is used. Being an inquisitive type, I asked the Exchange development team what was going on. They were very kind and didn’t refer to me as being too stupid and simply whispered “synthetic transactions.”

As you might recall, Exchange 2013 includes automatic system monitoring and maintenance, aka “Managed Availability”, which constantly checks the health of various Exchange components through a comprehensive and wide-ranging set of probes, monitors, and responders. It’s obviously very important that databases are in good health and that users are able to connect to databases to send and receive email. Part of Managed Availability’s suite of tests is designed to conduct an end-to-end assessment of the end-user experience and these tests happen, as you’ve guessed, roughly every 15 minutes. The health mailboxes created in every database are used for this purpose.

The apparent “log roll” that I saw was nothing more than the transactions logged to the database by the synthetic transactions executed by Managed Availability to test the health of the database. It’s a natural side effect of Exchange making sure that all is well on a server. As such, there’s absolutely nothing to worry about. Which is nice, isn’t it?

Follow Tony @12Knocksinna