Exchange Server Forums

log truncation in DAG scenario

Users viewing this topic: none

Logged in as: Guest

Printable Version

All Forums >> [Microsoft Exchange 2010] >> High Availability >> log truncation in DAG scenario

Page: [1]

Message

<< Older Topic Newer Topic >>

log truncation in DAG scenario - 24.May2010 8:52:35 AM

rijukl

Posts: 8
Joined: 23.Jul.2003
From: India
Status: offline

I am little confused with the log truncation in DAG.
I have two 2010 servers. Each has passive database of the other.
Circular logging is disabled.
It's my understanding that logs will be truncated after successful log replication to the other server. It doesn't happen in my case. Logs keep piling up. Replication is healthy.
Log replay and log truncation delays are 0, default.
My questions are:-
1) If I run a full IS backup, logs are committed and deleted, but what will happen to the logs which are not replicated to second server? Will they be committed and deleted too?
2)What is the best backup method here? Should I backup active or pasive backup?

Your replies are appreciated.
thanks,
Riju

Post #: 1

Featured Links*

RE: log truncation in DAG scenario - 24.May2010 12:27:51 PM

flaubel

Posts: 5
Joined: 27.Aug.2009
Status: offline

Hi !

Technet is your friend

http://technet.microsoft.com/en-us/library/dd335158.aspx

The following criteria must be met for a database copy's log file to be truncated when lag settings are left at their default values of 0 (disabled) :

The log file must have been successfully backed up, or circular logging must be enabled.
The log file must be below the checkpoint (the minimum log file required for recovery) for the database.
All other lagged copies must have inspected the log file.
All other copies (not lagged copies) must have replayed the log file.

You can only backup active databases with Windows Server Backup. With DPM 2010 you can backup active and passive :
http://blogs.msexchange.org/walther/2009/10/02/protecting-exchange-2010-dags-with-dpm-2010/

quote:

ORIGINAL: rijukl

I am little confused with the log truncation in DAG.
I have two 2010 servers. Each has passive database of the other.
Circular logging is disabled.
It's my understanding that logs will be truncated after successful log replication to the other server. It doesn't happen in my case. Logs keep piling up. Replication is healthy.
Log replay and log truncation delays are 0, default.
My questions are:-
1) If I run a full IS backup, logs are committed and deleted, but what will happen to the logs which are not replicated to second server? Will they be committed and deleted too?
2)What is the best backup method here? Should I backup active or pasive backup?

Your replies are appreciated.
thanks,
Riju

_____________________________

http://laubel.wordpress.com/

(in reply to rijukl)

Post #: 2

RE: log truncation in DAG scenario - 24.May2010 1:20:30 PM

rijukl

Posts: 8
Joined: 23.Jul.2003
From: India
Status: offline

Hi flaubel,
I did read this article. But I didn't quite find the answer to my question.
If I backup the active database, what if it commits the log files before replicating to the passive database?
I use Netbackup, so I can backup active or passive copy.
-Riju

(in reply to flaubel)

Post #: 3

RE: log truncation in DAG scenario - 24.May2010 4:29:54 PM

flaubel

Posts: 5
Joined: 27.Aug.2009
Status: offline

I could never explain this as well as Scott Schnoll - Hope this helps

:
http://blogs.technet.com/b/scottschnoll/archive/2006/12/11/continuous-replications-and-exchange-backups.aspx

With log files being copied around and required by the Replication service, it becomes a little more complicated when it comes to getting rid of them. Right now the conventional way to get rid of log files is to run a backup. Backups runs, and on successful completion, it deletes the logs you don't need any more. The challenge now is that the definition of "need" is different because now it takes into account the state of replication. If a log file has not been copied, then you still need it (even though the store might not need it). So now a log file should not be deleted until (1) it isn't needed for crash recovery, (2) it has been replayed on the passive, and (3) it has been backed up.
To coordinate all of this, whenever the Replication service finishes a replay, it contacts the store and says that it replayed storage group X up to Y generation number. At that point, the store knows that log files up to that generation number are no longer needed by the Replication service. It can then analyze the state of the last backup and the state of crash recovery and work out which log files are no longer needed on the active.
Fortunately, on the passive, things are a lot simpler. The passive can analyze its own log files and determine which ones are needed for recovery, and which ones are needed for backup.

_____________________________

http://laubel.wordpress.com/

(in reply to rijukl)

Post #: 4