How continuous replication methods affect Exchange 2007 log shipping

The log shipping process in Exchange Server 2007 varies depending on which continuous replication method is in place: local continuous replication (LCR), cluster continuous replication (CCR) or standby continuous replication (SCR). Get an understanding of how continuous replication affects Exchange Server 2007 log shipping, and what happens when a failure occurs in a continuous replication environment.

The log shipping process in Exchange Server 2007 varies depending on whether you're using local continuous replication (LCR), cluster continuous replication (CCR) or standby continuous replication (SCR). Exchange Server expert Brien Posey explains how log shipping differs in Exchange 2007 and what happens when a failure occurs in a continuous replication environment.

During server hosting, the passive database pulls copies of log files from the server that's hosting the active database using server message blocks. This only occurs, however, with CCR and SCR.

LCR is a single-server solution. Both active and passive copies of the database reside on the same physical server, but on different volumes. Therefore, a log file doesn't need to be transmitted over a network connection. Instead, LCR uses file system notifications to alert the passive database copies that new log files exist. It then uses a standard file copy to duplicate the log file to the inspection folder associated with the passive database.

LCR, CCR and SCR also differ in that LCR is a single-server replication mechanism that requires only a single instance of the replication service. In contrast, CCR and SCR require each server involved in the replication process to run its own copy of the replication service. These copies then work together to facilitate log file shipping.

More on Exchange 2007 continuous replication:
Managing LCR in Exchange 2007

Exchange 2007 replication and database transaction basics

Exchange Server 2007 hardware planning for continuous replication

If LCR uses standard file copies, and SCR and CCR transmit log files over the network, you may wonder how the transmission process actually works. Exchange Server accomplishes CCR and SCR log shipping through the use of hidden shares on the server.

The replication service running on the server that contains the active database creates a hidden, read-only share that corresponds to the log file folder. Multiple storage groups are used and a separate share is created for each storage group.

The share name is actually the storage group's GUID, followed by a $ symbol, which designates that the share is hidden. When the server containing the passive database copy needs to pull a log file, it connects to the share and copies the file across the network.

Additionally, Windows UNC-naming conventions require that a NetBIOS name or an IP address be specified before the share name. Exchange Server 2007 generally does not use literal server names or IP addresses when connecting to hidden shares. Exchange 2007 uses a variable called nodenameActive, instead of the name of the server that contains the active database. Therefore, when the passive node (in a CCR deployment) needs to connect to the server hosting the active database, it connects to nodenameActive\GUID$. In this case, the word GUID is replaced by the GUID of the storage group on the active server.

Failure situations in Exchange Server continuous replication

When a failure occurs in a continuous replication environment, what happens depends on the type of failure that has occurred and on the type of continuous replication being used. For example, LCR gives you a backup copy of the database, but it doesn't really protect you from all types of failures since both database copies reside on the same physical server.

If the server's system board were to fail, then both copies of the database would be accessible. In contrast, if a disk controller were to fail, then volumes that did not depend on that controller would remain online and could theoretically be used.

Failures become more interesting when you bring CCR into the picture. CCR allows you to not only recover from unexpected failure, but to also take a node down for maintenance while leaving the information store mostly accessible. A short outage will occur while controllers shift from one server to another.

About the author: Brien M. Posey, MCSE, is a five-time recipient of Microsoft's Most Valuable Professional award for his work with Exchange Server, Windows Server, Internet Information Services (IIS), and File Systems and Storage. Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal website at www.brienposey.com.

Do you have comments on this tip? Let us know.

Please let others know how useful this tip was via the rating scale below. Do you know a helpful Exchange Server, Microsoft Outlook or SharePoint tip, timesaver or workaround? Email the editors to talk about writing for SearchExchange.com.

This was first published in December 2008

Dig deeper on Microsoft Exchange Server Backup and Disaster Recovery

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchWindowsServer

SearchEnterpriseDesktop

SearchCloudComputing

SearchSQLServer

Close