locked
SCR replication RRS feed

  • Question

  • Hi Guys,

    I am wondering how is the SCR replication schedule work.. for example, if I have enable for the following cmdlet, what will be the result like?

    Enable-StorageGroupCopy -Identity "clsmbx\first storage group" -standbyMachine scr_vm04 -ReplayLagTime 0.6:0:0  -TruncationLagTime 0.12:0:0

    If am not mistaken, with this cmdlet said the replay log time will be delay in 6hrs, and truncate log will be delay in 12hrs, but with such explain, which exactly the time is sepecific to excute? will it be start counting right about this cmdlet been executed? example, the cmdlet was execute in local server time 12pm, from next 6hrs which is 6pm later, the replay will trigger? and subsequence?

    On seperate question, in the event of mailbox server crash, and with such SCR setting, how do we calculate the lost email? there will be how many hour of email will not be recover when SCR is activated?

    Please feel free to comment, very appreciates it...

    Many thanks....
    Saturday, May 16, 2009 8:00 AM

Answers

  • If your SRC target is avialable then it will pull the log files from the SCR source as soon as possible - the network connection is available.
    The parameters just specify when the log file gets replayed into the SCR database (ReplayLagTime) and when it is possible to delete a already replayed logfile on the SCR target.

    The amount of "lost email" does not depend on the two parameters. It depends on how many log files have not been shipped to the SCR target for example because of network problems.

    http://www.amazon.com/gp/product/1555583083/ref=s9_simx_gw_s2_p14_t1?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=center-1&pf_rd_r=1T7RAZ1FBPRADYVZ6N7V&pf_rd_t=101&pf_rd_p=470938131&pf_rd_i=507846


    You only can use the following parameters to fine tune SCR:

    • ReplayLagTime
    • TruncationLagTime
    • SeedingPostpost

    ReplayLagTime specifies the time the Replication Service has to wait until a copied log file is replayed into the SCR target database. The default value is 24 hours and the maximum delay is 7 days. The format of the value is Days.Hours:Minutes:Seconds.

    In addition to this lag time Exchange verifies if at least 50 log files have been shipped to the SCR target before it replays a log file to the target database. This is also the case when you SCR enable a storage group; Exchange does not create the initial SCR target database until at least 50 log files have been shipped. Users with mailboxes in the SCR enabled storage group must send and receive new emails so that new log files are created on the SCR source and shipped to the SCR target before the database will be created on the SCR target.

    Therefore the actual replay lag time is the maximum of ReplayLagTime or “X log files” where X is 50 in the current Exchange Server 2007 build. You cannot configure X, it is a fixed value. This delay minimizes the likelihood that a reseed is necessary after a lossy failover in a LCR / CCR deployment. After a lossy failover log files are missing on the new active storage group. The SCR source and SCR target are closer together in time because of the missing log files on the SCR source.

    The ReplayLagTime reduces the likelihood that the active database and the SCR target database have a logical corruption at the same time. You have the chance to recognize the logical corruption on the active database and stop replication before the replay occurs. In LCR and CCR on Exchange Server 2007 there is no such delay and an administrator can not influence when shipped log files will be replayed.

    The parameter TruncationLagTime specifies the amount of time the Replication Service has to wait until it can delete log files that have been replayed into the SCR target database. It is important to note the time period starts after the log file has been replayed into the copy database; the time does not start when the log file has been shipped from the SCR source to the SCR target. This parameter only affects the deletion of log files on the SCR target. Log file deletion on the SCR source is not affected by this parameter. The SCR source only has to wait until log files have been inspected on the SCR target. It is not necessary for log file deletion on the SCR source that a log file has already been replayed into the SCR target database. The maximum value for TruncationLagTime is 7 days and the minimum value is 0 seconds. The default value of TruncationLagTime is 0. It is important to highlight that NO log file gets deleted on the SCR target until the log file with the same log file generation number has been successfully backed up on the SCR source.

    If you enable an existing Storage Group for SCR then you can use the parameter –SeedingPostponed to specify that you do not want to start seeding automatically and prefer to use the command Update-StorageGroupCopy to manually start the seeding process. You have to execute the Update-StorageGroupCopy command on the SCR target and not on the SCR source. This enables you to setup and configure SCR during working hours but postpone seeding to a time with low user activity and utilization of the network. If you do not specify the parameter SeedingPostponed then the SummaryCopyStatus automatically switches from initially Disabled to Suspended and finally to Health.

    • Proposed as answer by Alan.Gim Friday, May 22, 2009 8:45 AM
    • Marked as answer by Alan.Gim Monday, May 25, 2009 1:12 AM
    Saturday, May 16, 2009 9:51 AM
  • If you suspend replication then the SCR target does not pull transaction log files. This will affect your recoverability. Log files that are not available on the SCR target cannot be replayed into the SCR target databases when you lost your SCR source.
    You can use powershell scripts as scheduled tasks.

    You can use the Exchange 2007 Mailbox Server Role Storage Requirements Calculator spreadsheet to estimate the required network connection between the SCR source and SCR target.
    If you use Windows Server 2008 then you can take advantage of the TCP/IP autotuning features. With Windows Server 2003 you can tweak the TCP/IP stack manually.

    There are a few whitepapers and books available that describe SCR configuration and activation step by step.
    • Proposed as answer by Alan.Gim Friday, May 22, 2009 8:45 AM
    • Marked as answer by Alan.Gim Monday, May 25, 2009 1:12 AM
    Tuesday, May 19, 2009 6:25 AM
  • Yes, as CopyQueueLength is the number of logs known by the copy that needs to be replicated, I think the amount is right

    However, if we suspend replication for so much time, there must have a big impact for end users. As you said in the previous post, if primary copy is down at the 17:00 PM just before the replication start, end users will lose almost all messages in that day when SCR target has been activated. And, as J-H said before, this will definitely affect a lot to the high availability

    So, please consider running the log replication daily

    Per my knowledge, there’s no issue between log replication and backup (In the same time). But, please still build a lab to test the whole scenario before implement the plan

    • Proposed as answer by Alan.Gim Friday, May 22, 2009 8:45 AM
    • Marked as answer by Alan.Gim Monday, May 25, 2009 1:12 AM
    Thursday, May 21, 2009 5:44 AM

All replies

  • If your SRC target is avialable then it will pull the log files from the SCR source as soon as possible - the network connection is available.
    The parameters just specify when the log file gets replayed into the SCR database (ReplayLagTime) and when it is possible to delete a already replayed logfile on the SCR target.

    The amount of "lost email" does not depend on the two parameters. It depends on how many log files have not been shipped to the SCR target for example because of network problems.

    http://www.amazon.com/gp/product/1555583083/ref=s9_simx_gw_s2_p14_t1?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=center-1&pf_rd_r=1T7RAZ1FBPRADYVZ6N7V&pf_rd_t=101&pf_rd_p=470938131&pf_rd_i=507846


    You only can use the following parameters to fine tune SCR:

    • ReplayLagTime
    • TruncationLagTime
    • SeedingPostpost

    ReplayLagTime specifies the time the Replication Service has to wait until a copied log file is replayed into the SCR target database. The default value is 24 hours and the maximum delay is 7 days. The format of the value is Days.Hours:Minutes:Seconds.

    In addition to this lag time Exchange verifies if at least 50 log files have been shipped to the SCR target before it replays a log file to the target database. This is also the case when you SCR enable a storage group; Exchange does not create the initial SCR target database until at least 50 log files have been shipped. Users with mailboxes in the SCR enabled storage group must send and receive new emails so that new log files are created on the SCR source and shipped to the SCR target before the database will be created on the SCR target.

    Therefore the actual replay lag time is the maximum of ReplayLagTime or “X log files” where X is 50 in the current Exchange Server 2007 build. You cannot configure X, it is a fixed value. This delay minimizes the likelihood that a reseed is necessary after a lossy failover in a LCR / CCR deployment. After a lossy failover log files are missing on the new active storage group. The SCR source and SCR target are closer together in time because of the missing log files on the SCR source.

    The ReplayLagTime reduces the likelihood that the active database and the SCR target database have a logical corruption at the same time. You have the chance to recognize the logical corruption on the active database and stop replication before the replay occurs. In LCR and CCR on Exchange Server 2007 there is no such delay and an administrator can not influence when shipped log files will be replayed.

    The parameter TruncationLagTime specifies the amount of time the Replication Service has to wait until it can delete log files that have been replayed into the SCR target database. It is important to note the time period starts after the log file has been replayed into the copy database; the time does not start when the log file has been shipped from the SCR source to the SCR target. This parameter only affects the deletion of log files on the SCR target. Log file deletion on the SCR source is not affected by this parameter. The SCR source only has to wait until log files have been inspected on the SCR target. It is not necessary for log file deletion on the SCR source that a log file has already been replayed into the SCR target database. The maximum value for TruncationLagTime is 7 days and the minimum value is 0 seconds. The default value of TruncationLagTime is 0. It is important to highlight that NO log file gets deleted on the SCR target until the log file with the same log file generation number has been successfully backed up on the SCR source.

    If you enable an existing Storage Group for SCR then you can use the parameter –SeedingPostponed to specify that you do not want to start seeding automatically and prefer to use the command Update-StorageGroupCopy to manually start the seeding process. You have to execute the Update-StorageGroupCopy command on the SCR target and not on the SCR source. This enables you to setup and configure SCR during working hours but postpone seeding to a time with low user activity and utilization of the network. If you do not specify the parameter SeedingPostponed then the SummaryCopyStatus automatically switches from initially Disabled to Suspended and finally to Health.

    • Proposed as answer by Alan.Gim Friday, May 22, 2009 8:45 AM
    • Marked as answer by Alan.Gim Monday, May 25, 2009 1:12 AM
    Saturday, May 16, 2009 9:51 AM
  • Hi J-H,

    fistly, thanks for the detail comment.. really appreciate it..

    I have got better understanding of replaylagtime and trancationlagtime parameter... but a question, since the scr target is available it will start pulling the log from scr source as soon as possible, that will cause a certain network bandwidth congestion for site to site connection, right? we have a limit of site to site bandwidth connection, therefore I have a concern with the bandwitdh to replicate the transaction log between both sites, since we decided to locate a scr target on different site than primary mailbox server.

    Is there a tweak setting for scr for such scenario to reduce the bandwidth consume by scr replication? while reduce the bandwidth that within the calculated lost. If am not mistaken, each transaction log size about 1Mb, and there will be minimun of 50log by default will replicate over before the replaylagtime, can i assume that minimun bandwidth cost about 50Mb? Is there a way that I can ensure the scr target has the full log being replicate over? how do i verify how much log been replicated over successful against with source server?

    With deep understand of scr, i have doubt that this could really be use in DR of exchange mailbox for co-lo, the purpose of acquiring this would be create redundant of primary mailbox server with miminum lost of email in the event of primary site has down, and scr target will activate for business continueously.. when primary site is back up and scr target will be replicating the changes to primary mailboxs server ideally.. I am still figuring out how to acheive of ideal design.. Please feel free to comment and share the thinking of scr design for DR site purpose...

    Appreciate the comments and many thanks...

    Saturday, May 16, 2009 11:26 AM
  • Q: “Is there a tweak setting for scr for such scenario to reduce the bandwidth consume by scr replication?”

    Well, it seems what you concerned is about the user experience during the log shipping, and then the method below might be a good option for you

    SeedingPostponed, can be used to skip the initial seeding of the SCR target. Postponing seeding is useful in a variety of situations. For example, say the database in the storage group being enabled for SCR is 100GB. You might not want 100GB of data to traverse the network during peak production times. The SeedingPostponed parameter gives you the option of enabling SCR immediately and performing a seeding task later. When you're ready, you can manually seed the SCR target using the Update-StorageGroupCopy cmdlet

    -----------------<Standby Continuous Replication in Exchange Server 2007 Service Pack 1>

    Resources:

    How to Seed a Standby Continuous Replication Target

    Q: “Is there a way that I can ensure the scr target has the full log being replicate over?”

    We can use “Get-StorageGroupCopyStatus” to confirm in the output, like the fields below will tell us if the 50 log files have been shipped

    ·         ReplayQueueLength: The number of logs available to be replayed into the copy's database.

    ·         CopyQueueLength: The number of logs known by the copy that need to be replicated to the copy

    Monday, May 18, 2009 7:09 AM
  • Hi James-Luo,

    I'm more concern about the day to day log shipping that will cause of bandwidth congested by scr replication, since as it mentioned, the log will pull from scr source as soon as the scr target available. The seedingpostponed parameter will useful right after the enabled for SCR, and manually seed the SCR target might be workable but that is not so effective too.. I am looking at a schedule task which it can execute the seeding only certain scheduled timeframe... I am not sure that writing a powershell cmdlet and save it as a file execute like a batch file with schedule task.. will this workable? Please advise..

    On seperately, have you done the activation of scr target that located at remote site, while primary site is problem? how do you push the changes from activated scr target to originate server? I am still figuring out how is the activation steps and also restore process of scr target to primary exchange server with changes update..

    Please advise..

    Appreciates it... many thanks
    Monday, May 18, 2009 11:58 AM
  • Hello,

    Well, i guess you can achieve this by pausing and starting the replication as per the schedule by running backup cmdshell commands.


    How to Suspend Changes to a Standby Continuous Replication Target
    http://technet.microsoft.com/en-us/library/bb629504.aspx

    How to Resume Replication to a Standby Continuous Replication Target
    http://technet.microsoft.com/en-us/library/bb691431.aspx

    BAT file Exchange 2007
    http://social.technet.microsoft.com/Forums/en-US/exchangesvradmin/thread/fdbda4f5-4142-4736-87d3-75915d788e11


    Arun Kumar | MCSE - 2K3 + Messaging | ITIL-F V3
    Monday, May 18, 2009 7:48 PM
  • If you suspend replication then the SCR target does not pull transaction log files. This will affect your recoverability. Log files that are not available on the SCR target cannot be replayed into the SCR target databases when you lost your SCR source.
    You can use powershell scripts as scheduled tasks.

    You can use the Exchange 2007 Mailbox Server Role Storage Requirements Calculator spreadsheet to estimate the required network connection between the SCR source and SCR target.
    If you use Windows Server 2008 then you can take advantage of the TCP/IP autotuning features. With Windows Server 2003 you can tweak the TCP/IP stack manually.

    There are a few whitepapers and books available that describe SCR configuration and activation step by step.
    • Proposed as answer by Alan.Gim Friday, May 22, 2009 8:45 AM
    • Marked as answer by Alan.Gim Monday, May 25, 2009 1:12 AM
    Tuesday, May 19, 2009 6:25 AM
  • Yes

    I planned to set a task scheduler to execute these cmdlet suspend-storagegroupcopy and resume-storagegroupcopy in sequence.. in that case, for my replaylagtime and truncatelagtime will be shorten since i want the replay happen as soon as the schedule resume the replication, right?

    Also, I realized the number of copyqueuelength is increasing after it has been suspended, how does it read? does it represent total number of log file need to be replicate since after it has suspended?

    Name                      SummaryCopySt CopyQueueLeng ReplayQueueL LastInspecte
                                  atus                    th                      ength             dLogTime
    ----                         -------------         -------------         ------------      ------------
    First Storage Group       Suspended     761                   120                5/19/2009...

    For my task scheduler schedule, I would prefer to execute it during off office hour, end before the office begin.. for example, office hour is 8.00 to 17:00, resume cmdlet will execute at hour 18:00 and suspend cmdlet will stop replication at hour 6.00 next day.. in order word, we have 7hrs different and that will be the lost if anything goes wrong in between, right? other than that, the log should replicated over and replay into edb.. please correct me if my idea is wrong..

    Many thanks...

    Tuesday, May 19, 2009 8:02 AM
  • Once you suspend the copy, the CopyQueueLength will increase because those are the logs which need to be copied to the SCR target.
    Tuesday, May 19, 2009 6:16 PM
  • Here’s a sample as a walkthrough for the activation of SCR target and switch back

    Q: “I realized the number of copyqueuelength is increasing after it has been suspended, how does it read?”

    A: “The Replication service on the target uses file system notifications to detect new log files as they are closed … The Replication service on the target also watches for file change notifications and updates its internal counter which is reflected in the state

    --------Refer to < Continuous Replication Deep Dive >

    Wednesday, May 20, 2009 8:26 AM
  • each of log file size is 1024KB, in that case, we have 761 copyqueuelength pending for replicate over, can I conclude the total size of transfer by 761log times up 1024KB, that will be the amount of replication right?

    on seperate question, we have daily schedule backup set for SCR source server, the backup will kick off daily at 12AM, and since I does not want the SCR to be replication as soon as it available, I have created two task scheduler with these both cmdlet, suspend-storagegroupcopy and resume-storagegorupcopy, the resume of SCR replication will kick off at the same time with daily backup.. I have a doubt of does it conflict of each other? What do you think?

    Thanks for sharing the comment, and appreciates it..

    Many Thanks...

    Wednesday, May 20, 2009 9:34 AM
  • Yes, as CopyQueueLength is the number of logs known by the copy that needs to be replicated, I think the amount is right

    However, if we suspend replication for so much time, there must have a big impact for end users. As you said in the previous post, if primary copy is down at the 17:00 PM just before the replication start, end users will lose almost all messages in that day when SCR target has been activated. And, as J-H said before, this will definitely affect a lot to the high availability

    So, please consider running the log replication daily

    Per my knowledge, there’s no issue between log replication and backup (In the same time). But, please still build a lab to test the whole scenario before implement the plan

    • Proposed as answer by Alan.Gim Friday, May 22, 2009 8:45 AM
    • Marked as answer by Alan.Gim Monday, May 25, 2009 1:12 AM
    Thursday, May 21, 2009 5:44 AM