Como redefinir a replicação do banco de dados do Cisco Emergency Responder

Introduction

Este documento descreve como redefinir a replicação do banco de dados do Cisco Emergency Responder (CER).

Prerequisites

Requirements

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas; no entanto, a versão usada para criar este documento é CER versão 10.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Procedimento de redefinição da replicação do banco de dados CER

Etapas do resumo

Etapa 1. Detele entradas na tabela do banco de dados cerremote usando a CLI (Command Line Interface, interface de linha de comando) do nó primário CER.

Etapa 2. Reinicie os serviços nos nós primário e secundário.

Etapa 3. Redefina a duplicação do CLI do nó primário CER.

Etapa 4. Reinicialize o nó secundário.

Etapa 5. Verificar replicação

Etapa 6. Repita o processo, se necessário

Etapas detalhadas

Na CLI do servidor primário, exclua as entradas na tabela cerremote

Use o comando run sql delete from cerremote para excluir as entradas na tabela do banco de dados cerremote e confirme se não há entradas na tabela cerremote usando o comando run sql select name from cerremote.

Dos serviços de reinicialização CLI dos servidores primário e secundário

Use os comandos abaixo para reiniciar os serviços nos nós primário e secundário:

• utils service restart Cisco Emergency Responder
• utils service restart Cisco Tomcat
• utils service restart A Cisco DB Replicator
• utils service restart Cisco IDS ou utils service stop Cisco IDS e utils service start Cisco IDS
  

A partir da replicação de redefinição de CLI do servidor primário

Na CLI do nó primário, use o comando utils dbreplication reset all para redefinir a replicação no cluster.

Na CLI do servidor secundário, reinicialize o servidor

Quando a redefinição termina no primário, um prompt para reinicializar o nó secundário é exibido. Neste ponto, reinicialize o secundário da CLI usando o comando utils system restart.

Verificar a replicação quando o secundário estiver em serviço completo

Quando o servidor secundário estiver em serviços completos, verifique a replicação do banco de dados da CLI do primário usando o comando utils dbreplication status.

Há um comando file view na saída do comando status. Use o comando file view para confirmar que não há problemas.

file view ativelog er/trace/dbl/sdi/ReplicationStatus.YYYY_MM_DD_HH_MM_SS.out

A replicação pode ser observada como não configurando corretamente se as seguintes saídas forem vistas em vez de Connected como visto acima.

SERVER                 ID STATE    STATUS     QUEUE  CONNECTION CHANGED
-----------------------------------------------------------------------
g_cer10_cer10_0_2_10000_11    2 Active   Local           0
g_cersub_cer10_0_2_10000_11    3 Active   Connecting 165527

SERVER                 ID STATE    STATUS     QUEUE  CONNECTION CHANGED
-----------------------------------------------------------------------
g_cer10_cer10_0_2_10000_11    2 Active   Local           0
g_cersub_cer10_0_2_10000_11    3 Active   Disconnect      0

Repita o processo, se necessário

Se a replicação ainda não tiver sido bem-sucedida, talvez seja necessário repetir esse procedimento até duas vezes mais.  Se a replicação não for bem-sucedida após executar este procedimento 3 vezes, exclua e reinstale o assinante.