Introducción
Este documento describe cómo diagnosticar problemas de replicación de bases de datos y proporciona los pasos necesarios para resolver esos problemas.
Pasos para Diagnosticar la Replicación de la Base de Datos
Esta sección describe los escenarios en los que se rompe la replicación de la base de datos y proporciona la metodología de solución de problemas que sigue un ingeniero del TAC para diagnosticar y aislar el problema.
Paso 1. Verificar que la replicación de la base de datos esté dañada
Para determinar si la replicación de la base de datos está dañada, debe conocer los diversos estados de la Herramienta de supervisión en tiempo real (RTMT) para la replicación.
Valor |
Significado |
Descripción |
0 |
Estado de inicialización |
La replicación está en proceso de configuración. Puede que se haya producido un error de configuración si la replicación se encuentra en este estado durante más de una hora. |
1 |
El número de réplicas es incorrecto |
La configuración sigue en curso. Este estado raramente se ve en las versiones 6.x y 7.x; en la versión 5.x, indica que la configuración todavía está en curso. |
2 |
La replicación es buena |
Se establecen conexiones lógicas y las tablas se corresponden con los otros servidores del clúster. |
3 |
Tablas no coincidentes |
Se establecen conexiones lógicas, pero no está seguro de si las tablas coinciden. En las versiones 6.x y 7.x, todos los servidores podrían mostrar el estado 3 incluso si un servidor está inactivo en el clúster. Este problema puede ocurrir porque los otros servidores no están seguros de si hay una actualización de la función de usuario (UFF) que no se ha pasado del suscriptor al otro dispositivo del clúster. |
4 |
Error/Descarte de la configuración |
El servidor ya no tiene una conexión lógica activa para recibir cualquier tabla de base de datos a través de la red. No se produce replicación en este estado. |
Para verificar la replicación de la base de datos, ejecute el comando utils dbreplicación runtimstate desde la CLI del nodo del editor, como se muestra en esta imagen.

En el resultado, asegúrese de que el estado de replicación del clúster no contenga la información de sincronización anterior. Marque la misma opción mediante la marca de tiempo.
Si la sincronización de broadcast no se actualiza con una fecha reciente, ejecute el comando utils dbreplicación status para verificar todas las tablas y la replicación. Si se descubren errores/discordancias, se muestran en el resultado y el estado RTMT cambia en consecuencia, como se muestra en esta imagen.

Después de ejecutar el comando, todas las tablas se comprueban por coherencia y se muestra un estado de replicación preciso.
Nota: Permitir que se verifiquen todas las tablas y, a continuación, continuar con la solución de problemas.

Una vez que se muestra un estado de replicación preciso, verifique la Configuración de replicación (RTMT) y los detalles como se muestra en el primer resultado. Debe comprobar el estado de cada nodo. Si algún nodo tiene un estado distinto de 2, continúe con la resolución de problemas.
Paso 2. Recopile el estado de la base de datos de CM de la página de Cisco Unified Reporting en CUCM
- Después de completar el paso 1, seleccione la opción Cisco Unified Reporting en la lista desplegable Navegación del editor de Cisco Unified Communications Manager (CUCM), como se muestra en esta imagen.

2. Desplácese hasta Informes del sistema y haga clic en Estado de la base de datos de Unified CM, como se muestra en esta imagen.

3. Genere un nuevo informe mediante la opción Generar nuevo informe o haga clic en el icono Generar nuevo informe, como se muestra en esta imagen.

t
4. Una vez generado, descargue y guarde el informe para que se pueda proporcionar a un ingeniero del TAC en caso de que deba abrirse una solicitud de servicio (SR).
Paso 3. Revisar el informe de la base de datos de Unified CM de cualquier componente marcado como error
Si hay algún error en los componentes, los errores se marcarán con un icono de cruz roja, como se muestra en esta imagen.

- En caso de error, verifique la conectividad de red entre los nodos. Verifique si el servicio A Cisco DB se está ejecutando desde la CLI del nodo mediante el comando utils service list.
- Si el servicio A DB de Cisco está inactivo, ejecute el comando utils service start A Cisco DB para iniciar el servicio. Si esto falla, póngase en contacto con el TAC de Cisco.
- Asegúrese de que Replication Server List (cdr list serv) se rellene para todos los nodos.
Esta imagen ilustra una salida ideal.

Si la lista de Cisco Database Replicator (CDR) está vacía para algunos nodos, consulte el Paso 8.
- Asegúrese de que los Hosts, Rhosts y Sqlhosts de Unified CM sean equivalentes en todos los nodos.
Este es un paso importante. Como se muestra en esta imagen, los Hosts de Unified CM, los Rhosts y los Sqlhosts son equivalentes en todos los nodos.

Los archivos Hosts no coinciden:
Existe la posibilidad de una actividad incorrecta cuando una dirección IP cambia o se actualiza al nombre de host en el servidor.
Consulte este enlace para cambiar la dirección IP al nombre de host de CUCM.
Cambios en la dirección IP y el nombre de host
Reinicie los siguientes servicios desde la CLI del servidor del editor y verifique si se borra la discordancia. En caso afirmativo, vaya al paso 8. Si la respuesta es negativa, póngase en contacto con el TAC de Cisco. Genere un nuevo informe cada vez que realice un cambio en la GUI/CLI para comprobar si se incluyen los cambios.
Cluster Manager ( utils service restart Cluster Manager)
A Cisco DB ( utils service restart A Cisco DB)
Los archivos Rhosts no coinciden:
Si los archivos Rhosts no coinciden con los archivos host, siga los pasos mencionados en Los archivos Hosts no coinciden. Si sólo los archivos Rhosts no coinciden, ejecute los comandos desde la CLI:
A Cisco DB ( utils service restart A Cisco DB )
Cluster Manager ( utils service restart Cluster Manager)
Genere un nuevo informe y verifique si los archivos Rhost son equivalentes en todos los servidores. En caso afirmativo, vaya al paso 8. Si la respuesta es negativa, póngase en contacto con el TAC de Cisco.
Los Sqlhosts no coinciden:
Si los Sqlhosts no coinciden con los archivos host, siga los pasos mencionados en Los archivos de Hosts no coinciden. Si sólo los archivos Sqlhosts no coinciden, ejecute el comando desde la CLI:
utils service restart A Cisco DB
Genere un nuevo informe y verifique si los archivos Sqlhost son equivalentes en todos los servidores. En caso afirmativo, vaya al paso 8. Si la respuesta es negativa, póngase en contacto con el TAC de Cisco

Si el hello RPC no funciona para un nodo determinado:
- Asegúrese de la conectividad de red entre el nodo en particular y el editor.
- Asegúrese de que el número de puerto 1515 esté permitido en la red.
Consulte este enlace para obtener detalles sobre el uso del puerto TCP/UDP:
Uso de puertos TCP y UDP de Cisco Unified Communications Manager
- Asegúrese de que la conectividad de red entre los nodos sea correcta, como se muestra en esta imagen:

Si la conectividad de red falla para los nodos:
- Asegúrese de que el alcance de la red esté presente entre los nodos.
- Asegúrese de que los números de puerto TCP/UDP adecuados estén permitidos en la red.
Genere un nuevo informe y compruebe si la conexión se ha realizado correctamente. En caso de que la conexión no se realice correctamente, vaya al paso 8.
Paso 4. Verifique los componentes individuales mediante el comando utils diagnose test
El comando utils diagnose test verifica todos los componentes y devuelve un valor pasado/fallido. Los componentes esenciales para el correcto funcionamiento de la replicación de la base de datos son:
El comando Validation_network verifica todos los aspectos de la conectividad de red con todos los nodos en el clúster. Si hay un problema con la conectividad, a menudo se muestra un error en el servidor de nombres de dominio/servidor de nombres de dominio inverso (DNS/RDNS). El comando Validation_network completa la operación en 300 segundos. Los mensajes de error comunes tal como se ven en las pruebas de conectividad de red:
1. Error, la comunicación dentro del clúster está dañada, como se muestra en esta imagen.

-Causa
Este error se produce cuando uno o más nodos del clúster tienen un problema de conectividad de red. Asegúrese de que todos los nodos tengan disponibilidad de ping.
-Efecto
Si se rompe la comunicación dentro del clúster, se producen problemas de replicación de la base de datos.
2. Error en la búsqueda de DNS inverso.
-Causa
Este error se produce cuando la búsqueda de DNS inversa falla en un nodo. Sin embargo, puede verificar si el DNS está configurado y funciona correctamente usando estos comandos:
utils network eth0 all - Shows the DNS configuration (if present)
utils network host <ip address/Hostname> - Checks for resolution of ip address/Hostname
-Efecto
Si el DNS no funciona correctamente, puede causar problemas de replicación de la base de datos cuando los servidores se definen usando los nombres de host.
El NTP es responsable de mantener el tiempo del servidor sincronizado con el reloj de referencia. El editor siempre sincroniza la hora con el dispositivo cuya IP aparece como servidores NTP; mientras que los suscriptores sincronizan la hora con el editor.
Es extremadamente importante que el NTP funcione completamente para evitar cualquier problema de replicación de bases de datos.
Es esencial que el estrato NTP (número de saltos al reloj de referencia principal) sea inferior a 5 o que lo considere poco fiable.
Complete estos pasos para verificar el estado de NTP:
- Utilice el comando utils diagnose test para verificar el resultado, como se muestra en esta imagen.

2. Además, puede ejecutar el siguiente comando:
utils ntp status

Paso 5. Verifique el estado de conectividad de todos los nodos y asegúrese de que estén autenticados
- Después de completar el Paso 4, si no se informa de ningún problema, ejecute el comando utils network Connectivity en todos los nodos para verificar que la conectividad a las bases de datos es exitosa, como se muestra en esta imagen.

2. Si recibe No se pueden enviar paquetes TCP/UDP como mensaje de error, verifique la red para ver si hay retransmisiones o bloquee los puertos TCP/UDP. El comando show network cluster verifica la autenticación de todos los nodos.
3. Si el estado del nodo no está autenticado, asegúrese de que la conectividad de red y la contraseña de seguridad sean iguales en todos los nodos, como se muestra en esta imagen.

Consulte los enlaces para cambiar/recuperar las contraseñas de seguridad:
Cómo restablecer contraseñas en CUCM
Recuperación de contraseña del administrador del sistema operativo CUCM
Paso 6. El comando utils dbreplicación runtimstate muestra estados fuera de sincronización o no solicitados
Es importante comprender que la replicación de la base de datos es una tarea que requiere una gran cantidad de red, ya que envía las tablas reales a todos los nodos del clúster. Asegúrese de lo siguiente:
utils dbreplication setprocess <1-40>
Nota: Al cambiar este parámetro, se mejora el rendimiento de la configuración de replicación, pero se consumen recursos adicionales del sistema.
Server 1-5 = 1 Minute Per Server Servers 6-10 = 2 Minutes Per Server Servers >10 = 3 Minutes Per Server.
Example: 12 Servers in Cluster : Server 1-5 * 1 min = 5 min, + 6-10 * 2 min = 10 min, + 11-12 * 3 min = 6 min,
Repltimeout should be set to 21 Minutes.
Comandos para verificar/establecer el tiempo de espera de replicación:
show tech repltimeout ( To check the current replication timeout value )
utils dbreplication setrepltimeout ( To set the replication timeout )
Los pasos 7 y 8 deben realizarse después de que se complete la lista de comprobación:
Lista de Verificación:
- Todos los nodos tienen conectividad entre sí. Consulte el Paso 5.
- RPC es accesible. Consulte el Paso 3.
- Consulte el TAC de Cisco antes de continuar con los pasos 7 y 8 en el caso de los nodos superiores a 8.
- Realice el procedimiento en el horario laboral fuera de horario.
Paso 7. Reparar todas las tablas/selectivas para la replicación de bases de datos
Si el comando utils dbreplicación runtimstate muestra que hay tablas con error/discordancia, ejecute el comando:
Utils dbreplication repair all
Ejecute el comando utils dbreplicación runtimstate para verificar el estado de nuevo.
Vaya al paso 8, si el estado no cambia.
Paso 8. Restablecer la replicación de la base de datos desde el principio
Consulte la secuencia para restablecer la replicación de la base de datos e iniciar el proceso desde el principio.
utils dbreplication stop all (Only on the publisher)
utils dbreplication dropadmindb (First on all the subscribers one by one then the publisher)
utils dbreplication reset all ( Only on the publisher )
Para monitorear el proceso, ejecute el comando RTMT/utils dbreplicación runtimstate.
Consulte la secuencia para restablecer la replicación de la base de datos para un nodo determinado:
utils dbreplication stop <sub name/IP> (Only on the publisher)
utils dbreplcation dropadmindb (Only on the affected subscriber)
utils dbreplication reset <sub name/IP> (Only on the publisher )
En caso de que se ponga en contacto con el TAC de Cisco para obtener más ayuda, asegúrese de que se proporcionan los siguientes resultados y los informes:
utils dbreplication runtimestate
utils diagnose test
utils network connectivity
Informes:
- Informe de base de datos de Cisco Unified Reporting CM (consulte el paso 2)
- El comando utils create report database desde CLI. Descargue el archivo .tar mediante un servidor SFTP.

Para obtener más información, consulte el enlace:
Solución de problemas del modelo de dispositivo Linux de replicación de bases de datos CUCM