Solucionar problemas de replicação do banco de dados do CUCM

Introduction

Este documento descreve como diagnosticar problemas de replicação de banco de dados e fornece as etapas necessárias para solucionar esses problemas.

Etapas para diagnosticar a replicação de banco de dados

Esta seção descreve cenários nos quais a replicação do 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 de banco de dados foi interrompida

Para determinar se a replicação de banco de dados foi interrompida, você deve conhecer os vários estados do Real Time Monitoring Tool (RTMT) para a replicação.

Para verificar a replicação de banco de dados, execute o comando utils dbreplication runtimestate na CLI do nó Publisher, conforme mostrado nesta imagem. 

Na saída, verifique se o estado de replicação do cluster não contém as informações de sincronização antigas. Marque a mesma opção e use o Carimbo de data/hora.

Se a sincronização de transmissão não estiver atualizada com uma data recente, execute o comando utils dbreplication status para verificar todas as tabelas e a replicação. Se erros/incompatibilidades forem encontrados, serão mostrados na saída e o estado do RTMT será alterado de acordo, conforme mostrado nesta imagem.

Depois de executar o comando, todas as tabelas serão verificadas quanto à consistência e um status de replicação preciso será exibido.

Observação: permita que todas as tabelas sejam verificadas e continue com a solução de problemas.

Quando um status de replicação preciso for exibido, verifique a configuração de replicação (RTMT) e os detalhes, conforme 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 problemas.

Etapa 2. Coletar o status do banco de dados do CM na página Cisco Unified Reporting no CUCM

1. Após concluir a Etapa 1, escolha a opção Cisco Unified Reporting na lista suspensa Navegação no editor do Cisco Unified Communications Manager (CUCM), conforme 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 que use a opção Gerar Novo Relatório ou clique no ícone Gerar Novo Relatório, conforme mostrado nesta imagem.

4. Depois de gerar e fazer o download, salve o relatório para que possa ser fornecido a um engenheiro do TAC caso uma solicitação de serviço (SR) precise ser aberta.

Etapa 3. Analisar o relatório do banco de dados do Unified CM quanto a componentes sinalizados como erro

Se houver erros nos componentes, eles serão sinalizados com um ícone X vermelho, como mostrado nesta imagem.

• Verifique se os bancos de dados Local e do Publicador estão acessíveis.

• Em caso de erro, verifique a conectividade de rede entre os nós. Verifique se o serviço A Cisco DB é executado a partir da CLI do nó e usa o comando utils service list.

• Se o serviço A Cisco DB estiver inativo, 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 de servidores de replicação (cdr list serv) foi 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.

• Verifique se os Hosts, Rhosts e Sqlhosts do Unified CM são equivalentes em todos os nós.

Essa é uma etapa importante. Conforme mostrado nesta imagem, os Hosts, Rhosts e Sqlhosts do Unified CM são equivalentes em todos os nós.

Os arquivos de Hosts apresentam incompatibilidade:

Existe a possibilidade de uma atividade incorreta quando um endereço IP é alterado ou atualizado para o nome de host no servidor.

Consulte este 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 esses serviços a partir do CLI do servidor do editor e verifique se a incompatibilidade foi eliminada. Nesse caso, vá para a Etapa 8. Em caso negativo, entre em contato com o TAC da Cisco. Gere um novo relatório toda vez que você 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 de Rhosts apresentam incompatibilidade:

Se os arquivos de Rhosts apresentarem incompatibilidade com os arquivos de Hosts, siga as etapas mencionadas em Os arquivos de Hosts apresentam incompatibilidade. Se apenas os arquivos de Rhosts apresentarem incompatibilidade, execute os comandos na 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 de Rhost são equivalentes em todos os servidores. Nesse caso, vá para a Etapa 8. Em caso negativo, entre em contato com o TAC da Cisco.

Os arquivos de Sqlhosts apresentam incompatibilidade:

Se os arquivos de Sqlhosts apresentarem incompatibilidade com os arquivos de Hosts, siga as etapas mencionadas em Os arquivos de Hosts apresentam incompatibilidade. Se apenas os arquivos de Sqlhosts apresentarem incompatibilidade, execute o comando na CLI:

utils service restart A Cisco DB

Gere um novo relatório e verifique se os arquivos de Sqlhosts são equivalentes em todos os servidores. Nesse caso, vá para a Etapa 8. Em caso negativo, entre em contato com o TAC da Cisco

• Verifique se o hello do Database Layer Remote Procedural Call (DBL RPC) foi executado com sucesso, conforme mostrado nesta imagem.

  Se o hello do RPC não funcionar em um nó específico:

• Verifique a conectividade de rede entre o nó específico e o editor.
• Verifique se o número da porta 1515 é permitido na rede.

Consulte este link para obter detalhes sobre o uso da porta TCP/UDP:

Uso das portas TCP e UDP do Cisco Unified Communications Manager

• Verifique se a conectividade de rede foi estabelecida com sucesso entre os nós, conforme mostrado nesta imagem:

Se a conectividade de rede falhar para os nós:

• Verifique se a acessibilidade da rede está presente entre os nós.
• Verifique se os devidos números da porta TCP/UDP são permitidos na rede.

Gere um novo relatório e verifique se uma conexão foi estabelecida com sucesso. Se uma conexão não foi estabelecida com sucesso, vá para a Etapa 8.

Etapa 4. Verifique os componentes individuais que usam o comando utils diagnose test

O comando utils diagnose test verifica todos os componentes e retorna um valor aprovado/reprovado. Os componentes essenciais para o funcionamento adequado da replicação de banco de dados são:

• Conectividade de rede:

O comando validate_network verifica todos os aspectos da conectividade de rede com todos os nós no cluster. Se houver um problema com a conectividade, um erro será exibido com frequência nos servidores DNS/RDNS. O comando validate_network conclui a operação em 300 segundos. As mensagens de erro comuns observadas nos testes de conectividade de rede:

1. Erro. A comunicação dentro do cluster está interrompida, como mostrado nesta imagem.

• Causa

Esse erro é causado quando um ou mais nós no cluster têm um problema de conectividade de rede. Verifique se todos os nós têm acessibilidade de ping.

• Efeito

Se a comunicação intra-cluster foi interrompida, ocorrerão problemas de replicação de banco de dados.

2. Falha na pesquisa de DNS reverso.

• Causa

Esse erro é causado quando há uma falha na pesquisa de RDNS em um nó. No entanto, você pode verificar se o DNS está configurado e funciona corretamente ao usar 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, ele poderá causar problemas de replicação de banco de dados quando os servidores forem definidos e usarem os nomes de host.

• Acessibilidade do Network Time Protocol (NTP):

O NTP é responsável por manter o horário do servidor em sincronia com o relógio de referência. O editor sempre sincroniza a hora com o dispositivo cujo IP está listado como servidores NTP; por outro lado, os assinantes sincronizam a hora com o editor.

É extremamente importante que o NTP esteja totalmente funcional para evitar problemas de replicação de banco de dados.

É essencial que o stratum do NTP (Número de saltos para o relógio de referência pai) seja menor que 5, caso contrário, ele não será considerado confiável.

Conclua estas etapas para verificar o status do NTP:

1. Use o comando utils diagnose test para verificar a saída, conforme mostrado nesta imagem.

  2.  Além disso, você pode executar este comando:

utils ntp status

Etapa 5. Verificar o status de conectividade em todos os nós e garantir que sejam autenticados

1. Depois de concluir a Etapa 4, se não houver relatório de problemas, execute o comando utils network connectivity em todos os nós, para verificar se a conectividade com os bancos de dados foi estabelecida com sucesso, conforme mostrado nesta imagem.

2. Se você receber a mensagem de erro Não é possível enviar pacotes TCP/UDP, 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 do CUCM

Etapa 6. O comando utils dbreplication runtimestate mostra os status fora de sincronização ou não solicitado

É importante entender que a replicação de banco de dados é uma tarefa com uso intensivo de rede, pois envia as tabelas reais para todos os nós no cluster. Assegure que:

•  Os nós estão no mesmo data center/local: todos os nós estão acessíveis com um tempo de ida e volta (RTT) menor. Se o RTT estiver excepcionalmente alto, verifique o desempenho da rede.

•  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 valor do parâmetro, conforme mostrado.

utils dbreplication setprocess <1-40>

Observação: Quando você altera esse parâmetro, ele melhora o desempenho da configuração de replicação, mas consome recursos adicionais do sistema.

• O tempo limite de replicação é baseado no número de nós no cluster: O tempo limite de replicação (Padrão: 300 Segundos) é o tempo que o publicador espera por todos os assinantes para enviar suas mensagens definidas. Calcule o limite de tempo da replicação de acordo com o número de nós no 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.

Comandos para verificar/definir o limite de tempo 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 após o preenchimento da lista de verificação:

Lista de verificação:

• Todos os nós têm conectividade entre si. Consulte a Etapa 5.

• O RPC está acessível. Consulte a Etapa 3.

• Consulte o Cisco TAC antes de prosseguir com as etapas 7 e 8 no caso de nós maiores que 8.

• Realize o procedimento fora do horário comercial.

Passo 7. Reparar todas/tabelas seletivas para replicação de banco de dados

Se o comando utils dbreplication runtimestate mostrar que há tabelas com erro/incompatibilidade, execute o comando:

Utils dbreplication repair all

Execute o comando utils dbreplication runtimestate para verificar o status novamente.

Passe 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 runtimestate.

Consulte a sequência para redefinir a replicação de 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ê entre em contato com o TAC da Cisco para obter assistência adicional, certifique-se de que estas saídas e os relatórios sejam fornecidos:

utils dbreplication runtimestate
utils diagnose test
utils network connectivity

Relatórios:

• O relatório do banco de dados do CM do Cisco Unified Reporting (consulte a Etapa 2)

• O comando utils create report database na CLI.  Baixe o arquivo .tar e use um servidor SFTP.

Para obter mais informações, consulte os links:

Entendendo a saída do estado de execução de replicação de utils para CUCM

Solução de problemas do modelo da aplicação do Linux para replicação de banco de dados do CUCM