In this post we demonstrate what happens when you use
snapshot delete (without the “set diag” level “-ignore-owners true” flag) on a
load-sharing SnapMirror relationship’s reference snapshots. It does not delete,
which is good news versus 7-Mode, as this prevents a storage admin accidentally
deleting a reference snapshot.
Image: Even more
rejoicing…
The Example
To demonstrate, we first walkthrough how to set up a
load-sharing mirror for a Vserver root volume, then try deleting the reference
snapshots, then see what happens when we try to break the LS mirror
relationship (you do not break healthy LS mirrors), and finally show what
happens when we snapmirror promote.
n::>
vol show
vs1_root
(volume show)
Vserver Volume
Aggregate State Type
Size Available Used%
---------
------------ ------------ ---------- ---- ---------- ---------- -----
vs1 vs1_root aggr1_nac1_01
online RW
20MB 18.88MB 5%
n::>
volume
create -volume vs1_root_ls -aggr aggr2_nac1_01 -vserver vs1 -size 20MB -type DP
[Job
113] Job succeeded: Successful
n::>
snapmirror
create -source-path n://vs1/vs1_root -destination-path n://vs1/vs1_root_ls
-type LS
[Job
114] Job succeeded: SnapMirror: done
n::>
snapmirror
initialize-ls-set -source-path n://vs1/vs1_root
[Job
116] Job is queued: snapmirror initialize-ls-set for source n://vs1/vs1_root.
n::>
snapmirror
show
Source Destination Mirror
Relationship
Path Type
Path State Status
Healthy
-----------
---- ------------ ------- ------------- -------
n://vs1/vs1_root
LS
n://vs1/vs1_root_ls
Snapmirrored
Idle true
n::>
snapshot
show vs1_root,vs1_root_ls
Vserver Volume
Snapshot
State Size Total% Used%
--------
------- ------------------------------- -------- -------- ------ -----
vs1 vs1_root
snapmirror.5a944ece-3f34-11e3-9b19-123478563412_7_2147484680.2013-12-06_223541
valid 60KB 0%
33%
vs1_root_ls
snapmirror.5a944ece-3f34-11e3-9b19-123478563412_7_2147484680.2013-12-06_223541
valid 0B 0%
0%
2
entries were displayed.
n::>
snapshot
delete vs1_root_ls -snapshot
snapmirror.5a944ece-3f34-11e3-9b19-123478563412_7_2147484680.2013-12-06_223541
-vserver vs1
Error: command
failed: Volume is read-only.
n::>
snapshot
delete vs1_root -snapshot snapmirror.5a944ece-3f34-11e3-9b19-123478563412_7_2147484680.2013-12-06_223541
-vserver vs1
Error: command
failed: This Snapshot copy is currently used as a reference Snapshot copy by
one or more SnapMirror relationships. Deleting the Snapshot copy can cause future
SnapMirror operations to fail.
n::>
snapmirror
break -source-path n://vs1/vs1_root -destination-path n://vs1/vs1_root_ls
Error: command
failed: snapmirror break is not allowed for destination n://vs1/vs1_root_ls in
a load-sharing relationship.
n::>
snapmirror
promote -destination-path n://vs1/vs1_root_ls
Warning:
Promote will delete the read-write volume n://vs1/vs1_root and replace it with
n://vs1/vs1_root_ls.
Do
you want to continue? {y|n}: y
n::>
vol show
vs1_root*
Vserver Volume
Aggregate State Type
Size Available Used%
---------
------------ ------------ ---------- ---- ---------- ---------- -----
vs1 vs1_root_ls aggr2_nac1_01
online RW
20MB 18.88MB 5%
Volume Modify
Type
You might be wondering what happens if you have deleted
the SnapMirror relationship, and either have no source or all the SnapMirror
reference snapshots have gone (so no chance of resync.)
Are we stuck with a
volume of read-only type DP? NO
Is there a volume
modify -type switch/option? NO
How do you make a
type DP volume read-write (RW) if there is no existing snapmirror relationship
and the source has long gone/lost its snapmirror reference snapshots? Easy! “snapmirror break” will make (convert)
the type DP volume to RW!
Comments
Post a Comment