Pasos para resolver problemas la réplica de base de datos

Introducción

Este documento describe cómo diagnosticar los problemas de la réplica de base de datos y proporciona los pasos necesarios resolver problemas y resolver esos problemas.

Pasos para diagnosticar la réplica de base de datos

Esta sección describe los escenarios en los cuales la réplica de base de datos está quebrada, y proporciona la metodología del Troubleshooting que un ingeniero de TAC sigue para diagnosticar y aislar el problema.

Paso 1. Verifique la réplica de base de datos está quebrado

Para determinar si su réplica de base de datos está quebrada, usted debe conocer los diversos estados de la herramienta del monitoreo en tiempo real (RTMT) para la replicación.

Para verificar la réplica de base de datos, funcione con el comando del runtimestate del dbreplication del utils del theCLI del nodo del editor, tal y como se muestra en de esta imagen. 

En la salida, asegúrese de que el estado de la replicación del cluster no contenga la vieja información de sincronización. Marque lo mismo usando el grupo fecha/hora.

Si el broadcast sincroniza no se pone al día con una fecha reciente, funciona con el comando status del dbreplication del utils de marcar todas las tablas y la replicación. Si se descubren algunos errores/discordancías, se muestran en la salida y RTMT los cambios de estado por consiguiente, tal y como se muestra en de esta imagen.

Después de que usted funcione con el comando, todas las tablas se marcan para saber si hay estado coherente y se visualiza un estatus exacto de la replicación.

Nota: Permita que todas las tablas sean marcadas y después progrese resolver problemas.

Una vez que se visualiza un estatus exacto de la replicación, marque la replicación puesta (RTMT) y los detalles tal y como se muestra en de la primera salida. Usted debe marcar el estatus para cada nodo. Si cualquier nodo tiene un estado con excepción de 2, continúe resolviendo problemas.

Paso 2. Recoja el estatus de la base de datos CM de la página unificada Cisco de la información en el CUCM

1. Después de que usted complete el paso 1, seleccione Cisco unificado señalando la opción de la lista desplegable de la navegación en el editor del administrador de las Comunicaciones unificadas de Cisco (CUCM), tal y como se muestra en de esta imagen.

2. Navegue a los informes del sistema y haga clic el estatus unificado de la base de datos CM tal y como se muestra en de esta imagen.

3. Genere un nuevo informe usando la nueva opción del informe de la generación o haga clic el nuevo icono del informe de la generación tal y como se muestra en de esta imagen.

 t

4. Una vez que se genera, descargue y salve el informe para poder proporcionar a un ingeniero de TAC en caso de que una solicitud de servicio (SENIOR) necesite ser abierta.

Paso 3. Revise el informe unificado de la base de datos CM cualquier componente señalado por medio de una bandera como error

Si hay algunos errores en los componentes, los errores serán señalados por medio de una bandera con un icono de la Cruz Roja, tal y como se muestra en de esta imagen.

• Asegúrese que el Local y las Bases de datos del editor sean accesibles.

• En caso de un error, marque para saber si hay la conectividad de red entre los Nodos. Verifique si un servicio de Cisco DB se está ejecutando del CLI del nodo usando el comando list del servicio del utils.

• Si un servicio de Cisco DB está abajo, ejecute el comienzo del servicio del utils un comando de Cisco DB de comenzar el servicio. Si esto falla, entre en contacto el TAC de Cisco.     

• Asegúrese que la lista pueblen del Servidor de replicación (servicio de la lista de los cdr) para todos los Nodos.

 Esta imagen ilustra un ouput ideal.

 Si la lista de Replicator de la base de datos de Cisco (CDR) está vacía para algunos Nodos, refiera al paso 8.

• Asegúrese de que los host unificados, Rhosts y Sqlhosts CM sean equivalentes en todos los Nodos.

Esto es un paso importante. Tal y como se muestra en de esta imagen, los host unificados CM, el Rhosts y el Sqlhosts son equivalentes en todos los Nodos.

Se unen mal los archivos de los host:

Hay una posibilidad de una actividad incorrecta cuando una dirección IP cambia o las actualizaciones al nombre de host en el servidor.

Refiera a este link para cambiar la dirección IP al nombre de host para el CUCM.

Cambios de la dirección IP y del nombre de host

  Recomience los servicios siguientes del CLI del servidor editor y marque si se borra la discordancía. Si sí, vaya al paso 8. Si ningún, entre en contacto el TAC de Cisco. Genere un nuevo informe cada vez que usted realiza un cambio en el GUI/CLI para marcar si los cambios son incluidos.

Cluster Manager ( utils service restart Cluster Manager) 
A Cisco DB ( utils service restart A Cisco DB)

Se unen mal los archivos de Rhosts:

Si los archivos de Rhosts se unen mal junto con los archivos de host, siga los pasos mencionados bajo host que se unen mal los archivos. Si solamente se unen mal los archivos de Rhosts, funcione con los comandos del CLI:

A Cisco DB ( utils service restart A Cisco DB )Cluster Manager ( utils service restart Cluster Manager)

Genere un nuevos informe y control si los archivos de Rhost son equivalentes en todos los servidores. Si sí, vaya al paso 8. Si ningún, entre en contacto el TAC de Cisco.

Se une mal el Sqlhosts:

Si el Sqlhosts se une mal junto con los archivos de host, siga los pasos mencionados bajo host que se unen mal los archivos. Si solamente se unen mal los archivos de Sqlhosts, funcione con el comando del CLI:

utils system restart A Cisco DB

Genere un nuevos informe y control si los archivos de Sqlhost son equivalentes en todos los servidores. Si sí, vaya al paso 8. Si ningún, entre en contacto el TAC de Cisco

• Asegúrese de que la llamada procesal remota de la capa de la base de datos (DBL RPC) hola sea acertada, tal y como se muestra en de esta imagen.

  Si el RPC hola no trabaja para un nodo determinado:

- Asegure la conectividad de red entre el nodo determinado y el editor.

- Asegúrese de que el número del puerto 1515 esté permitido en la red.

Refiera a este link para los detalles en el uso del puerto TCP/UDP:

Administrador TCP de las Comunicaciones unificadas de Cisco y uso del puerto UDP

• Asegúrese de que la conectividad de red sea acertada entre los Nodos, tal y como se muestra en de 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 del puerto apropiados TCP/UDP estén permitidos en la red.

Genere un nuevo informe, y la comprobación para una conexión satisfactoria. En caso de una conexión fracasada, vaya al paso 8.

Paso 4. Marque a los componentes individuales que usan el utils diagnostican el comando test

El utils diagnostica el comando test marca todos los componentes y vuelve pasajero/falló el valor. Los componentes que son esenciales para el funcionamiento apropiado de la réplica de base de datos son:

• Conectividad de red:

El comando del validate_network marca todos los aspectos de la conectividad de red con todos los Nodos en el cluster. Si hay un problema con la Conectividad, un error se visualiza a menudo en el Domain Name Server/el Domain Name Server del revés (DNS/RDNS). El comando del validate_network completa la operación en 300 segundos. Los mensajes de error frecuente como se ve en las pruebas de la conectividad de red:

1. El error, comunicación dentro del clúster está quebrado, tal y como se muestra en de esta imagen.

- Causa

Se causa este error cuando uno o más Nodos en el cluster tienen un problema de conectividad de red. Asegúrese de que todos los Nodos tengan accesibilidad del ping.

- Efecto

Si comunicación dentro del clúster está quebrado, los problemas de la réplica de base de datos ocurren.

2. Búsqueda de DNS reversible fallada.

- Causa

Se causa este error cuando la búsqueda de DNS reversible falla en un nodo. Sin embargo, usted puede verificar si el DNS esté configurado y funcione 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 no lo hace el DNS las funciones correctamente, puede causar los problemas de la réplica de base de datos cuando los servidores se definen usando los nombres de host.

• Accesibilidad del Network Time Protocol (NTP):

El NTP es responsable de guardar el tiempo del servidor en sincronización con el reloj de referencia. El editor sincroniza siempre el tiempo con el dispositivo cuyo IP se enumera como servidores NTP; considerando que, los suscriptores sincronizan el tiempo con el editor.

Es extremadamente importante que el NTP sea completamente - funcional para evitar cualquier problema de la réplica de base de datos.

Es que el estrato NTP (número de saltos al reloj de referencia del padre) debe ser menos de 5 esenciales o bien lo juzgará no fiable.

Complete estos pasos para marcar el estado NTP:

1. Utilice el utils diagnostican el comando test de marcar la salida, tal y como se muestra en de esta imagen.

  2.  Además, usted puede funcionar con el siguiente comando:

utils ntp status

Paso 5. Marque el estatus de la Conectividad de todos los Nodos y asegúrese que están autenticados

1. Después de que usted complete el paso 4, si no hay problemas señalados, funcione con el comando de la conectividad de red del utils en todos los Nodos de marcar la Conectividad a las bases de datos es acertado, tal y como se muestra en de esta imagen.

2. Si usted recibe no puede enviar los paquetes TCP/UDP como mensaje de error, marca su red para cualesquiera retransmisiones o bloquea los puertos TCP/UDP. El comando cluster de la red de la demostración marca para saber si hay autenticación de todos los Nodos.

3. Si el statusof el nodo es unauthenticated, asegúrese de que la conectividad de red y la contraseña de seguridad sea lo mismo en todos los Nodos, tal y como se muestra en de esta imagen.

Refiera a los links para cambiar/recupere las contraseñas de seguridad:

Cómo reajustar las contraseñas en CUCM

Recuperación de la contraseña del administrador del sistema operativo CUCM

Paso 6. Las demostraciones del comando del runtimestate del dbreplication del utils fuera de sincronizan o los estatuses no pedidos

Es importante entender que la réplica de base de datos es una tarea intensiva de la red pues avanza las tablas reales a todos los Nodos en el cluster. Asegúrese de lo siguiente:

•  Los Nodos están en el mismo centro de datos/sitio: Todos los Nodos son accesibles con un Round Trip Time más bajo (RTT). Si el RTT es unusally alto, marque el rendimiento de la red.

•  Los Nodos se dispersan sobre el Red de área ancha (WAN): Asegúrese de que los Nodos tengan red connecitivty bien bajo el ms 80. Si algunos Nodos no pueden unirse al proceso de replicación, aumente el parámetro a un valor más alto como se muestra.

utils dbreplication setprocess <1-40>

Nota: El cambio de este parámetro mejora el funcionamiento de la configuración de la replicación, pero consume a los recursos del sistema adicionales.

• El descanso de la replicación se basa en el número de Nodos en el cluster: El descanso de la replicación (valor por defecto: 300 segundos) son el tiempo que el editor espera a todos los suscriptores para enviar sus mensajes definidos. Calcule el descanso de la replicación basado en el número de Nodos en el cluster.

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.

Marcar/conjunto de los comandos el descanso de la 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 ser realizados después de que se satisfaga la lista de verificación:

Lista de verificación:

• Todos los Nodos tienen la Conectividad el uno al otro. Refiera al paso 5.

• El RPC es accesible. Refiera al paso 3.

• Consulte el TAC de Cisco antes de proceder con el paso 7 y 8 en caso de los Nodos mayores de 8.

• Realice el procedimiento en apagado las horas hábiles.

Paso 7. Repare todos/selectivo las tablas para la réplica de base de datos

Si el comando del runtimestate del dbreplication del utils muestra que hay error/tablas unidas mal, funcione con el comando:

Utils dbreplication repair all

Funcione con el comando del runtimestate del dbreplication del utils de marcar el estatus otra vez.

Proceda al paso 8, si el estatus no cambia.

Paso 8. Reajuste la réplica de base de datos del rasguño

Refiera a la secuencia para reajustar la réplica de base de datos y para comenzar el proceso del rasguño.

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, funcione con el comando del runtimestate del dbreplication RTMT/utils.

Refiera a la secuencia para reajustar la réplica de 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 usted alcance el TAC de Cisco para la asistencia adicional, asegúrese de que los productos siguientes y los informes estén proporcionados:

utils dbreplication runtimestateutils diagnose testutils network connectivity

Informes:

• Cisco unificado señalando el informe de la base de datos CM (refiera al paso 2)

• El utils crea el comando database del informe del CLI.  Descargue el archivo de .tar usando un servidor SFTP.

Para más información refiera al link:

Resolver problemas el modelo del dispositivo de Linux de la réplica de base de datos CUCM