How to Check DB Replication status in CUCM?

CUCM uses Informix as its database , and there is no native access to it, other then through AXL queries and queries via CLI. (Unless you are a Cisco TAC engineer, in which case a local hash value gets put into a hash value, which will the generate temporary root access).

If db replication breaks, there are many symptoms such as phones registered on call manager group A are unable to call phones on call manager group B, or when logging into extension mobility on Subscriber A, when DB replication is bad another, phone registered on Subscriber B might not be able to complete a call to the newly logged in user.

We can check the DB replication status of the call manager in three ways.

CLI

Step1: Open CUCM CLI via Putty.

Step2: Put the command “utils dbreplication runtimestate”.

1: This lets you know the last action performed and the time of the action. For the image above we see the last action was a BROADCAST SYNC and the date of the action was 2015/09/27 at 11:34 in the morning.

2: This tells you if any tables were repaired, and how many tables have been checked after you executed the utils dbreplication status command

3: If there are tables out of sync you will see something similar to “errors or mismatches found”

4: Using this file view command allows you to look at the file in the activelog. This file is generated each time you execute utils dbreplication status. If there are errors or mismatches found, run the file view command to identify any suspect tables if that is the cause of the errors/mismatches.

5: This is the database version. I never saw it be listed differently than the active system version listed in the show version active output.

6: This is the replication timeout for all the nodes.

7: This is the ping time between the servers.

8: This lets you know if the DB, RPC, and DBMon services are working fine.

   DB = A Cisco DB
   RPC = A Cisco DB Replicator
   DbMon = Cisco Database Layer Monitor

9: This shows how many bytes of replication data in queue to be sent to a particular node. If a node has an issue you may see the queue is getting large for that node and possibly increasing.

10: This shows the node id. g_# with the number being the node id. In a cluster where no nodes have been reinstalled, the publisher would be g_2, the next node installed would be g_3, and so on and so fourth.

11: This shows the RTMT states for database replication. There are 5 states.

Value	Meaning	Description
0	Initialization State	This state indicates that replication is in the process of trying to setup. Being in this state for a period longer than an hour could indicate a failure in setup.
1	Number of Replicates not correct	This state is rarely seen in 6.x and 7.x but in 5.x can indicate its still in the setup process. Being in this state for a period longer than an hour could indicate a failure in setup.
2	Replication is good	Logical connections have been established and tables match the other servers on the cluster.
3	Tables are suspect	Logical connections have been established but we are unsure if tables match. In 6.x and 7.x all servers could show state 3 if one server is down in the cluster. This can happen because the other servers are unsure if there is an update to a user facing feature that has not been passed from that sub to the other device in the cluster.
4	Setup Failed / Dropped	The server no longer has an active logical connection to receive database table across. No replication is occurring in this state.