The procedure of data replication is all about storing data over one site or node. It is helpful in the enhancement of data accessibility. It just entails copying data from a database from server to server so that every user can obtain a piece of similar information without inconsistencies. In data replication, data is obtainable at various sites, but a certain relation has to be located in only one location. There can be complete replication wherein the whole database is stored at every location. There can be incomplete replication, too, wherein some recurrently employed fragment of the database is replicated, and others aren’t replicated. Let us now discuss the steps to troubleshoot call manager database replication issues.
Steps to Troubleshoot Call Manager Database Replication Issues
Step 1: Verify the network reachability of every node
Ping every node from an apparatus in the administration VLAN (where they should all be within reach) to check whether they are all online and accessible.
If every node is accessible, head to the next step; if not, check the node’s power state or the network issues that are averting it from being reached.
Step 2: Verify the network accessibility among every CUCM nodes
Use the command mentioned below to check the ping accessibility from the Publisher node to all of the Subscriber nodes and vice versa. If the nodes are properly connected, go to the next step; if not, troubleshoot the network issues while ensuring each node is accessible.
Step 3: Ensure DNS and reverse DNS record accessibility of every node
In the scenario of malfunctioning of DNS and if the servers are defined with the hostnames, it may result in database replication problems.
The command for checking DNS configuration
To view how to set up name resolution servers on Linux, use the resolvectl status command. Use resolvectl to display DNS server data. Use the Network Manager graphical tool to display DNS server information. To display the set-up name resolution servers on macOS, use scutil —DNS.
Step 4: Check NTP Accessibility
NTP has to be fully functional to avoid any issues with database replication. The NTP server’s stratum, which is essential for the proper operation of database replication, must be less than 3, which also plays a part in this.
Step 5: Check the connectivity status of each of the nodes
Run the following command on every node within the cluster to check if the database connectivity is successful if all the checks pass.
If you receive a “Cannot send TCP/UDP packets” error message, see whether TCP/UDP ports are opened within the network. After this, run the “Show network cluster” command to check the authentication of every node.
If any nodes appear to be unauthenticated, check if:
- There is network connectivity.
- All nodes use the same security password.
Step 6: See whether the needed services are operating
The mentioned command can be executed to check whether the Cisco DB service is functioning on every node:
If A Cisco DB service is down on a node, operate the “utils service start A Cisco DB” command to twitch the service. In case you see a problem, initially connect with Cisco TAC. Restarting the note may correct the problem, but it’s not advisable.
Step 7: Restoring particular or all tables impacted by database replication
If each of the steps mentioned above has been completed, everything should be functioning perfectly, with the exception of database replication. The next step is to restore the database tables in hopes of fixing the replication issue.
Step 8: Reset Database Replication
Carry on with the database replication reset from scratch if the step above does not solve the problem. To correct and reset the data replication, here is a step that you should follow.
- On the subscriber node, run the “utils dbreplication stop” command and let it be finished before starting the further steps.
- On the publisher node, run the “utils dbreplication stop” command and let it complete.
- Run the “utils dbreplication runtimestate” command on both the publisher and subscriber nodes. Make that both the servers are RPC accessible.
- On the publisher node, run the “utils dbreplication dropadmindb” command and wait for a while to begin the further steps.
- On the subscriber node, execute the “utils dbreplication dropadmindb” command and let it complete.
- On the publisher node, execute the “utils dbreplication reset all” command and wait for it to complete.
- Restart the Subscriber now, and wait for it to start with each of its services.
- Execute the command on a frequent basis while monitoring the RTMT state on the Publisher and Subscriber nodes.
