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/.
- Se 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:
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
Para mais informações sobre esse assunto, clique aqui!