Replication goes to Failed state.

Last post 03-16-2011, 4:45 PM by ArvTechMan. 3 replies.
Sort Posts: Previous Next
  • Replication goes to Failed state.
    Posted: 03-16-2011, 12:07 AM
    • Noor is not online. Last active: Mon, Oct 17 2011, 7:09 AM Noor
    • Top 500 Contributor
    • Joined on 03-03-2011
    • Karachi
    • Novice
    • Points 42
    Dear All,
    I am facing an issue at my client side when we start replication pair on windows server machines from source to destination, its goes normal and complete all phases but when it comes to the updating smart sync phase, after that it goes to failed state but the data which we are replicating is on the destination machine and its replicated, i want to add some thing that the data which we are replicating are databases of  SQL server and size of  16-GB over WAN.
    Meanwhile when we tested test pair of 1-GB or less every thing going fine with smooth phases to replicating state.
    I am using Simpana 8 version with SP 5.
    Your urgent response is highly appreciated 
    Thanks

    Noor
  • Re: Replication goes to Failed state.
    Posted: 03-16-2011, 12:43 AM

    Sounds like you're using CDR replication, and you are using the APP detection when creating the pair to replicate the SQL database?  Are you trying an out-of-band sync or just a straight over the wan copy when starting?

    Here comes my vent for the CDR our of-band-sync with exchange...prepare yourself.  First, I would love your 16GB db vs the 200GB db exchange server with 50gb + logs I'm trying to replicate and the 24 regions the same situation.  V8 SP5 CDR, I went round and round with support on the best method for trying to replicate this data over a wan.  After numerous failed attempts with CV failing on itself and trying to re-replicate the entire edb file.  Only one method seemed plausible after speaking with Cliff from the replication team.  CV fails because of two reasons on the out of band sync.  Either 1) USN was not marked properly prior to backing the data up and moving it to destination or 2)FLR change journal has already rolled itself over in the commserv database and CV can't recover.  (The FLR rolling typically occurs when there is to much time between getting the data to destination and starting the pair.  Come to find out there is also a way support can flag FLR and reset it after syncing the data.  Wish I knew this prior to the other 10 failed attempts and prior to us upgrading to V9 SP1a which is suppose to solve all the problems by checking itself via the gui.  Well in a sense V9 does correct it.  Except on V9 in our environment being this large it takes the GUI out of band option 3 days to finally begin replicating, which by this time either source or destination is already flooded with 20+ GB of cv rep logs while it was busy checking itself and this puts itself so far behind that it never can catch up across the wan.  Which leads me to another support call tomorrow to see if there is a method in v9 sp1a to perform a successful out of band sync without it taking 3 days to try itself and causing itself to get behind and never able to sync up.  I'm sorry, we can't afford 2 weeks of no CRP's occurring while an out-of-band sync tries to occur.  Maybe there is a way to out-of-band sync the rep logs...really...come on.

    Not sure if my vent above made sense, but to truely answer your question.  You're probably failing because CDR thinks the destination does not match the source and therefore is attempting to re-replicate your entire DB.  Again this is caused by either the USN not being set properly before moving the data or FLR rolling to quickly in the commserv database and not being flagged and reset prior to starting the pair.  The CDR.log will tell you exactly why if you just tail it on source.  Another common cause is the setting on the CDR Agent.  It will stop/fail itself if source or destination hits a certain threshold of free space on the cv logs directory.  This is configurable as well as where the logs are placed on both source and destination.

    I wish you luck, if you find a workable out of band sync method please let me know.  Still looking for that magic answer that I'm sure someone knows.  Cliff in Replication support has been the most help.  Knowledgable guy.  Hopefully I can reach him tomorrow.  This environment being setup for replication keeps getting pushed and pushed because one thing after another...sigh.

  • Re: Replication goes to Failed state.
    Posted: 03-16-2011, 1:58 AM
    • Noor is not online. Last active: Mon, Oct 17 2011, 7:09 AM Noor
    • Top 500 Contributor
    • Joined on 03-03-2011
    • Karachi
    • Novice
    • Points 42

    Thank you Man, i am trying my best and will help you too anyways can you tell me where can i set USN number in the commserver..??

     

     

     

    Thanks


    Noor
  • Re: Replication goes to Failed state.
    Posted: 03-16-2011, 4:45 PM

    This is for the out of band sync method....

    Make sure the pair is in a stopped or new pair state.  On the source server open a command prompt.  Navigate to the base folder and run this command:

    cdrxhelp.exe -readUSN -cn *sourceservername* -vm Instance001 -pID *pair id of the rep pair*

    This will query the source USN and tell you what the current USN of change journal is.  Mark the USN down and run the command to set the USN.  This will tell commvault what point in time to start checking for changes to replicate.  Remember there is stil FLR that is tracked in commserv and I know it can be tracked and set in the DB, but if you move the data over quick enough this shouldn't be a concern.  Now just run the command to tell CommVault what USN to start at.

    cdrxhelp.exe -setUSN -cn *sourceservername* -vm Instance001 -pID *pair id of the rep pair* -USN *usn value returned from previous command*

    With the USN set.  Take a backup using other means or simply stop SQL and do a flat file copy.  Place your data in your destination location specified in the pair.  Simply restart replication.  Setting the USN tells commvault to bypass the baseline phase and simply replicate only changed data.

The content of the forums, threads and posts reflects the thoughts and opinions of each author, and does not represent the thoughts, opinions, plans or strategies of Commvault Systems, Inc. ("Commvault") and Commvault undertakes no obligation to update, correct or modify any statements made in this forum. Any and all third party links, statements, comments, or feedback posted to, or otherwise provided by this forum, thread or post are not affiliated with, nor endorsed by, Commvault.
Commvault, Commvault and logo, the “CV” logo, Commvault Systems, Solving Forward, SIM, Singular Information Management, Simpana, Commvault Galaxy, Unified Data Management, QiNetix, Quick Recovery, QR, CommNet, GridStor, Vault Tracker, InnerVault, QuickSnap, QSnap, Recovery Director, CommServe, CommCell, SnapProtect, ROMS, and CommValue, are trademarks or registered trademarks of Commvault Systems, Inc. All other third party brands, products, service names, trademarks, or registered service marks are the property of and used to identify the products or services of their respective owners. All specifications are subject to change without notice.
Close
Copyright © 2020 Commvault | All Rights Reserved. | Legal | Privacy Policy