Remote copy slower from secondary to Primary

[jruffer]

We had to failover to our DR site because of a power issue at the primary.

We have found that synchronisation is much slower in the reverse direction.

Any ideas what could be causing this?

Jeremy

[Dennis Handly]

Are the two StoreServs the same model and OS version?

Is one more heavily loaded than the other?

[jruffer]

Same model and OS.

Normally the target of the remote copy is doing nothing else while the source is our production system.

[Dennis Handly]

>Normally the target of the remote copy is doing nothing else while the source is our production system.

That may explain why it is slower, too busy to write the data?

[jruffer]

Found the problem.  It turns out that the default gateway wass missing from one of the replication ports.  Must have gone missing when we had a power outage.

It's looking much better now.

[jruffer]

The relief was only temporary, it's back to being slow again.

The remote copy we have going from primary to secondary are working fine.

[jruffer · Accepted solution]

It looks like we've finally fixed it though we still don't know why it was a problem in one direction and not the other.

The problem is that when heartbeats are missed the 3PAR resets the connections.  The key was to stop the heartbeats from going missing.

We used setcopytarget tput to limit the bandwith to 40% of the link and setrcopytarget tunelinks to the same value with an appropriate latency. In our case 60.  We tried 40 at first and it was a big improvement but we still had dropped heartbeats overnight.