SnapMirrors go into a queued state after upgrade to ONTAP 9.2
Applies to
ONTAP 9.2 and later
Issue
- On SnapMirror destination cluster nodes with multiple source cluster nodes, some SnapMirrors go into a queued state after the update schedule is triggered, after a manual update, or during initialization.
- SnapMirror transfers are typically always queued initially, but relationships impacted by this issue will report they are queued and will stay in the queued state for some time before starting the transfer as seen in the
/etc/log/snapmirror_auditlogs. - Below, the relationship starts replicating one hour after waiting in a queued state.
EXAMPLE:
Wed Sep 13 13:10:01 2017 CreateSnapshotDest[Sep 13 13:10:00]:7caa055a-e032-11e5-95d8-00a0985dae38 Operation-Uuid=bcf90269-2d39-4d80-90f7-1852860e3da4 Group=none Operation-Cookie=0 action=End source=srcSVM:srcVol destination=dstSVM:dstVol status=SuccessNote=Scheduled update operation is queued.Wed Sep 13 13:10:01 2017 CreateSnapshotDest[Sep 13 13:10:00]:7caa055a-e032-11e5-95d8-00a0985dae38 Operation-Uuid=bcf90269-2d39-4d80-90f7-1852860e3da4 Group=none Operation-Cookie=0 action=End source=srcSVM:srcVol destination=dstSVM:dstVol status=SuccessNote=Scheduled update operation is queued.Wed Sep 13 14:09:27 2017 ScheduledUpdate[Sep 13 13:10:00]:7caa055a-e032-11e5-95d8-00a0985dae38 Operation-Uuid=bcf90269-2d39-4d80-90f7-1852860e3da4 Group=none Operation-Cookie=0 action=Start source=srcSVM:srcVol destination=dstSVM:dstVol- In these cases, some SnapMirrors continue to work and run immediately.
- In addition,it may not be the same relationships which are queued each time the issue is noticed.Once the transferring relationships complete, the queued relationships begin their transfer.