ONTAP Discussions
ONTAP Discussions
We have two clusters that are both running 9.7P5. On Cluster A, we have a volume that has a CIFS share associated with it. We then have a Snapmirror Sync relationship with Cluster B. For some reason, when a user updates a file in the original volume, the changes aren't replicated to Cluster B until 5 minutes after the hour (or a manual update). Our understanding is that a write to the source volume would be written immediately to the source and destination?
Below is the information for the relationship in case it helps:
Oriole::> snapmirror show -destination-path oriole-svm:sm_s_prj004_NTFS
Source Path: cardinal-svm:prj004_NTFS
Destination Path: oriole-svm:sm_s_prj004_NTFS
Relationship Type: XDP
Relationship Group Type: none
SnapMirror Schedule: -
SnapMirror Policy Type: sync-mirror
SnapMirror Policy: Sync
Tries Limit: -
Throttle (KB/sec): unlimited
Mirror State: Snapmirrored
Relationship Status: InSync
File Restore File Count: -
File Restore File List: -
Transfer Snapshot: -
Snapshot Progress: -
Total Progress: -
Network Compression Ratio: -
Snapshot Checkpoint: -
Newest Snapshot: snapmirror.477874a4-49e1-11e6-934f-00a098a22fa1_2153295841.2020-08-18_110500
Newest Snapshot Timestamp: 08/18 11:05:00
Exported Snapshot: snapmirror.477874a4-49e1-11e6-934f-00a098a22fa1_2153295841.2020-08-18_110500
Exported Snapshot Timestamp: 08/18 11:05:00
Healthy: true
Unhealthy Reason: -
Destination Volume Node: Oriole-01
Relationship ID: 60d303d6-db52-11ea-9aa3-90e2ba9be160
Current Operation ID: -
Transfer Type: -
Transfer Error: -
Current Throttle: -
Current Transfer Priority: -
Last Transfer Type: resync
Last Transfer Error: -
Last Transfer Size: 2.97KB
Last Transfer Network Compression Ratio: 1:1
Last Transfer Duration: 0:0:12
Last Transfer From: cardinal-svm:prj004_NTFS
Last Transfer End Timestamp: 08/10 17:57:43
Progress Last Updated: -
Relationship Capability: 8.2 and above
Lag Time: 0:0:0
Identity Preserve Vserver DR: -
Volume MSIDs Preserved: -
Is Auto Expand Enabled: -
Number of Successful Updates: 187
Number of Failed Updates: 0
Number of Successful Resyncs: 1
Number of Failed Resyncs: 0
Number of Successful Breaks: 0
Number of Failed Breaks: 0
Total Transfer Bytes: 15879
Total Transfer Time in Seconds: 12
Solved! See The Solution
This is expected behavior. User reads to a SnapMirror Synchronous (SM-S)
destination volume are redirected to the latest exported Snapshot for the SnapMirror
Synchronous relationship
If the SnapMirror Synchronous relationship is healthy and "InSync", writes to the source
volume are still being replicated synchronously and will be available in case of a
disaster recovery scenario.
https://www.netapp.com/us/media/tr-4733.pdf
Chapter 3.12
Here is a KB as well
This is expected behavior. User reads to a SnapMirror Synchronous (SM-S)
destination volume are redirected to the latest exported Snapshot for the SnapMirror
Synchronous relationship
If the SnapMirror Synchronous relationship is healthy and "InSync", writes to the source
volume are still being replicated synchronously and will be available in case of a
disaster recovery scenario.
https://www.netapp.com/us/media/tr-4733.pdf
Chapter 3.12
Here is a KB as well
That is unfortunate, as our understanding was that we would be able to instantly see the file in location A and B immediately after a change was made. We have an application that needs to be able to read from the secondary copy, but it sounds like we can't make the sync happen more often than 30 minutes.
The technology was designed for as close to possible RTO, not DR type file mirroring. You may want to look at Flexcache for your solution needs. It seems like the network is close so that should offer good performance.
We also have a cloud based product GFC that can be used in physical environments (from Talon). Perhaps this may meet your needs?
If you're unsure, a discussion with the account team is definitely a possibility to ensure you are getting the products that meet your needs.