Synchronous SnapMirror latency


A partner asked me this week how Sync SM handles lag time. I've been comparing the descriptions in the 7.2, 7.3 and 8.x 7-Mode admin guides as well as TR-3326. I notice some differences such as "outstanding" parameter being deprecated and, it is fairly clear what occurs if if a network issue arises. But what happens if the ack time from the secondary lags to the point where write acks to the host application start to exceed timeouts? Does it drop back to the 1 minute intervals until it is caught up again as described in the networking issues section. I thought that I remembered it would drop back into semi-sync mode but can't find any docs that state that.

I of course understand that best practices would dictate that one should have thought about network B/W and latency in the architecting phase but what if the unexpected happens and you're in a situation like this. Am I overlooking something basic?

Re: Synchronous SnapMirror latency

When timeout thresholds are exceeded, it will drop to async. It will try every minute to get back into sync. Once the network is backup, it will then transition back into sync by way of -- async updates, CP forwarding and NVLOG forwarding.

Re: Synchronous SnapMirror latency

Thanks for the response. I actually found a great explanation of this in the NCDA training manual I received some years ago. The reason I posted the question was because I tried to research this with partner SE and, in the Online DPR Admin Guide, the only explanation is under a heading based on networking issues. There can be other issues such as hardware problems on the secondary and there is no mention of this in the admin guide. The NCDA training guide however states that any problem whether networking or hardware will cause the same reaction of back off to async.

The important part we were interested in is acks to the host app. It's my understanding from my readings that once it falls back to async mode the host app writes are acknowledged once the write is committed to the primary.

Thanks again.