Introduction
Replicating the database represents a core function of Cisco Unified Communications Manager clusters. The server with the master copy of the database acts as the publisher (first node), while the servers that replicate the database comprise subscribers (subsequent nodes).
Tip 
Before you install Cisco Unified Communications Manager on the subscriber server, you must add the subscriber to the Server Configuration window in Cisco Unified Communications Manager Administration to ensure that the subscriber replicates the database that exists on the publisher database server. After you add the subscriber server to the Server Configuration window and then install Cisco Unified Communications Manager on the subscriber, the subscriber receives a copy of the database that exists on the publisher server.
Issue
Changes that are made on the publisher server do not get reflected on phones that are registered with the subscriber server.
Resolution
Verify and, if necessary, repair database replication, as described in the following procedure:
Step 1:- Verify database replication. You can use the CLI, Cisco Unified Reporting, or RTMT to verify database replication.
•To verify using the CLI, see Step 2.
•To verify using Cisco Unified Reporting, see Step 3.
•To verify using RTMT, see Step 4.
Step 2:- To verify database replication using the CLI, access the CLI and issue the following command to check replication on each node. You will need to run this CLI command on each node to check its replication status. Also, after a subscriber is installed, depending on the number of subscribers, it may take a considerable amount of time to achieve a status of 2.:
admin : show perf query class "Number of Replicates created and state of Replication"
==> query class :
-Perf class (Number of Replicates Created and State of Replication)
has instances and values:
ReplicateCount ->Number of Replicates Createds=344
ReplicateCount ->Replicate_State =2
Be aware that the Replicate_State object shows a value of 2 in this case. The following list shows the possible values for Replicate_State:
•0—This value indicates that replication did not start. Either no subsequent nodes (subscribers) exist, or the Cisco Database Layer Monitor service is not running and has not been running since the subscriber was installed.
•1—This value indicates that replicates have been created, but their count is incorrect.
•2—This value indicates that replication is good.
•3—This value indicates that replication is bad in the cluster.
•4—This value indicates that replication setup did not succeed.
Step 3:- To verify database replication using Cisco Unified Reporting, perform the following tasks
a. From the Navigation drop-down list box in the upper, right corner in Cisco Unified Communications Manager Administration, choose Cisco Unified Reporting.
b. After Cisco Unified Reporting displays, click System Reports.
c. Generate and view the Unified CM Database Status report, which provides debugging information for database replication.
Once you have generated the report, open it and look at the Unified CM Database Status. It gives the RTMT replication counters for all servers in the cluster. All servers should have a replicate state of 2, and all servers should have the same number of replicates created.
If you see any servers whose replicate states are not equal to 2 in the above status check, inspect the "Replication Server List" on this report. It shows which servers are connected and communicating with each node. Each server should show itself as local (in its list) and the other servers as active connected. If you see any servers as dropped, it usually means there is a communication problem between the nodes.
d. If you want to do so, generate and view the Unified CM Database Status report, which provides a snapshot of the health of the Cisco Unified Communications Manager database.
Step 4:- To verify database replication using RTMT, perform the following tasks:
a. Open the Cisco Unified Real-Time Monitoring Tool (RTMT).
b. Click the CallManager tab.
c. Click Database Summary. The Replication Status pane displays
The following list shows the possible values for the Replication Status pane:
•0—This value indicates that replication has not started. Either no subsequent nodes (subscribers) exist, or the Cisco Database Layer Monitor service is not running and has not been running since the subscriber was installed.
•1—This value indicates that replicates have been created, but their count is incorrect.
•2—This value indicates that replication is good.
•3—This value indicates that replication is bad in the cluster.
•4—This value indicates that replication setup did not succeed.
d. To view the Replicate_State performance monitoring counter, choose System > Performance > Open Performance Monitoring. Double-click the publisher database server (first node) to expand the performance monitors. Click Number of Replicates Created and State of Replication. Double-click Replicate_State. Click ReplicateCount from the Object Instances window and click Add.
Note:-To view the definition of the counter, right click the counter name and choose Counter Description.
Step 5:- If all the servers have a good RTMT status, but you suspect the databases are not in sync, you can run the CLI command utils dbreplication status
(If any of the servers showed an RTMT status of 4, proceed to Step 6)
This status command can be run on all servers by using utils dbreplication status all
or on one subscriber by using utils dbreplication status <hostname>
The status report will tell you if any tables are suspect. If there are suspect tables, you will want to do a replication repair CLI command to sync the data from the publisher server to the subscriber servers.
The replication repair can be done on all subscriber servers (using the all parameter) or on just one subscriber server by using the following:
utils dbreplication repair usage:utils dbreplication repair [nodename]|all
After running the replication repair, which can take several minutes, you can run another status command to verify that all tables are now in sync.
If tables are in sync after running the repair, you are successful in fixing replication.
No Note :- Only do Step 6 if one of the servers showed an RTMT status of 4, or had a status of 0 for more than four hours.
Step 6:- Generate and view the Unified CM Database Status report, which provides debugging information for database replication. For each subscriber server that has a bad RTMT status, check that the hosts, rhosts, sqlhosts, and services files have the appropriate information.
Generate and view the Unified CM Cluster Overview report. Verify that the subscriber servers have the same version, verify that connectivity is good, and verify that time delay is within tolerances.
If the preceding conditions are acceptable, do the following to reset replication on that subscriber server:
a. At the subscriber server, perform the CLI command utils dbreplication stop
Do this for all subscriber servers that have an RTMT value of 4
b. At the publisher server, perform the CLI command utils dbreplication stop
c. At the publisher server, perform the CLI command utils dbreplication reset <hostname>
where <hostname> is the hostname of the subscriber server that needs to be reset. If all subscriber servers need to be reset, use command utils dbreplication reset all
