We all know that CUCM database replication issues are serious. We are checking database every time there is an upgrade, server cores, new machine is added, etc., just to ensure that our customer will have properly functioning environment.

We all know CLI commands like utils dbreplication status or utils dbreplication runtimestate, but what these commands really do and what is the logic of using them?

I’ve seen many people running runtimestate command as a basic database replication test. You just check if servers are connected with status of “(2) Setup Completed” and all’s good, isn’t it?

Let’s take a look at example dbreplication check. I just put show status command bellow for time reference. Please notice the date: Feb 12th, 2017.

Now, let’s just run our old good utils dbreplication runtimestate:

Interesting huh? Output says “Replication status command started at: 2017–01-23-05-42“, but the date we’re running the command is actually 2017-02-12. 

What does it mean? Well, here is the thing – utils dbreplication runtimestate, apart from showing the replication setup in real time, shows the output of database tables check. But what actually starts the table check is utils dbreplication stauts command. What does it mean is that when you’re logging into your CUCM and you just run runtimestate command, server will show you the outcome of table check from the last time you issued utils dbreplication status command. In my example that was 23rd of January 2017. So if you really want to check what is your current table status, you should always run utils dbreplication status command first, followed by utils dbreplication runtimestate to see if check is completed.

Let’s take a look at the bellow example. I run status command:

Now lets run runtimestate:

See? Now we have info that replication status command started at the day we actually want to check it. There is also information that “Replication status command COMPLETED 42 tables checked out of 681“. This is perfectly normal. CUCM is just checking every table in its database, which takes time (the bigger database you have the longer it can take). Let’s wait couple minutes and run runtimestate command again:

CUCM checked its all 681 tables and found no errors. That’s the proper check.

In case you have an issue with database and there are errors or mismatches, there is a very good article posted on Cisco Support Forum which goes deeply into database troubleshooting procedure and I strongly recommend to read it:

https://supportforums.cisco.com/document/52421/troubleshooting-cucm-database-replication-linux-appliance-model

Thanks!