Call Manager Database Replication Check (3 Ways)

After going through my lab I added a Call Manager Publisher / Subscriber cluster. Going through the setup I was going to check the database replication status. Here is the awesome command to use in the CLI.

Check database replication method 1:
show perf query class "Number of Replicates Created and State of Replication"

What comes up is a replication status of "2". This is definitely what we want to see. 2 = GOOD! When checking the database via CLI make sure you do it on both servers/all servers in the  cluster.

Check database replication method 2:
Another way to do it is to generate a report inside of CUCM. 

When checking a report in CUCM. Go to the Cisco Unified Reporting Page and when you login select the "System Reports" tab on the top left. Once you select that tab make sure you go down to Unified CM Database Replication Status and Generate New Report. 

Check database replication method 3:

A third way to check the database replication is to check in RTMT which we can get via Call Manager from plugins. When going into RTMT go to Call Manager > Service > Database Summary.

After we go into Database Summary go to the very bottom and you should a small area like the following:

In the image we will see to the far right the status number 0,1,2,3,4 of the database replication.



Last but not least is a small excerpt from Cisco explaining the numbering behind each Database Replication numbering.  

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.