This post is more than 5 years old
11 Posts
0
1216
Did Pool do a content failover on my clip?
I was wondering if there was a way to query either the Pool or the Clip to find out if a content failover occurred. We have one particular document that takes a long time for the clip to be retrieved, and we suspect it may be corrupt on our primary centera and therefore it's coming over the wire from our secondary centera nodes, which are hosted in a different state. I was hoping that I could use one of the Pool or Clip properties to determine if that is truly the case or not. Is there a property on one of these objects that would tell me that?
Thanks
-VG
mckeown_paul
409 Posts
0
November 6th, 2012 13:00
You could try a clip exists call rather than an open call. The clip exists by default will not failover to the replica, unlike the open. This will show it failing on the primary, If it fails yo ushould probably see the error blob id mismatch. Let me know what error you see.
vgmni
11 Posts
0
November 7th, 2012 05:00
Thank you for your help Paul! I put in logic to log to our database If Not thePool.ClipExists(clipID)
and sure enough, the ClipExists was false, and therefore my message was logged. It was still able to retrieve the clip, presumably from the backup nodes. So we will now try to look into why this Clip does not exist on the primary nodes. Thanks again for your help!
-VG
mckeown_paul
409 Posts
0
November 10th, 2012 04:00
I would recommend you only do this when in a DEBUG mode. If you do a clip_exists on every read then you are adding the overhead of doing the operation (which is significant) to the cost of doing a read ( approx doubling the length of time).
If you are willing to pay that price for every read to catch the (hopfully) very occasional error like this then fair enough, but I wouldn't recommend this.
vgmni
11 Posts
0
November 13th, 2012 04:00
Hi Paul, thank you, we understand the performance implications but we wanted to find approximately how many clips have been affected by this so we added the logging to our production systems (it hasn't seemed to slow down the process much). As it turns out we have found 85 clips so far that do not exist on one of our node clusters. We have someone from EMC coming on site this week to help with an upgrade and we hope to resolve this soon, and make sure that our replication is working properly.
-VG