Dbmonpreflightcheck File Is Found Locally Please Check Again in Few Minutes

CUCMuses IBM Informix for database needs. Nosotros accept no native admission to this (unless you are a Cisco TAC Engineer who can gain temporary access to root).

If DB replication breaks, we see many symptoms in our IPT network like Phone registered to a Subscriber unable to brand calls to phones registered on the other subscriber, unable to login to extension mobility etc.

We tin make utilise on any one of these methods to cheque replication status:

•  Open RTMT -- Click on : Call Manager --> Service --> Database Summary

• Open a web browser, type in https://<IP address>:8443/cucreports/ ,Enter your authorized username and password.
  Go to : Database Status Report

• Using putty, SSH to the CUCM to take CLI access and run this command : utils dbreplication runtimestate --> REPl.LOOP? is the current state.

Here is what the replication state means :
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.

i - Number of replicates non correct : This land is rarely seen, tin can indicate its nevertheless in the setup procedure. Beingness in this land for a flow longer than an hr could indicate a failure in setup.

2 - Replication is good : All is well in paradise :)

3 - Tables are suspect : Logical connections have been established merely nosotros are unsure if tables match. This tin can happen because the other servers are unsure if  at that place is an update to a user facing characteristic that has not been passed  from that sub to the other device in the cluster.

four - Setup failed / Dropped : The server no longer has an active logical connection to receive  database table across. No replication is occurring in this state.

If State is other than 2, check:

• Server & Cluster connectivity : Bank check TCP/UDP ports needed to be opened on the network. To get the port list for your CUCM version, merely google : CUCM < your version> ports

• Configuration files (if on older CUCM - extremely rare) :

1. /etc/hosts ---> local resolution of hostnames to IP addresses
2. /habitation/informix/.rhosts ---> hosts trusted to brand database connections
3. $INFORMIXDIR/etc/sqlhosts ---> full list of CCM servers for replication

• Cheque if server times are correct and synced (NTP working fine)
• DNS not configured properly (forwards/reverse lookup)
• NTP not reachable/time drift betwixt server
• A Cisco DB replicator service not running/not working
• Cisco Database Layer monitor (DbMon) hung/stopped

Useful Commands :

• utils dbreplication setrepltimeout -- The default value is set to 300 seconds. You can validate this by running "show tech repltimeout". This is the timer used to put multiple servers into 1 run of the information sync. In other words, information technology is the "batching" timer. This affects when the broadcast realize template and data sync volition fire (n seconds from the finish of the first divers server). Clustering over WAN (CoW) long delays can cause the data sync process to be exponentially longer. Try to sync the local servers first.

• utils dbreplication repair -- in CUCM 5.x, this command meant a reset of the replication, whereas, in CUCM 6.10 and higher versions, this means a repair of the data. It runs a repair process on all tables in the replication for all servers that are included in the command. Run this command when RTMT = 2, not when RTMT = 0 or 3.

• utils dbreplication repairtable / repairreplicate -- This command substantially does the same affair as the repair command, simply runs on only one table / replicate, hence making the process much faster. It fixes the out of sync data for that tabular array / replicate. Yous can verify by running "utils dbreplication condition" to run into if there are whatsoever mismatches or errors institute. It is peculiarly useful on large CUCM clusters. Run this command when RTMT = 2, not when RTMT = 0 or 3.

• utils dbreplication stop -- You should only be running this if you want to end replication setup. The merely way to recover from a finish is with a reset. This command removes the set-up indicator file i.e. the dbmonpreflightcheck file and kills the currently running replication commands. It pauses for the duration of repltimeout timer, so if y'all run replication commands soon after running a stop, it could kill the commands again. Run this command when RTMT = 0, not when RTMT = 3

• utils dbreplication reset -- This command causes replication to be torn down and then set up-up. You should run this command when RTMT = 4 or when you lot have issued finish. Successful completion of this process results in RTMT = 2.

• utils dbreplication clusterreset -- Avoid running this control. It is for debugging replication set-up problems. It bypasses the RTMT settings, cluster requirements and normal CUCM gear up-up. It causes services to go out of sync with the database because it syncs information without alter notification. The services need to exist restarted when this control is run, no exceptions!

• utils dbreplication dropadmindb -- Run this command when at that place is a looping attempt to define a server in replication. Information technology's ordinarily not the server that'due south failing, it'south the pub which is corrupted equally a result of an attempt or the sub, prior to the current ane attempting set-up.

• utils dbreplication forcedatasyncsub -- This command takes a backup of the publisher and restores information technology to the subscriber(southward) and resets up replication. It requires a serivces restart on the subscriber so they go the new values.

New Commands and Database Improvements in CUCM ix.10:

• Re-engineered CLI forcedatasyncsuball (Lightening fast) -- This command can now restore a larger cluster in a shorter period of time!

• New CLI rebuild is a stop, drop and reset all in i (and faster) -- The architecture of Rebuild is multi-threaded, the total operation time is much shorter than executing 3 different CLI commands (stop / drop / reset). Rebuild, is a master command that will cease, delete and trigger the replication setup signal across the cluster automatically and in parallel:

1. Cease DB Replication – stop the current replication setup procedure if exists

1. Remove server from database – Remove replication from the network by either "cdr delete", dropping the syscdr database or renaming the syscdr database remotely

1. Trigger Dbmon on the subscriber to submit a replication setup request on to publisher.

• New CLI utils replication status table/replicate -- The "utils dbreplication status" command is lengthy when it runs. If simply ane table is suspect, then yous take to look for all the tables to cheque. Being able to check one table speeds up checking of replication.

• Better Log Collection -- "utils create report database" collects all the database logs in one get. Also, ercollect.sh script is embedded into the server for IBM root cause cases. The script is on the server now, no demand to transfer and modify permissions. It is accessible via root access only.

• Faster and more accurate Runtimestate CLI -- This control is now multithreaded, making information technology much faster. The output will as well be logged for historical RCA. If there are any unreachable servers in the cluster, this command will no longer hang. Some additional information will be included in information technology such as repltimeout and IDS server number.

- Abhinay Mylavarapu

masonmotosed.blogspot.com

Source: http://voipholic.blogspot.com/2014/03/troubleshooting-cucm-database.html

Share this post