Etapas para pesquisar defeitos a replicação de base de dados

Introdução

Este documento descreve como diagnosticar edições da replicação de base de dados e fornece as etapas necessárias pesquisar defeitos e resolver aquelas edições.

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

Esta seção descreve as encenações em que a replicação de base de dados é quebrada, e fornece a metodologia da pesquisa de defeitos que um coordenador TAC segue a fim diagnosticar e isolar o problema.

Etapa 1. Verifique que a replicação de base de dados é quebrada

A fim determinar se sua replicação de base de dados é quebrada, você deve conhecer os vários estados da ferramenta do monitoramento em tempo real (RTMT) para a replicação.

Para verificar a replicação de base de dados, execute o comando do runtimestate do dbreplication dos utils do theCLI do nó do editor, segundo as indicações desta imagem. 

Na saída, assegure-se de que o estado da replicação do conjunto não contenha a informação de sincronização velha. Verifique o mesmos que usam o Timestamp.

Se a sincronização da transmissão não é atualizada com uma data recente, execute o comando status do dbreplication dos utils verificar todas as tabelas e replicação. Se alguns erro/má combinação é descoberto, está mostrado na saída e nas mudanças de estado RTMT em conformidade, segundo as indicações desta imagem.

Depois que você executa o comando, todas as tabelas estão verificadas para ver se há a consistência e um estado exato da replicação é indicado.

Nota: Permita que todas as tabelas sejam verificadas e continue então mais pesquisar defeitos.

Uma vez que um estado exato da replicação é indicado, verifique a replicação Setup (RTMT) e detalhes segundo as indicações da primeira saída. Você deve verificar o estado para ver se há cada nó. Se qualquer nó tem um estado a não ser 2, continue a pesquisar defeitos.

Etapa 2. Recolha o estado do base de dados CM de Cisco unificado relatando a página no CUCM

1. Depois que você termina etapa 1, selecione Cisco unificado relatando a opção da lista de drop-down da navegação no editor do gerente das comunicações unificadas de Cisco (CUCM), segundo as indicações desta imagem.

2. Navegue aos relatórios do sistema e clique o estado unificado do base de dados CM segundo as indicações desta imagem.

3. Gerencia um relatório novo usando a opção nova do relatório da geração ou clique o ícone novo do relatório da geração segundo as indicações desta imagem.

 t

4. Uma vez que é gerado, transfira e salvar o relatório de modo que se possa fornecer a um coordenador TAC caso que um pedido do serviço (SÊNIOR) precisa de ser aberto.

Etapa 3. Reveja o relatório unificado do base de dados CM todo o componente embandeirado como um erro

Se há algum erro nos componentes, os erros estarão embandeirados com um ícone da cruz vermelha, segundo as indicações desta imagem.

• Assegure-se de que o Local e as bases de dados do editor estejam acessíveis.

• Em caso de um erro, verifique para ver se há a conectividade de rede entre os Nós. Verifique se um serviço de Cisco DB está sendo executado do CLI do nó usando o comando list do serviço dos utils.

• Se um serviço de Cisco DB está para baixo, execute o começo do serviço dos utils um comando de Cisco DB começar o serviço. Se isto falha, contacte o tac Cisco.     

• Assegure-se de que a lista do servidor de replicação (serviço da lista dos cdr) esteja povoado para todos os Nós.

 Esta imagem ilustra umas saídas ideais.

 Se a lista de Replicator do base de dados de Cisco (CDR) está vazia para alguns Nós, refira etapa 8.

• Assegure-se de que os anfitriões unificados, Rhosts e Sqlhosts CM estejam equivalentes em todos os Nós.

Esta é uma etapa importante. Segundo as indicações desta imagem, os anfitriões unificados CM, o Rhosts e o Sqlhosts são equivalentes em todos os Nós.

Os arquivos dos anfitriões são combinados mal:

Há uma possibilidade de uma atividade incorreta quando um endereço IP de Um ou Mais Servidores Cisco ICM NT muda ou atualizações ao hostname no server.

Refira este link a fim mudar o endereço IP de Um ou Mais Servidores Cisco ICM NT ao hostname para o CUCM.

Mudanças do endereço IP de Um ou Mais Servidores Cisco ICM NT e do hostname

  Reinicie os seguintes serviços do CLI do servidor do publicador e verifique se a má combinação é cancelada. Se sim, passe a etapa 8. Se nenhum, contacte o tac Cisco. Gerencia um relatório novo cada vez que você faz uma mudança no GUI/CLI para verificar se as mudanças são incluídas.

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

Os arquivos de Rhosts são combinados mal:

Se os arquivos de Rhosts são combinados mal junto com os arquivos de host, siga as etapas mencionadas sob os anfitriões que os arquivos são combinados mal. Se somente os arquivos de Rhosts são combinados mal, execute os comandos do CLI:

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

Gerencia um relatório e uma verificação novos se os arquivos de Rhost são equivalentes em todos os server. Se sim, passe a etapa 8. Se nenhum, contacte o tac Cisco.

O Sqlhosts é combinado mal:

Se o Sqlhosts é combinado mal junto com os arquivos de host, siga as etapas mencionadas sob os anfitriões que os arquivos são combinados mal. Se somente os arquivos de Sqlhosts são combinados mal, execute o comando do CLI:

utils system restart A Cisco DB

Gerencia um relatório e uma verificação novos se os arquivos de Sqlhost são equivalentes em todos os server. Se sim, passe a etapa 8. Se nenhum, contacte o tac Cisco

• Assegure-se de que o atendimento processual remoto da camada do base de dados (DBL RPC) olá! esteja bem sucedido, segundo as indicações desta imagem.

  Se o RPC olá! não trabalha para um nó específico:

- Assegure a conectividade de rede entre o nó específico e o editor.

- Assegure-se de que o número de porta 1515 esteja permitido na rede.

Refira este link para detalhes no uso da porta TCP/UDP:

Gerente TCP das comunicações unificadas de Cisco e uso de porta UDP

• Assegure-se de que a conectividade de rede esteja bem sucedida entre os Nós, segundo as indicações desta imagem:

Se a conectividade de rede falha para os Nós:

- Assegure-se de que a alcançabilidade de rede este presente entre os Nós.

- Assegure-se de que os números de porta apropriados TCP/UDP estejam permitidos na rede.

Gerencia um relatório novo, e a verificação para uma conexão bem sucedida. Em caso de uma conexão mal sucedida, passe a etapa 8.

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

Os utils diagnosticam o comando test verificam todos os componentes e retornam passado/falharam o valor. Os componentes que são essenciais para o funcionamento apropriado da replicação de base de dados são:

• Conectividade de rede:

O comando do validate_network verifica todos os aspectos da conectividade de rede com todos os Nós no conjunto. Se há uma edição com Conectividade, um erro está indicado frequentemente no Domain Name Server/Domain Name Server do reverso (DNS/RDNS). O comando do validate_network termina a operação em 300 segundos. Os mensagens de erro comum como visto nos testes da conectividade de rede:

1. O erro, uma comunicação intracluster é quebrado, segundo as indicações desta imagem.

- Causa

Este erro é causado quando uns ou vários Nós no conjunto têm um problema de conectividade de rede. Assegure-se de que todos os Nós tenham a alcançabilidade do sibilo.

- Efeito

Se a comunicação intracluster é quebrada, as edições da replicação de base de dados ocorrem.

2. Pesquisa de DNS reversa falhada.

- Causa

Este erro é causado quando a pesquisa de DNS reversa falha em um nó. Contudo, 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 faz funções corretamente, pode causar as edições da replicação de base de dados quando os server são definidos usando os nomes de host.

• Alcançabilidade do Network Time Protocol (NTP):

O NTP é responsável para manter o tempo do server em sincronia com o relógio de referência. Do editor as sincronizações sempre o tempo com o dispositivo cujo o IP é alistado como servidores de NTP; considerando que, as sincronizações dos assinantes o tempo com o editor.

É extremamente importante para o NTP ser inteiramente - funcional a fim evitar todas as edições da replicação de base de dados.

É essencial que o estrato NTP (número de saltos ao relógio de referência do pai) deve ser menos do que 5 ou então o julgará incerto.

Termine estas etapas a fim verificar o status NTP:

1. Use os utils diagnosticam o comando test verificar a saída, segundo as indicações desta imagem.

  2.  Adicionalmente, você pode executar o comando seguinte:

utils ntp status

Etapa 5. Verifique o estado da Conectividade de todos os Nós e assegure-se de que estejam autenticados

1. Depois que você termina etapa 4, se não há nenhuma edição relatada, execute o comando da conectividade de rede dos utils em todos os Nós verificar a Conectividade aos bases de dados é bem sucedido, segundo as indicações desta imagem.

2. Se você recebe não pode enviar pacotes TCP/UDP como um Mensagem de Erro, verifica sua rede para ver se há quaisquer retransmissões ou obstrui as portas TCP/UDP. O comando cluster da rede da mostra verifica para ver se há a autenticação de todos os Nós.

3. Se o statusof o nó é não-autenticado, assegure-se de que a conectividade de rede e a senha de segurança sejam mesma em todos os Nós, segundo as indicações desta imagem.

Refira os links para mudar/recupere as senhas de segurança:

Como restaurar senhas em CUCM

Recuperação da senha de administrador do sistema operacional CUCM

Etapa 6. As mostras do comando do runtimestate do dbreplication dos utils fora da sincronização ou dos estados não pedidos

É importante compreender que a replicação de base de dados é uma tarefa intensiva da rede porque empurra as tabelas reais para todos os Nós no conjunto. Assegure que:

•  Os Nós estão no mesmos centro de dados/local: Todos os Nós são alcançáveis com um Round Trip Time mais baixo (RTT). Se o RTT é unusally alto, verifique o desempenho da rede.

•  Os Nós são dispersados sobre o Wide Area Network (WAN): Assegure-se de que os Nós tenham a rede connecitivty bem sob a Senhora 80. Se alguns Nós não podem se juntar ao processo de replicação, aumente o parâmetro a um valor mais alto como mostrado.

utils dbreplication setprocess <1-40>

Nota: Mudar este parâmetro melhora o desempenho da instalação da replicação, mas consome recursos de sistema adicionais.

• O intervalo da replicação é baseado no número de Nós no conjunto: O intervalo da replicação (padrão: 300 segundos) são o tempo que o editor espera todos os assinantes a fim enviar a suas mensagens definidas. Calcule o intervalo da replicação baseado no número de Nós no conjunto.

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.

Verificar dos comandos/grupo o intervalo da replicação:

show tech repltimeout ( To check the current replication timeout value )
utils dbreplication setrepltimeout ( To set the replication timeout )

Etapas 7 e 8 devem ser executadas depois que a lista de verificação é cumprida:

Lista de verificação:

• Todos os Nós têm a Conectividade entre si. Consulte para pisar 5.

• O RPC é alcançável. Refira etapa 3.

• Consulte o tac Cisco antes de continuar com etapa 7 e 8 em caso dos Nós maiores de 8.

• Execute o procedimento fora nas horas de negócio.

Etapa 7. Repare tudo/seletivo as tabelas para a replicação de base de dados

Se o comando do runtimestate do dbreplication dos utils mostra que há um erro/tabelas combinadas mal, execute o comando:

Utils dbreplication repair all

Execute o comando do runtimestate do dbreplication dos utils verificar outra vez o estado.

Continue a etapa 8, se o estado não muda.

Etapa 8. Restaure a replicação de base de dados do risco

Refira a sequência para restaurar a replicação de base de dados e para começar o processo do risco.

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 do runtimestate do dbreplication RTMT/utils.

Refira a sequência para restaurar a replicação de base 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 que você alcança o tac Cisco para a assistência adicional, assegure-se de que as seguintes saídas e os relatórios estejam fornecidos:

utils dbreplication runtimestate
utils diagnose test
utils network connectivity

Relatórios:

• Cisco unificado relatando o relatório do base de dados CM (refira etapa 2)

• Os utils criam o comando database do relatório do CLI.  Transfira o arquivo de .tar usando um servidor SFTP.

Refira para mais informações o link:

Pesquisando defeitos o modelo do dispositivo de Linux da replicação de base de dados CUCM