Go Premium for a chance to win a PS4. Enter to Win

x
?
Solved

Standby Continuous Replication throttling question

Posted on 2008-10-16
18
Medium Priority
?
755 Views
Last Modified: 2008-10-22
We are setting up SCR in our environment and replicating over a WAN. There are a lot of Storage Groups to replicate and we are concerned about the amount of traffic with log shipping and all. I have two questions. One, does anyone know if the log shipping process is file level or bit level? Two, is there any way at all to throttle the log file shipping so we can reduce the traffic during the day when WAN utilization is the highest. Just curious as to what others are doing in a situation like this.
0
Comment
Question by:osiexchange
  • 9
  • 9
18 Comments
 
LVL 32

Expert Comment

by:gupnit
ID: 22732473
Hi,
Q1: Log Shipping is File Level, log files are 1MB each.
Q2: Well if you want to delay it then the entire objective would be lost
Here are few good articles to refer to:
Hope this helps
Thanks
Nitin
0
 

Author Comment

by:osiexchange
ID: 22732727
Thanks. I wil check these out.
0
 

Author Comment

by:osiexchange
ID: 22732928
I have seen these articles before. They only confuse me more than I am. They don't mention anything about throttling. What I am looking for is a way to more or less schedule replication to the SCR target. Once it starts, or you Enable-StorageGroup Copy, log files start shipping and we are afraid it will take up too much bandwidth. I know I can suspend the copy and resume it later but that is too much work with a lot of Storage Groups. The replay lag time doesn't slow down or delay the copy from what I have read. It simply delays the committing to the database after the log has been copied. Is this correct?

Also, I don't understand this paragraph. Is it saysing the SCR allows for log file truncation at the SOURCE
or it does log file truncation at the source. I don't think I would want my production server log files to be truncated automatically. Maybe I am reading it wrong.

In the RTM version of Exchange 2007, rules are enforced so that in a continuous replication environment a log file is not deleted unless and until it has been backed up and replayed into the copy of the database. This rule is modified when using SCR. SCR (which introduces the concept of multiple database copies) allows log files to be truncated at the SCR source as soon as they are inspected by all SCR target machines. Log truncation at the SCR source server does not wait till all logs have been replayed into all SCR targets because SCR target copies can configured with large log replay lag times.
0
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
LVL 32

Expert Comment

by:gupnit
ID: 22733391
Hi,
Let me clarify some points here....
RelayLagTime (sth like that) is the one that just delays the replay of Log Files once they have been successfully replicated to Target Server
TruncateLagTime (sth like that) is the one that defines the time for which Exchange on target server will wait after sucessful Log Replay and then will delete the Log Files. Logs are truncated at Target Server !!
And on the Scheduling of Replicaiton, No that cannot be done.
Hope this helps
Thanks
Nitin
0
 

Author Comment

by:osiexchange
ID: 22734286
OK, so if that is true, there is no need to  run backups on your production server just to flush log files because this does it for you.Of course you have to back up databases. Is there a way to disable the truncate on the source so you just let you backups flush the logs. I don't see a benefit to this but maybe I am missing something. Thanks for this info. It is really helpful.
0
 
LVL 32

Expert Comment

by:gupnit
ID: 22734342
100%, true...but backups will be required to backup !
Well, see once the Logs are replayed into the Database, then the DB is uptodate, and Logs as such are not required. Thats the reason MS has brought in this setting.
By default Truncate setting is set to 0 seconds. Well, you can increase this if oyu want. but I would say not required
Thanks
Nitin
0
 

Author Comment

by:osiexchange
ID: 22761288
I understand, but, what happens if the logs truncate on your production server and then your database crashes and all you have left is a backup of your database from yesterday and whatever log files you have to play back. Then what! If they are truncated, you are out of luck.
I suppose you can say, well, at that point you can failover to your SCR server but I would prefer not to do that because failing back means down time for all users on that server. With a CCR environment, you need to remove the Cluster software before you can fail back which means everyone is disrupted. So,
to avoid this, if a single database fails, you have to fail over the entire server to avoid disruption when failing back. Really not a good option. You see what I mean. If there is no way to disable truncation, can you delay it until after your backups have been run?
0
 
LVL 32

Expert Comment

by:gupnit
ID: 22761564
Hi,
I understand your concern....See you can set the TruncationLagTime anything between 0 Sec to 7 days....so that can take care of your concern. Though I am not sure what is the reason then that you want to continue with SCR, I assume it is a part of larger Site DR (BCP), right?
Also, CCR you do not have to remove Cluster Software, that is the benefit, if the Active fails the passive takes over, thats where CCR is better than LCR, whereby in LCR you got to manually initiate the failover. Are we in sync?
Nitin
0
 

Author Comment

by:osiexchange
ID: 22761662
What I was talking about is failing back from the SCR server to your CCR. Not node failover from active to passive. In order to replicate data back to your CCR from the SCR, in other words, reverse the process to fail back to production from your DR Site,  you need to run Exchange setup.com with the /removeCMS switch on your CCR. Then enable Storage group copy back to your CCR server, then reinstall CMS. Its a major pain. Thats why you are forced to fail over all your Storage Groups even if one fails because failing back will take everyone down. Having said this, I prefer not to use the SCR unless we do indeed have a total Site failure, and not just a single database failure. Its just too much trouble failing back, seeding the database etc.....over a WAN.

However, if I set log truncation to seven days, our backup software will be able to capture all the logs during the week. I just wish there was a way to turn it off. I don't like anything messing with the logs.
0
 
LVL 32

Expert Comment

by:gupnit
ID: 22762292
Ok, so your Source is a CCR and Target is a single SCR or you have your SCR at multiple locations....!! See to overcome your concerns....I would suggest...
  • ReplayLagTime....well here you better keep a delay of around 24 hrs (assuming your backups are daily)
  • TruncationLagTime....keep it to another 24 hrs so that you have 2 days in hand....else inccrease this to 7 (I doubt you would want to)
Considering you are being very clear on your deployment, I assume that there will be pretty active monitoring, so 48 hrs is a pretty good time so take control of things...
Hope you are getting what I am trying to say here....and well you have to live with /RecoverCMS....if at all you need to....no way out :-) !!
 
Unlike CCR where there is no delay allowed, you can then go with 2 options.....1
0
 

Author Comment

by:osiexchange
ID: 22762522
Thanks for all your help. I really appreciate it. OK, so if I keep the replaylagtime to 24 hours, what flushes the logs on the target. The daily backups or do the logs truncate on the target automatically after they are committed to the database.
I suppose even if the logs did truncate on the source, if I needed them to replay into the database after a crash, I could always manually copy them from the target SCR server back into the source log folder. No?
Also, if I increase the truncate time to 7 days, what would be the harm seeing the backups are flushing the logs every day anyway?
0
 
LVL 32

Expert Comment

by:gupnit
ID: 22762687
See what happens is that when a successful Backup is taken on the Source SG the DB header Target will be updated and the log files will be truncated. Now in your case (CCR Source) the DB header on Target will be updated and Log files will be truncated the moment a successful Backup is taken on either Active or Passive Nodes of SCR source SG ie CCR.
As such no harm, you might get some warnings on the truncation (not tried though).
Read this...http://technet.microsoft.com/en-us/library/cc164368(EXCHG.80).aspx
0
 

Author Comment

by:osiexchange
ID: 22767916
If logs are truncated on the source, then why does this blog state that they are truncated on the target.

Here is the section I am referring to and below a link to the blog:

SCR Target Log Files Fail to Truncate After the TruncationLagTime is Surpassed.

Possible Causes

The SCR log file truncation time is set to a value over 24 hours.

Resolution

Set TruncationLagTime to 0.0:00:00 minutes and then restart the Microsoft Exchange Information Store and Microsoft Exchange Replication services.  Next, take a backup of the Storage Group on the SCR Source server and then confirm that SCR Target log files get truncated after successful backup.  After SCR target files truncate properly, you may change the TruncationLagTime to your desired values.

http://msexchangeteam.com/archive/2008/05/28/448929.aspx

Its all very confusing.
0
 
LVL 32

Expert Comment

by:gupnit
ID: 22769557
Log are truncated on Source and Target both....Read this from Technet as I explained earlier...
"
In Exchange 2007 RTM, rules are enforced so that in a continuous replication environment, a log file is not deleted unless it has been backed up and replayed into the copy of the database. This rule is modified when using SCR. SCR (which introduces the concept of multiple database copies) allows log files to be truncated at the SCR source as soon as they are inspected by all SCR target computers. Log truncation on the SCR source does not wait until all logs have been replayed into all SCR targets because SCR target copies can be configured with large log replay delays. However, log truncation on an SCR source will not occur if one or more SCR targets for a storage group are down. In order for logs to be truncated on an SCR source, the SCR target computer(s) must be online and accessible by the source.
On an SCR target, a background thread runs every three minutes to determine if any log files need to be truncated. If the following three criteria are met, a log file will be truncated on an SCR target: The log file has been truncated on the SCR source.
The log file generation sequence is below the log file checkpoint for the storage group.
The log file is older than ReplayLagTime + TruncationLagTime. (For a description of these parameters, see "Cmdlet Updates for SCR" in the topic, Standby Continuous Replication)


In an LCR or CCR environment that is extended with SCR, if the following three criteria are met, a log file will be truncated on the active and passive copies in the LCR or CCR environment: The log file has been backed up.
The log file generation sequence is below the log file checkpoint for the storage group.
All SCR targets have inspected the log file"
Let me know
0
 

Author Comment

by:osiexchange
ID: 22776759
Thanks. I read that about 5 times. I posted on a Microsoft forum and got an explanation I hope is correct and final. The truncationlagtime value is the amount of time the SCR target waits before truncating log files after they have been truncated on the source. For example, if I set truncationlagtime to 1 hour and my backup runs at 11:00 PM at night and flushes the logs on the source, the SCR target will waiting 1 hour and then flush the logs on the target server. I like this explanation better because I was concerned that the logs on the source would be flushed without running a backup. I am hoping this is correct. I am not sure why you would want to do this which is maybe why Microsoft set the default to zero.
0
 
LVL 32

Accepted Solution

by:
gupnit earned 2000 total points
ID: 22779356
100%....if you see one of my previous comment....after successful backup on Source, the Target is updated with informaiton
Here is what I wrote "See what happens is that when a successful Backup is taken on the Source SG the DB header Target will be updated and the log files will be truncated. Now in your case (CCR Source) the DB header on Target will be updated and Log files will be truncated the moment a successful Backup is taken on either Active or Passive Nodes of SCR source SG ie CCR."
This would be since by default it is 0.
Now you wanted to be sure of keeping logs for sometime, hence I said make it 24 hrs....as per one of my suggestions
Hope this clarifies
Thanks
Nitin
0
 

Author Comment

by:osiexchange
ID: 22779949
Thanks for all your help. Its clear now.
0
 
LVL 32

Expert Comment

by:gupnit
ID: 22780029
My pleasure....It helps me also revise hahaha..!!
0

Featured Post

NFR key for Veeam Agent for Linux

Veeam is happy to provide a free NFR license for one year.  It allows for the non‑production use and valid for five workstations and two servers. Veeam Agent for Linux is a simple backup tool for your Linux installations, both on‑premises and in the public cloud.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

On September 18, Experts Exchange launched the first installment of the Help Bell, a new feature for Premium Members, Team Accounts, and Qualified Experts. The Help Bell will serve as an additional tool to help teams increase question visibility.
This month, Experts Exchange sat down with resident SQL expert, Jim Horn, for an in-depth look into the makings of a successful career in SQL.
In this Micro Video tutorial you will learn the basics about Database Availability Groups and How to configure one using a live Exchange Server Environment. The video tutorial explains the basics of the Exchange server Database Availability grou…
To add imagery to an HTML email signature, you have two options available to you. You can either add a logo/image by embedding it directly into the signature or hosting it externally and linking to it. The vast majority of email clients display l…
Suggested Courses

972 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question