ONTAP Discussions

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

mike-leblanc
9,926 Views

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?

1 ACCEPTED SOLUTION

mike-leblanc
8,552 Views

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

10 REPLIES 10

Ontapforrum
9,916 Views

Hi,

 

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

 

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

 

Thanks!

mike-leblanc
9,910 Views

Tried the -force switch but to no avail.

PedroFrancisco
9,901 Views

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

 

 

mike-leblanc
9,886 Views

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.

Ontapforrum
9,878 Views

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

mike-leblanc
9,859 Views

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.

mike-leblanc
8,553 Views

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.

 

 

 

chris316
4,934 Views

I have the same problem and the command worked on my cluter.

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

*note the asterisks at the end for wildcard

 

derrick
3,894 Views

This worked for me too, for some reason when you specify the destination-path its saying entry doesn't exist. But when doing the wildcard(asterisks)  it worked.

ParthaSC
3,664 Views

here is what i think can be done to rectify the issue :

 

Clearing Dupe Vol MSID from the Table: applicationSG

Clearing Dupe Vol MSID from the Table: application

Clearing Dupe Vol MSID from the Table: applicationPG

 

Command :

debug smdb table applicationPG show

debug smdb table applicationPG Delete 

 

Public