[ExchangeList] Re: exchange 2007 CCr and error checking

  • From: "Rick Boza" <rickb@xxxxxxxxxxxxxxx>
  • To: exchangelist@xxxxxxxxxxxxx
  • Date: Mon, 29 Dec 2008 10:28:17 -0500

TranLogs replicate between nodes.  If you look at the article I linked, there is the following information:

Transaction Log Replication and Replay

Transaction log replication and replay is used to copy the changed data and update the passive copy's database. Replication takes advantage of the change history produced by the Extensible Storage Engine (ESE). This change history is represented as a sequence of fixed-size 1 megabyte (MB) log files. The replication functionality copies the log files to the passive node as each log file is generated. The replication mechanism is asynchronous to the online database. When the logs arrive at the passive node, they are checked for corruption and then replayed into the copy of the database that is stored on the passive node. The replay process makes the changes described in the change log to the passive node's database, which makes the passive node's database match the production database with a slight time lag.

So basically what this means is that the database tries to prevent any sort of corruption from getting replicated and brought in, or from a corrupt replication cycle.

The replication in this sense works very similarly to AD replication - there is an administrative file share used for copying of files.  The Tran Logs are copied as they are created.  ESE (the engine) reviews and imports the transactions.

The thing to remember is this isn't a cluster where you are sharing data storage, it's basically replicating the data to two different data stores.  It's not disk level replication, but file level replication via log shipping.

Does that help?  Admittedly I'm a bit fuzzy on looking into the replication specific steps beyond what I have outlined - my assumption is it works similarly to AD where a sequence number is assigned and at various points the passive node checks with the active node to see if it is current.  Since the replication is async, it is possible for a log to fail to copy for any of a number of reasons.  When the status check happens, and the numbers are off, the logs required to bring the sequence up to date are re-shipped.  But that's a bit of a guess on my part (albeit a fairly educated one).


On Mon, Dec 29, 2008 at 10:13 AM, Patrick <london31uk@xxxxxxxxx> wrote:
Thanks Rick,
Very helpful. Just wanting to know the in's and out's, so does the cluster maintain 2 seperate transcation logs? one on each  node? if the tans logs are the source of db corruption they can still be passed on?


From: Rick Boza <rickb@xxxxxxxxxxxxxxx>
To: exchangelist@xxxxxxxxxxxxx
Sent: Monday, December 29, 2008 2:50:56 PM

Subject: [ExchangeList] Re: exchange 2007 CCr and error checking

The replication is managed via transaction logs, not via direct database repl, which prevents corruption as you describe - so (mostly) no worries there.  of course, if something somehow corrupts one of the DBs due to content in a transaction log, chances are it will replicate over.  It's not true database clustering in the traditional sense.

See this article for some detail.

Hope that helps!


On Mon, Dec 29, 2008 at 6:39 AM, Patrick <london31uk@xxxxxxxxx> wrote:
Hi Guys,
I am a bit new to this and just need  a bit more information on how ccr works, especially with error checking.
My understanding (and I may be wrong) is that with CCR the nodes are not required to have a shared storage subsystem. So which means each node keeps a copy of the exchange DB. My question is how is error checking done? if node2 takes a copy of node1's db, surely that could lead to node1 actually corrupting node2, or am i missing something. Also is it still possible to have the shared subsystem configuration, as I am just testing things out in my Lab.

Other related posts: