This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Replication WAN Issue

We recently updated our core at our DR facility to 6.2.1.100. Our main facility is at 6.3.1.100. We replicate roughly 100 servers at night. Since we upgraded to 6.2.1.100 we noticed that our replication is taking an extra hour to hour and a half to complete. Network graphs show that we are not using 100% of the WAN connection when we replicate at night. The connection will go up and then it looks like before it starts the next server replication the connection stops and waits and then starts the next server. If we replicate one server with a large amount of data the software uses the entire WAN connection for that one server. We have never had an issue with this prior to upgrading DR. Our nightly replication always used 100% of the WAN connection until all servers we replicated to DR. We didn't make any configuration changes to the network or to the backup settings when we upgraded to this new version but we now have encountered this issue. Can anyone give me any thoughts on this?

Parents

0 Emte over 5 years ago
I believe Cores need to be on the same version for replication. I am surprised it is working at all

support.quest.com/.../how-to-upgrade-to-the-most-recent-version-of-rapid-recovery

Target Cores: If upgrading a multi-Core environment, upgrade Target Cores first.
NOTE: Replication cannot be resumed unless the Target Core is of an equal or greater build than the Source Core.
Cancel
Up 0 Down

Cancel
0 tim.sweet over 5 years ago in reply to Emte

Thanks for your response but if I am reading this correctly we need to update the target core first, as long as we do that then everything should work properly. That's what we did we upgraded the target core first and we picked up this issue. We are reluctant to upgrade our source core in fear that this will cause additional slowness to the process.
Cancel
Up 0 Down

Cancel

Reply

0 tim.sweet over 5 years ago in reply to Emte

Thanks for your response but if I am reading this correctly we need to update the target core first, as long as we do that then everything should work properly. That's what we did we upgraded the target core first and we picked up this issue. We are reluctant to upgrade our source core in fear that this will cause additional slowness to the process.
Cancel
Up 0 Down

Cancel

Children

0 Emte over 5 years ago in reply to tim.sweet

You are probably right. No idea if the issue with performance is related directly to the new build or the version difference between cores. Of course there is no way to find out either since RR does not log any performance detail of use
Cancel
Up 0 Down

Cancel