COBRAS import for Unity Connection Cluster

Unanswered Question


We setup a Unity Connection Cluster version 7.1 and they are working as they should be, one server is primary server and the other one is the secondary server, vm subscribers can be synchorized between servers.

However after we run the COBRAS import, the secondary server is not working propery: all the primary subscriber information are not synchroized to secondary server; and if we looked at the CUC serviceability, both the servers show status are primary.

My question is that for COBRAS import for cluster, should we shutdown the secondary server before import?

In my case, do I have to rebuild the secondary server?



I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
David Hailey Tue, 05/11/2010 - 09:49

I've worked with COBRAS quite a bit. I don't see any reason why you can't shutdown the server prior to import.  Just shut down the Subscriber if choose to do so.  However, I would suggest you simply reboot the cluster as a first method.

Reboot the Pub (use Cluster Mgmt to view status after reboot)

Reboot the Sub (same thing, use Cluster Mgmt to view status after reboot)

If they don't come back properly, you could try shutting down one node before import.  Once the import is complete and the Subscriber is online and healthy, verify replication to the Sub by logging into it directly and checking the Subscriber table, etc.


Please rate helpful posts!

David Hailey Tue, 05/11/2010 - 11:53

I'm sorry you had an issue but that is not an accurate statement.  If the forums were blowing up with the same issue, I would concede - but I haven't seen many (if any) other complaints of this nature nor have I experienced it in my many interactions with the COBRAS suite.  It is more likely that your secondary server and/or DB replication between the 2 nodes was not working properly before you ever imported data into the cluster.  I have worked with COBRAS quite a bit - Unity to Unity upgrades, Unity to Connection migrations (single node, CUC cluster) and I've never had a problem with the secondary server - especially none like what you describe.  In fact, I recently did Unity to Unity Connection (cluster) migration for a customer with over 4000 subscribers, 200+ Call Handlers, 200+ Distribution Lists, and migrated approximately 48,000 messages for all of the users as well...without issue.  Rebuild of the second node would be a pretty drastic issue if it were being caused by COBRAS migrations (which there are a lot of these days - either on the sales front or the implementation front).  So, good that your issue is resolved...but just needed to hop in regarding the assumption that COBRAS caused your issues.

lindborg Tue, 05/11/2010 - 12:05

Yeah, it's not possible for COBRAS to have interfered with the replication here even if it wanted to.  It uses the stored procs and view in the database to do it's business - it never, ever does direct table edits, or messes with triggers or anything of that nature.  Trust me - that's been reviewed up and down more than once - it plays nice.  It's using the same database interface when creating/editing objects as the SA, BAT and all other tools do - if your replication is working properly adding users/handlers/schedules etc... via BAT or the SA or COBRAS should all replicate over to the secondary fine.  If that's not the case it's far more likely a replication configuration than some sort of rogue tool issue - there's not much a tool could do to break that replciation if it's using the standard interfaces (which COBRAS does).


I am not complain about COBRAS which is a great tool. But I am sure that the replication worked fine before import.

if you looked at your first reply and compared to your 2nd reply I was a little confused, since on the 1st one, you said that you shutdown the seconday server before you do the COBRAS import. So is it correct or not?

What I am looking for is the correct procedure for Unity Connection cluster COBRAS database import in HA environment where I could not find it on the COBRAS help file or possibily I missed.

So in your Cluster enviornment, before COBRAS data imprt, did you shutdown or deactivate the secondary server or not?



David Hailey Tue, 05/11/2010 - 12:12

NO.  You misread my post.  In your original post, you asked: "My question is that for COBRAS import for cluster, should we shutdown  the secondary server before import?".

My answer was that I didn't see any reason why you couldn't; however, I suggested that you reboot the cluster first to see if the server roles corrected themselves and then verify replication.  So, could you shut down your Secondary before import - my answer would be a theoretical yes.  Once you do the import and, assuming the cluster is healthy in general (irrespective of COBRAS), then when you bring the Subscriber online the data should get replicated.  I never said that you have to or should shut down the second node...I just answered the question in your post.

When I read your post, my gut reaction is that "this guy/girl has a problem with the Subscriber in general".  I probably would have tried a few more troubleshooting steps before doing a rebuild but hey, if that works for you then that's fine.  Bottom line is that in some way, shape, or form (whether visible to you or not) - you had an issue with the CUC cluster replication or simply a bad Subscriber build from the start.  COBRAS did not and could not have caused that type of issue.


David Hailey Tue, 05/11/2010 - 12:24

It wouldn't affect replication.

But, in practice - you only need the DB proxy service activated on the Primary because when you connect to the cluster to do the COBRAS import, you should connect to the Publisher as a best practice.

With CUC, the servers should perform the following roles:

Publisher - primary server, handles Database and Web services in normal operations

Subscriber - secondary server, is the Call Processing node - answer calls, etc. and can burst onto Pub ports if needed.



This Discussion