ONTAP Discussions

Snapmirror Synchronous isn't synching immediately

Stormont

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

1 ACCEPTED SOLUTION

Sergey_Osipov

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

https://kb.netapp.com/Advice_and_Troubleshooting/Data_Protection_and_Security/SnapMirror/SnapMirror_Synchronous_doesn't_show_changes_on_destination_vo...

 

View solution in original post

3 REPLIES 3

Sergey_Osipov

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

https://kb.netapp.com/Advice_and_Troubleshooting/Data_Protection_and_Security/SnapMirror/SnapMirror_Synchronous_doesn't_show_changes_on_destination_vo...

 

View solution in original post

Stormont

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.

paul_stejskal

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.

Announcements
NetApp on Discord Image

We're on Discord, are you?

Live Chat, Watch Parties, and More!

Explore Banner

Meet Explore, NetApp’s digital sales platform

Engage digitally throughout the sales process, from product discovery to configuration, and handle all your post-purchase needs.

NetApp Insights to Action
I2A Banner
Public