ONTAP Discussions

Releasing a SnapMirror relationship when the destination is no longer reachable.

mike-leblanc

Hey guys, looking for some help here, I have scoured what I could to try and figure this out but I'm really stuck.

Here's the scenario.

I have a source volume of which I had a SnapMirror relationship.

The Snapmirror relationship went from Source Volume on Source Vserver on Source Cluster to Destination Volume on Destination Vserver on Destination Cluster.

At some point that destination was completely decommissioned and wiped out. 

 

However I'm stuck now where there is still a relationship listed on the source volume and the destination is listed as:

-:destination_volume_mirror 

 

I have tried performing a snapmirror release using the source volume, relationship id, all the things that could identify the relationship and I keep getting the error:

Error: command failed: Failed to get information for Vserver -. (entry doesn't exist)

 

Someone help me out here, what's the next steps to try and clean up these old entries?

7 REPLIES 7

Re: Releasing a SnapMirror relationship when the destination is no longer reachable.

Ontapforrum

Hi,

 

Just wondering if you tried the '-force' switch.

 

::> snapmirror release -destination-path vserver:vol  -force true

 

Thanks!

Re: Releasing a SnapMirror relationship when the destination is no longer reachable.

mike-leblanc

Tried the -force switch but to no avail.

Re: Releasing a SnapMirror relationship when the destination is no longer reachable.

PedroFrancisco

Use the command to identify the snapmirror and releationship-id:

 

snapmirror list-destinations -source-volume SOURCE_VOLUME

 

So, You need use the command:

 

snapmirror release -source-path SVM:SOURCE_VOLUME -relationship-id ID -force true

 

Regards

 

 

Re: Releasing a SnapMirror relationship when the destination is no longer reachable.

mike-leblanc

OK here's the result of that (which I know I've already tried), I'll obfuscate the system specific stuff:

crp-nap::> snapmirror list-destinations -source-volume sourcevolume
Progress
Source Destination Transfer Last Relationship
Path Type Path Status Progress Updated Id
----------- ----- ------------ ------- --------- ------------ ---------------
vserver:sourcevolume
XDP -:destinationvolume
- - - <relationshipID>

 

cluster::> snapmirror release -source-path vserver:sourcevolume -relationship-id <relationshipID> -force true *

*note the asterisks at the end for wildcard

 

Returns:

 Error: command failed on source-path "vserver:sourcevolume" destination-path "-:destinationvolume": Failed to get information for Vserver -. (entry
doesn't exist)
0 entries were acted on.

Re: Releasing a SnapMirror relationship when the destination is no longer reachable.

Ontapforrum

It's going to be tricky b'cos it's trying to lookup and it cannot make contact with the destination cluster/svm/vol etc.

I guess, it's not a show stopper but you would like to get rid of them cosmetically.

On the source, do you see peer-relationships for remote cluster and vserver:
::> cluster peer show
::> vserver peer show

Re: Releasing a SnapMirror relationship when the destination is no longer reachable.

mike-leblanc

No entries in the peer relationships for cluster nor vserver.

Those were removed.

 

Even if removed "cosmetically" having some sort of reference to a relationship might affect my ability later to offline and delete this volume in the future.

 

At this point I am considering moving this data to another volume, and cutting over the junction path to this new volume. 

Then doing my best later to try and delete this volume or orphan it when I end up upgrading this system in the future (which we usually do the process of going from 2 node cluster to 4 node cluster, migrate volumes to new nodes and then go back down to 2 nodes).

However that seems like a lot of work for what should be an easy command to remove a relationship.

Re: Releasing a SnapMirror relationship when the destination is no longer reachable.

mike-leblanc

I figure I'll offer a followup for anyone who might come across this issue.

I contacted NetApp support, they escalated it a bunch and eventually gave me the commands to be able to remove the relationship directly from the SMDB.

 

Once removed from the SMDB I was finally able to delete those volumes.

Basic commands were done it diag mode and started with:

debug smdb table localSrcSnapMirror show

and using that info

debug smdb table localSrcSnapMirror delete .....

 

I would however seek guidance from NetApp Support on how best to perform this action as it is a pretty volatile command.

 

 

 

View solution in original post

Earn Rewards for Your Review!
GPI Review Banner
All Community Forums
Public