Make plans now to attend XMPP integration with CVP 2012/06/14 @ 10:00 AM at Cisco Live! in San Diego. ...Read More

 



Cisco Developer Network will be presenting a CDN Developer Track at Cisco Live! London the week of January 31, 2011.

We are presenting technical sessions which highlight Application Programming interfaces (APIs) and Software Developer Kits (SDKs) for Cisco technologies such as Unified Communications, IOS, and Access Routing Technologies ¿ including the new Cisco Cius ...Read More

 

Recently noticed that there have been repeated questions from our developer community complaining that they can't seem to get the beep to work with <record>. They have set the beep attribute to "true" alright, and the reference guide even says this is supported but why doesn't it work?
...Read More

 

August 01, 2006
Earlier today, as I was typing a comment in our internal issuing-tracking system, I hit backspace to correct a typo. WHAM! I go back to the previous page, and my long-winded comment is gone. Apparently I somehow left the context of the text area (did I tab, or spuriously click, or??), which causes backspace to act as a hotkey for "Back". The web browser was not very forgiving of my mistake.

Are your IVR applications forgiving? They should be.
...Read More

 

Mark Gibbs over at Network World has put together a spiffy little scoring system for customer service systems (including many criteria for IVR systems). How would callers score your IVR using Mark's guidelines? Place a call and find out, you may be surprised.
...Read More

 

If you're using JNDI to connect to your database through Tomcat, then it's possible you've had to deal with database connection pool leaks. Your code tests fine, it's been reviewed, but in load tests or in production your app is unable to acquire database connections, the pool is empty!

Fear not, there are some handy parameters which can be set in your application's XML configuration file (in tomcat/conf/Catalina/YOUR_IP/YOUR_APP.xml):
...Read More

 

Showing 6 results.
Items per Page 50
of 1
First Previous Next Last

CVP Forum

« Back to CVP - All Versions

HDS Sync process

Combination View Flat View Tree View
Threads [ Previous | Next ]
HDS Sync process
Answer
12/20/12 9:21 PM
Geoff,
Posting it here as could not get any response on ICM forum.
I would like to understand in details on how the syncing process happens in a setup where there are 2 HDS servers, 2 loggers.  Also what can cause one of the HDS server to go out of sync even though loggers and one of the HDS is in sync.  I have had this happen and do not have a good explanation yet.
I want to look at this process in detail and also what order the tables get updated.
Thanks,
Hemal
Flag

RE: HDS Sync process
Answer
12/20/12 9:39 PM as a reply to Hemal Mehta.
The Logger to HDS sync process is between a single Logger and a single HDS, and is exclusive of the Logger sync process between duplexed Loggers. There is a separate process (replication - rpl or hrpl now, I think) that controls the synchronization of data between a Logger and HDS.
So the standard setup for a duplexed Logger and HDS setup is that you have Logger A and HDS "A" set up to replicate, and then Logger B and HDS "B" to replicate. The HDSs know nothing of each other, and have no synchronization between them. This means the situation you describe is entirely possible, that is: both Loggers in "synch" and one HDS in synch, but the other HDS out of synch. It simply means the historical replication between the HDS and the Logger it is synching to has failed somehow.
As for the order of replication of the tables, I used to know that, but I think it is pretty simple in theory (like alphabetical by table name), but I also believe it cycles through each table in this order in smaller time chunks until it is fully replicated, then it performs differential synchs using the same method.
 - Bill
Flag

RE: New Message from Bill Webb in Customer Voice Portal (CVP) - CVP - All V
Answer
12/20/12 9:48 PM as a reply to Bill Webb.
Thanks Bill. I if you have a situation where the Logger A has up todate date and HDSA incorrect and Logger B incorrect data and also HDS B has incorrect data. What would be the best way to correct it ? Would you restart process on A to kick of the replication and update HDSA and also export A to B logger and do the same on B ?
Hemal

From: Cisco Developer Community Forums [mailto:cdicuser@developer.cisco.com]
Sent: Thursday, December 20, 2012 3:40 PM
To: cdicuser@developer.cisco.com
Subject: New Message from Bill Webb in Customer Voice Portal (CVP) - CVP - All Versions: RE: HDS Sync process

Bill Webb has created a new message in the forum "CVP - All Versions": -------------------------------------------------------------- The Logger to HDS sync process is between a single Logger and a single HDS, and is exclusive of the Logger sync process between duplexed Loggers. There is a separate process (replication - rpl or hrpl now, I think) that controls the synchronization of data between a Logger and HDS.
So the standard setup for a duplexed Logger and HDS setup is that you have Logger A and HDS "A" set up to replicate, and then Logger B and HDS "B" to replicate. The HDSs know nothing of each other, and have no synchronization between them. This means the situation you describe is entirely possible, that is: both Loggers in "synch" and one HDS in synch, but the other HDS out of synch. It simply means the historical replication between the HDS and the Logger it is synching to has failed somehow.
As for the order of replication of the tables, I used to know that, but I think it is pretty simple in theory (like alphabetical by table name), but I also believe it cycles through each table in this order in smaller time chunks until it is fully replicated, then it performs differential synchs using the same method.
- Bill
--
To respond to this post, please click the following link: http://developer.cisco.com/web/cvp/forums/-/message_boards/view_message/9626782 or simply reply to this email.
Flag

RE: New Message from Hemal Mehta in Customer Voice Portal (CVP) - CVP - All
Answer
12/20/12 10:27 PM as a reply to Hemal Mehta.
The MOST important thing is that the two loggers are synchronized. Turn off both HDS and get the loggers synchronized. The HDS will catch up – you have typically 14 days retention of historical data on a logger.

Regards,
Geoff
Flag