Does Mapr create a snapshot on a volume who's snapshot schedule is set to "none", but a mirror-schedule assigned to the volume?
There are two types of schedules 1) Snap schedules and Mirror schedules.Purpose of each schedule is different.
1)Snap schedule is basically to create snapshot backup for a volume
2)Mirror schedule is to trigger mirroring for a volume.
Mirror is the process which take snapshots in source and destination volumes before starting mirroring and transfer the data from the source snapshot.
As such there is not much meaning to set snap schedule for a mirror volume because mirror itself is a backup for source volume. But it would be useful when converting mirror volume to RW volume.
If setting "snap schedule" to "none", it doesn't mean we are disabling snapshot feature for a volume. But it means, automatic snapshot will not trigger for a volume according to schedule frequency/rules. You can still take snapshot for a volume manually using maprcli command or MCS.
Here in your question, you are setting snap schedule to "none" but mirror schedule is set. When mirror triggers, it creates snapshot on source and destination volume so that why you were seeing those snapshots.
Hope i answered your questions. Please let me know if you have any further queries.
Hello Karthik. A mirror of a MapR volume will always take a snapshot of the volume first before initiating the mirror calls. This, to the best of my knowledge, is irrespective of the regular snapshot schedule (or lack of) in place.
Hope that helps.
Hello Mufeed, Yes,I agree with you for a regular volume!
*correction, this is not a regular volume, this is mirror-volume on remote cluster.
Hmm, if it is a destination volume then no snapshots will be involved if the schedule is set to none. In a mirror relationship snapshot is automatically taken at the source alone, as you are already aware.
Just curious to understand the reason behind your ask? Are you seeing anything out of the normal? Please let us know.
Yes, we are seeing snapshots created on a mirror volume which has a snapshot schedule set to "none" (disabled).
Smit Jain Any quick thoughts from the description of the symptoms?
Thank you Smit for that detailed explanation :-). Even I learned something new (I wasn't quite aware that snapshots happened at the destination as well during the mirroring operation).
So, my question, your answer to which I hope will benefit others going through this thread as well - taking the snapshot at the source is understandable in trying to maintain a consistent point-in-time data-state before initiating the mirror. But what does the snapshot at the destination help with during the same cycle? Is it to maintain a last-known-good-state automatically at the destination so that in the event of any issues this will somehow be used to maintain data integrity and consistency?
Yes Mufeed, you got it right. There could be a case where inconsistency introduced in a source volume will propagate to mirror volume by mirroring and immediately after that source volume/cluster not available then we can recover to last consistent state using this snapshot :-)
Thank you Smit.
One question is if mirror gets completed, isn't the snapshot supposed to expire in destination cluster ? we see it isn't .
Default expiry time for mirror snapshot is 7 days. After that it got deleted.
the expiry of mirror snapshot is same as mirror schedule attached for the volume. i.e., my snapshot schedule is set to none , and i have mirror schedule to expiry the mirror in 2 days ,
mirror snapshots are expiring in 2 days as well which shouldn't be.
Retrieving data ...