Snapmirrors - odd behaviour

Hi all, my second question for the day...I have two FAS2020 with snapmirror enabled and licensed. I have a volume on "filer1" called "vol1", this has two ISCSI LUNS for use with an SQL server. I then have an equal sized volume on "filer2" with the same name, I configured snapmirroring and all seemed fine....until the customer/owner of the filers reported that he created an ISCSI group on filer2's snapmirrored volume so that he can view the databases to see if replication is working..and from what he can see file replication is 2 days behind, if I check the snapmirror status it's set to sync every minute, it's idle and it's lag is around a minute. Now here's the strange bit, when we reboot the destination "filer2", after it starts up it shows more data in the destination LUNS than before it was rebooted...

From what I can see the destination volume is not currently restricted however I know that priuor to configuring the snapmirrored volume you need to place the destination volume in restricted mode...does it automatically turn off restricted mode once the initial baseline mirror is completed? I'm not re-running the initialize with the destination volume in restricted mode to see if it behaves as it should.

Does anyone know why this would happen, or wether or not the owner/client should even be accessing LUNS he created on the destination snapmirrored volume?


Snapmirrors - odd behaviour

they are mounting the read-only lun?  If they create a flexclone (a read/write clone of a snapshot that can be destroyed after test) from one fo the snapshots they should see the most current update.  Also, I haven't looked in a while but there is (was) a visibility_interval of the target mirror but from what I remember it was only for semisync and sync methods of snapmirror, not async.

Snapmirrors - odd behaviour

also...the luns will be crash consistent if replicating every minute from snapmirror.conf.  They don't have SMSQL and SnapDrive to quiesce the database?  SnapDrive can be used to roll logs every minute still and gives a consistent lun on the target.

Snapmirrors - odd behaviour

Thanks for the replies

On your first question about read only lun...yeah, the user has created an ISCSI connection to the snapmirrored LUN, which he is viewing on his desktop....however he is able copy data to not so sure about it being read only..I need to check on SMSQL and SnapDrive...I believe they have these this similar to snapmirror? Is snapmirror not capable when it comes to SQL?

Re: Snapmirrors - odd behaviour

They are licensed. And they are compatible with snapmirror. Snapmirror by itself works but does not quiesce mssql without smsql (vdi interface) and does not quiesce ntfs without snapdrive.

Odd the readonly mount works... Maybe the write part is cached.. Or they are cloning the volume to make it writable?

Typos Sent on Blackberry Wireless