Q. What is Exchange 2007's Last Log Resilience?

A. In most lossy failover situations, the small size of transaction logs means that only a few transaction logs are missing. However, missing even a few would mean there would be differences in the databases when the failed active node was brought back online, because it would have database content not in the active copy of the database. If the databases are different, a very costly database reseed is required, which means completely replacing the content of the database replica.

To avoid this situation, Exchange 2007 implements Last Log Resilience on the CCR active node. Last Log Resilience delays writes from the transaction logs to the database for 10 transaction logs of content. This means the active node of the CCR has its mailbox database 10 transaction logs of content delayed, which minimizes the chances of data being written to the local database from transaction logs that don't make it to the passive node in the event of a lossy failover. This delay of 10 transaction logs only occurs on the active node of the CCR cluster, not on the passive. This arrangement is shown here.

Click to expand

In the illustration, the green transaction log files are those written to the database. On the active node of the CCR, the last transaction log is number 12, but because of the 10 transaction log delay, number 2 is the log most recently written to the database. On the passive node, the logs are still received as quickly as possible and committed to the database straight away, so the passive node's database is ahead of the active node. The passive node being ahead is not a problem in a failover situation because there is no divergence, one database is just ahead of the other.