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.
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>
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.ThanksPatrick