1. Home
  2. First Steps
  3. Disaster Recovery

Disaster Recovery

Objetivo

Demonstrar como realizar no mesmo equipamento, onde a base foi corrompida um Disaster Recovery, para restaurar o acesso ao OpMon.

Público-alvo

Destinado aos administradores do OpMon que necessitam realizar o Disaster Recovery.

Pré-requisitos

  • Antes de realizar o procedimento é necessário possuir o dump das bases do OpMon que estão disponíveis no diretório /var/tmp/opmondb/.
  • Ser a mesma instalação, apenas a base corrompeu, em caso de mudança de equipamento, os plugins customizados devem ser copiados.

Solução

Primeiramente certifique-se de que os dumps das bases opmon4 e opcfg estejam disponíveis, para isso, digite o comando:

[root@opmon]# ls -l /var/tmp/opmondb

Ao executar esse comando, você deverá visualizar uma tela similar a abaixo apresentada:

disaster_recovery

Caso você salve os backups em disco externo ou em outra máquina, os mesmos deverão ser removidos para este diretório.

Em seguida, pare o MySQL e o OpMon utilizando os seguintes comandos:

[root@opmon]# service opmon stop
[root@opmon]# service mysql stop

Agora, acesse o diretório onde se encontram os bancos de dados:

[root@opmon]# cd /var/lib/mysql

Para remover as bases danificadas, digite o comando:

[root@opmon mysql]# rm -rf *

Apos, digite o seguinte comando:

[root@opmon]# mysql_install_db --user=mysql --datadir=/var/lib/mysql/

Reinicie o serviço MySQL, utilizando seguinte comando:

[root@opmon]# service mysql restart

Acesse o diretório db com o comando:

[root@opmon]# cd /usr/local/opmon/db/

Para recriar as bases do OpMon, digite os comandos:

[root@opmon db]# touch updatedb
[root@opmon db]# php updatedb.php

Caso você esteja realizado uma migração de versões majors diferentes, por favor verifique o item: Cuidados ao realizar migrações de Majors diferentes, no final da página antes de prosseguir.

Para restaurar a base inicial para operar, digite:

[root@opmon db]# /usr/local/opmon/utils/opmon-base.pl -D

Pode ocorrer um alerta similar a este abaixo, não se preocupe, siga o processo:

Logging on file /var/log/opdb-dump.log
2017/3/2 16:3:1 - -> Starting database disaster recovery
2017/3/2 16:3:1 - -> Starting database opcfg recover
ERROR 1050 (42S01) at line 1: Table 'host_state_change_1' already exists
ERROR 1050 (42S01) at line 1: Table 'service_state_change_1' already exists
2017/3/2 16:3:5 - -> Database opcfg recover done

Para permanecer com o tempo de duração de um estado do elemento monitorado, precisa copiar do servidor antigo para o novo servidor o arquivo status.sav.

[root@opmon-antigo]# scp /usr/local/opmon/var/status.sav root@IP_DO_SERVIDOR:/usr/local/opmon/var/.

Após restaurado a base, rode o Export, pela interface WEB ou pela console, conforme comando abaixo.

[root@opmon]# php /usr/local/opmon/share/opcfg/tools/exporter/export.php 1 opmonadmin 127.0.0.1

Para restaurar os dados históricos de estado, precisa ser restaurada a base opmon4.

[root@opmon]# /usr/local/opmon/utils/opmon-base.pl -r opmon4

Para restaurar os dados históricos de performance, precisa ser restaurada a base opperf.

[root@opmon]# /usr/local/opmon/utils/opmon-base.pl -r opperf

O processo de restaurar a base opmon4 e opperf devem demorar algumas horas, dependendo do tamanho da base histórica, mas após concluído todo o histórico deve estar acessível no OpMon.

Cuidados ao realizar migrações de Majors diferentes

Se você está seguindo esta documentação para realizar migração de ambientes, caso elas sejam de versões majors diferentes é necessário se atentar para os passos a seguir:

Este procedimento é válido somente para migrações de versão 7 para versão 8 do OpMon. Em caso de versões abaixo da 7, por favor entrar em contato com a OpServices.

Ao realizar o procedimento antes de importar o backup do OpMon, é necessário zipar o backup. Isso ocorre porque a forma que o backup é feito e restaurado na versão 8.0 do OpMon é diferente da versão 7.0. Para isso, execute o comando abaixo em cada uma das pastas do backup (opcfg, opmon4 e opperf):

[root@opmon]# gzip *

Após zipada todos os diretórios pode seguir com os procedimentos a seguir:

[root@opmon db]# /usr/local/opmon/utils/opmon-base.pl -D

Pode ocorrer um alerta similar a este abaixo, não se preocupe, siga o processo:

Logging on file /var/log/opdb-dump.log
2017/3/2 16:3:1 - -> Starting database disaster recovery
2017/3/2 16:3:1 - -> Starting database opcfg recover
ERROR 1050 (42S01) at line 1: Table 'host_state_change_1' already exists
ERROR 1050 (42S01) at line 1: Table 'service_state_change_1' already exists
2017/3/2 16:3:5 - -> Database opcfg recover done

Para permanecer com o tempo de duração de um estado do elemento monitorado, precisa copiar do servidor antigo para o novo servidor o arquivo status.sav.

[root@opmon-antigo]# scp /usr/local/opmon/var/status.sav root@IP_DO_SERVIDOR:/usr/local/opmon/var/.

Após realizado isso, é necessário rodar novamente o seguinte procedimento:

Acesse o diretório abaixo:

[root@opmon]# cd /usr/local/opmon/db/

Recrie as bases do OpMon novamente:

[root@opmon db]# touch updatedb
[root@opmon db]# php updatedb.php

Após restaurado a base, rode o Export, pela interface WEB ou pela console, conforme comando abaixo.

[root@opmon]# php /usr/local/opmon/share/opcfg/tools/exporter/export.php 1 opmonadmin 127.0.0.1

Feito isso, pode seguir com a importação dos dados históricos conforme abaixo.

Para restaurar os dados históricos de estado, precisa ser restaurada a base opmon4.

[root@opmon]# /usr/local/opmon/utils/opmon-base.pl -r opmon4

Para restaurar os dados históricos de performance, precisa ser restaurada a base opperf.

[root@opmon]# /usr/local/opmon/utils/opmon-base.pl -r opperf

 

Updated on March 9, 2018

Was this article helpful?