Granular Replication – DAG, Exchange 2010 SP1

Below para’s will help you understand a bit how Granular Replication in DAG Exchange 2010 SP1 is improved compared to legacy continuous replication between the nodes. It also gives a clear view to what are the components involved in replication not in depth but enough for one who wants to be familiar how granular replication works….for more info please refer the MS Technet…!

The granular replication mechanism is able to replicate log data without requiring a log be completed before any data is shipped. The mechanism replicates data being written into Exx.log. The log data then replicates to all passive copies of the database.

The replication service then forwards that data on to each passive copy on other servers.  On the passive copy, the replication service uses a Jet instance and the Consume API to collect the replicated data. The log data is saved in a .JSL file (Jet Shadow Log) in the inspector directory of the log folder path.  As each file is completed, it is validated and then renamed to the numbered log file and then passed to the log inspector and replayer as in the regular replication mode (non-granular mode, wherein the whole log files are read).

The data is reconstituted to create identical logs on the passive database copies as present on the active database copy.  You would be able to perform a binary comparison of the two files and find no differences. The file modification times match between active and passive log files. The reconstituted log files have the same name on the passive as present on the active; that is they have the correct log generation-based names. The most recent log file on a passive is not named Exx.log; even though that is the name of the log file on the active.  The replication service supports the resynchronization process when different copies have Exx.log and the same log with a generation-based name.
A partially completed log file on the passive is saved in a usable (inspectable and replayable) state. It successfully passes inspection and can be replayed if no data was corrupted during the transfer operation.

Transmitted notifications for new log files can be deferred when the system is replicating partial logs. When new chunks of log file are transmitted the source indicates if more data is currently outstanding. This information is used to estimate and populate LatestAvailableLogTime on the target database copy.

Replay Manager:
The Replay Manager is responsible for managing the replication for all database copies on the server. There is one instance of the Replay Manager for each server, in charge of replication for that server only. The replay manger uses a replica instance object to drive replication actions for individual database copies. A replica instance is an object that represents a single database copy.
The replay manager creates a replica instance for each database copy on the server, active and passive.

Active:
For each database copy that is currently active, and is the source of replication to the passive database copy on another server, Replay Manager creates an instance of a GranularReader.
GranularReader manages consumption of data from the active copy of a database. It contains a Pipe from which data is read from the information store. It contains a queue of messages which is shared via the GranularCursor used by the LogCopyServer objects for each passive database instance that is operating in granular replication mode.

Passive:
For each database copy that is currently passive, and is the target of replication from the active database copy on another server, Replay Manager creates a TargetReplicaInstance instance. The LogCopier is a component of a TargetReplicaInstance. It is responsible for replicating from the source database copy to the target database copy. There is one LogCopier object for each TargetReplicaInstance.

Performance:
By design granular replication minimizes the performance impact on the active server.

  • The overall CPU impact is no more than 5% for a non-compressed and non-encrypted transfer compared to file replication mode
  • The overall memory impact is no more than 5% for a non-compressed and non-encrypted transfer compared to file replication mode
  • The overall network impact is no more than 10% for a non-compressed and non-encrypted transfer compared to file replication mode (A similar transport is assumed)
Advertisements
This entry was posted in Exchange Servers. Bookmark the permalink.

One Response to Granular Replication – DAG, Exchange 2010 SP1

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s