Introduction
Este documento descreve como diagnosticar problemas de replicação de banco de dados e fornece as etapas necessárias para solucionar e resolver esses problemas.
Etapas para Diagnosticar a Replicação do Banco de Dados
Esta seção descreve cenários em que a replicação de banco de dados é interrompida e fornece a metodologia de solução de problemas que um engenheiro do TAC segue para diagnosticar e isolar o problema.
Etapa 1. Verificar se a replicação do banco de dados está corrompida
Para determinar se a replicação do banco de dados está corrompida, você deve saber os vários estados da Real Time Monitoring Tool (RTMT) para a replicação.
Valor |
Significado |
Descrição |
0 |
Estado de inicialização |
A replicação está em processo de configuração. Uma falha de configuração pode ter ocorrido se a replicação estiver nesse estado por mais de uma hora. |
1 |
O número de réplicas está incorreto |
A configuração ainda está em andamento. Esse estado raramente é visto nas versões 6.x e 7.x; na versão 5.x, indica que a configuração ainda está em andamento. |
2 |
A replicação é boa |
As conexões lógicas são estabelecidas e as tabelas são correspondentes com os outros servidores no cluster. |
3 |
Tabelas incompatíveis |
As conexões lógicas são estabelecidas, mas não há certeza se as tabelas correspondem. Nas versões 6.x e 7.x, todos os servidores podem mostrar o estado 3 mesmo que um servidor esteja inoperante no cluster. Esse problema pode ocorrer porque os outros servidores não têm certeza se há uma atualização do User Facing Feature (UFF) que não tenha sido passada do assinante para o outro dispositivo no cluster. |
4 |
Falha/queda da configuração |
O servidor não tem mais uma conexão lógica ativa para receber qualquer tabela de banco de dados pela rede. Não há replicação neste estado. |
Para verificar a replicação do banco de dados, execute o comando utils dbreplication runtimproperty na CLI do nó do editor, como mostrado nesta imagem.

Na saída, certifique-se de que o Estado de Replicação de Cluster não contenha as informações de sincronização antigas. Verifique o mesmo usando o carimbo de data/hora.
Se a sincronização de broadcast não for atualizada com uma data recente, execute o comando utils dbreplication status para verificar todas as tabelas e a replicação. Se algum erro/incompatibilidade for detectado, eles serão mostrados na saída e o estado RTMT será alterado de acordo, como mostrado nesta imagem.

Depois de executar o comando, todas as tabelas são verificadas quanto à consistência e um status de replicação preciso é exibido.
Note: Permita que todas as tabelas sejam verificadas e, em seguida, prossiga para a solução de problemas.

Quando um status de replicação preciso for exibido, verifique a Configuração da replicação (RTMT) e os detalhes como mostrado na primeira saída. Você deve verificar o status de cada nó. Se qualquer nó tiver um estado diferente de 2, continue a solucionar o problema.
Etapa 2. Colete o status do banco de dados CM na página Cisco Unified Reporting no CUCM
- Após concluir a Etapa 1, selecione a opção Cisco Unified Reporting na lista suspensa Navegação no editor do Cisco Unified Communications Manager (CUCM), como mostrado nesta imagem.

2. Navegue até Relatórios do sistema e clique em Status do banco de dados do Unified CM como mostrado nesta imagem.

3. Gere um novo relatório usando a opção Gerar novo relatório ou clique no ícone Gerar novo relatório como mostrado nesta imagem.

t
4. Depois de gerá-lo, faça o download e salve o relatório para que ele possa ser fornecido a um engenheiro do TAC caso uma solicitação de serviço (SR) precise ser aberta.
Etapa 3. Revisar o Relatório do Banco de Dados do Unified CM de qualquer componente sinalizado como um erro
Se houver algum erro nos componentes, os erros serão sinalizados com um ícone de cruz vermelha, como mostrado nesta imagem.

- Em caso de erro, verifique a conectividade de rede entre os nós. Verifique se o serviço A Cisco DB está sendo executado a partir da CLI do nó usando o comando utils service list.
- Se o serviço Um Cisco DB estiver inoperante, execute o comando utils service start A Cisco DB para iniciar o serviço. Se isso falhar, entre em contato com o TAC da Cisco.
- Verifique se a lista do servidor de replicação (servidor de lista cdr) está preenchida para todos os nós.
Esta imagem ilustra uma saída ideal.

Se a lista do Cisco Database Replicator (CDR) estiver vazia para alguns nós, consulte a Etapa 8.
- Certifique-se de que os hosts, hosts e Sqlhosts do Unified CM sejam equivalentes em todos os nós.
Este é um passo importante. Como mostrado nesta imagem, os Hosts do Unified CM, os Rhosts e os Sqlhosts são equivalentes em todos os nós.

Os arquivos Hosts são incompatíveis:
Há a possibilidade de uma atividade incorreta quando um endereço IP é alterado ou atualizado para o nome do host no servidor.
Consulte esse link para alterar o endereço IP para o nome de host do CUCM.
Alterações de endereço IP e nome de host
Reinicie os seguintes serviços da CLI do servidor do editor e verifique se a incompatibilidade foi eliminada. Se sim, vá para a Etapa 8. Em caso negativo, entre em contato com o TAC da Cisco. Gere um novo relatório toda vez que fizer uma alteração na GUI/CLI para verificar se as alterações estão incluídas.
Cluster Manager ( utils service restart Cluster Manager)
A Cisco DB ( utils service restart A Cisco DB)
Os arquivos Rhosts são incompatíveis:
Se os arquivos Rhosts forem incompatíveis com os arquivos do host, siga as etapas mencionadas em Os arquivos Hosts são incompatíveis. Se apenas os arquivos Rhosts forem incompatíveis, execute os comandos da CLI:
A Cisco DB ( utils service restart A Cisco DB )
Cluster Manager ( utils service restart Cluster Manager)
Gere um novo relatório e verifique se os arquivos do host são equivalentes em todos os servidores. Se sim, vá para a Etapa 8. Em caso negativo, entre em contato com o TAC da Cisco.
Os Sqlhosts são incompatíveis:
Se os Sqlhosts forem incompatíveis com os arquivos de host, siga as etapas mencionadas em Os arquivos de host não têm correspondência. Se apenas os arquivos Sqlhosts não corresponderem, execute o comando a partir da CLI:
utils service restart A Cisco DB
Gere um novo relatório e verifique se os arquivos Sqlhost são equivalentes em todos os servidores. Se sim, vá para a Etapa 8. Em caso negativo, entre em contato com o TAC da Cisco

Se o hello do RPC não funcionar para um nó específico:
- Assegure a conectividade de rede entre o nó específico e o editor.
- Certifique-se de que o número de porta 1515 seja permitido na rede.
Consulte este link para obter detalhes sobre o uso da porta TCP/UDP:
Uso de porta TCP e UDP do Cisco Unified Communications Manager
- Assegure-se de que a conectividade de rede seja bem-sucedida entre os nós, como mostrado nesta imagem:

Se a conectividade de rede falhar para os nós:
- Certifique-se de que o alcance da rede esteja presente entre os nós.
- Verifique se os números de porta TCP/UDP apropriados são permitidos na rede.
Gere um novo relatório e verifique se a conexão foi bem-sucedida. Em caso de conexão malsucedida, vá para a Etapa 8.
Etapa 4. Verifique os componentes individuais usando o comando utils diagnose test
O comando utils diagnose test verifica todos os componentes e retorna um valor passado/com falha. Os componentes essenciais para o funcionamento correto da replicação do banco de dados são:
O comando validation_network verifica todos os aspectos da conectividade da rede com todos os nós no cluster. Se houver um problema com a conectividade, um erro é frequentemente exibido no Domain Name Server/Reverse Domain Name Server (DNS/RDNS). O comando validation_network conclui a operação em 300 segundos. As mensagens de erro comuns conforme vistas nos testes de conectividade de rede:
1. Erro, a comunicação entre clusters está quebrada, como mostrado nesta imagem.

-Causa
Esse erro é causado quando um ou mais nós no cluster têm um problema de conectividade de rede. Certifique-se de que todos os nós tenham alcance de ping.
-Efeito
Se a comunicação entre clusters for interrompida, ocorrerão problemas de replicação de banco de dados.
2. Falha na pesquisa de DNS reverso.
-Causa
Esse erro é causado quando a pesquisa de DNS reversa falha em um nó. No entanto, você pode verificar se o DNS está configurado e funciona corretamente usando estes comandos:
utils network eth0 all - Shows the DNS configuration (if present)
utils network host <ip address/Hostname> - Checks for resolution of ip address/Hostname
-Efeito
Se o DNS não funcionar corretamente, poderá causar problemas de replicação do banco de dados quando os servidores forem definidos usando os nomes de host.
O NTP é responsável por manter o tempo do servidor sincronizado com o relógio de referência. O editor sempre sincroniza o horário com o dispositivo cujo IP está listado como servidores NTP; ao passo que os assinantes sincronizam o horário com o editor.
É extremamente importante que o NTP seja totalmente funcional para evitar qualquer problema de replicação de banco de dados.
É essencial que o estrato NTP (número de saltos para o relógio de referência pai) seja menor que 5 ou então o considerará não confiável.
Conclua estes passos para verificar o status do NTP:
- Use o comando utils diagnose test para verificar a saída, como mostrado nesta imagem.

2. Além disso, você pode executar o seguinte comando:
utils ntp status

Etapa 5. Verifique o status da conectividade de todos os nós e certifique-se de que eles sejam autenticados
- Após concluir a Etapa 4, se não houver problemas relatados, execute o comando utils network connection em todos os nós para verificar se a conectividade aos bancos de dados foi bem-sucedida, como mostrado nesta imagem.

2. Se você receber Cannot send TCP/UDP packets como uma mensagem de erro, verifique se há retransmissões na rede ou bloqueie as portas TCP/UDP. O comando show network cluster verifica a autenticação de todos os nós.
3. Se o status do nó não for autenticado, certifique-se de que a conectividade de rede e a senha de segurança sejam iguais em todos os nós, como mostrado nesta imagem.

Consulte os links para alterar/recuperar as senhas de segurança:
Como redefinir senhas no CUCM
Recuperação de senha do administrador do sistema operacional CUCM
Etapa 6. O comando utils dbreplication runtimproperty mostra status fora de sincronização ou não solicitado
É importante entender que a replicação do banco de dados é uma tarefa que exige muita rede, pois envia as tabelas reais para todos os nós no cluster. Assegure que:
-
Os nós estão espalhados pela rede de longa distância (WAN): Verifique se os nós têm conectividade de rede bem abaixo de 80 ms. Se alguns nós não puderem ingressar no processo de replicação, aumente o parâmetro para um valor mais alto, como mostrado.
utils dbreplication setprocess <1-40>
Note: A alteração desse parâmetro melhora o desempenho da configuração de replicação, mas consome recursos adicionais do 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/definir o tempo limite de replicação:
show tech repltimeout ( To check the current replication timeout value )
utils dbreplication setrepltimeout ( To set the replication timeout )
As etapas 7 e 8 devem ser executadas depois que a lista de verificação for preenchida:
Lista de verificação:
- Todos os nós têm a conectividade uns com os outros. Consulte a Etapa 5.
- RPC está acessível. Consulte a Etapa 3.
- Consulte o TAC da Cisco antes de prosseguir com as etapas 7 e 8 no caso de nós maiores que 8.
- Execute o procedimento fora do horário comercial.
Passo 7. Reparar todas/selecionar as tabelas para replicação do banco de dados
Se o comando utils dbreplication runtime mostrar que há tabelas de erro/não correspondidas, execute o comando:
Utils dbreplication repair all
Execute o comando utils dbreplication runtime para verificar o status novamente.
Vá para a Etapa 8 se o status não for alterado.
Etapa 8. Redefinir a replicação do banco de dados do zero
Consulte a sequência para redefinir a replicação do banco de dados e iniciar o processo do zero.
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 monitorar o processo, execute o comando RTMT/utils dbreplication runtime.
Consulte a sequência para redefinir a replicação do banco de dados para um nó específico:
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 )
Caso você acesse o Cisco TAC para obter assistência adicional, certifique-se de que os seguintes resultados e relatórios sejam fornecidos:
utils dbreplication runtimestate
utils diagnose test
utils network connectivity
Relatórios:
- O Relatório do Banco de Dados do Cisco Unified Reporting CM (consulte a Etapa 2)
- O comando utils create report database da CLI. Faça o download do arquivo .tar usando um servidor SFTP.

Para obter mais informações, consulte o link:
Solução de problemas do modelo de dispositivo Linux de replicação de banco de dados CUCM