Este artigo visa abordar uma das possibilidades de alta disponibilidade que existem para o banco de dados DB2 da IBM , em se tratando deste middleware, é o HADR (High Availability Disaster Recovery) que teremos como melhor opção além de gratuito dentro do licenciamento do BANCO.
O HADR funciona como um espelhamento da base principal para outro servidor onde a base fica em standby.
Os logs da base principal são enviados ao servidor secundário de forma síncrona, ou quase síncrona (nearsync), e alimentam a base em standby.
Quando há alguma interrupção na base principal, a base secundária assume as aplicações conectadas de onde elas estiverem.
O HADR funciona entre bases de dados e suas instâncias, ou seja, um mesmo servidor pode ter uma base primária replicando para uma base secundária em outro servidor, enquanto o segundo tem também uma outra base primária em outra instância que replica para uma base secundária (standby) alocada no primeiro.
Contudo para a correta implantação e utilização do HADR, alguns requisitos básicos deverão ser levados em consideração, para que a contingência não termine sendo um problema maior do que a interrupção que causou o desastre.
COMO O HADR FUNCIONA:
O HADR é baseado na repetição dos logs: Inicializa-se o servidor de standby com um backup completo da base primária, sendo que essa, de preferência, deve estar fora do ar, ou seja, sem nenhum acesso durante a implantação do HADR.
Depois disso, configura-se o HADR nas bases de dados primária e secundária (standby). Os logs primários de transações são enviados para o modo de espera através de uma conexão TCP.
O servidor standby repete continuamente os registros dos logs da base primária, para manter-se em sincronia com ela.
Se o servidor primário falhar, emite-se um comando de “takeover HADR by force”, no modo de espera, para fazer do servidor standby o novo servidor primário. Um único comando faz tudo.
Caso seja uma manutenção planejada, emite-se um comando “HADR” (sem opção “by force”) para trocar de papéis primário e secundário. A gestão do HADR é simples. Há apenas 3 comandos: START HADR, STOP HADR, e TAKEOVER HADR.
REQUISITOS NECESSÁRIOS PARA IMPLANTAÇÂO DO HADR:
A base secundária é mantida como uma imagem espelhada da primária desta maneira diversos aspectos das bases de dados principais e de standby precisam ser idênticos.
Em primeiro lugar, as bases primária e de standby devem ter a mesma plataforma.
De preferência, se possível, tudo deve ser idêntico, principalmente no que diz respeito aos ambientes operacionais e de storage: mesma versão do SO com as mesmas atualizações, mesmas áreas de disco para dados, logs, etc.
(As bases primária e secundária devem ter os mesmos paths (diretórios) para containers de tablespaces. Nesse caso, a exigência de caminho do container pode muitas vezes estar satisfeito com links simbólicos. O servidor de standby deve ter igual ou maior capacidade de storage).
A restauração redirecionada (uma possibilidade do comando de RESTORE do DB2) não é suportada ao criar o standby.
No entanto, as mudanças do diretório de banco de dados (para arquivos de metadados de banco de dados) e log de transações de diretório são suportados durante a restauração.
Ainda, a mesma quantidade de memória é recomendada em ambos os servidores, para que a replicação dos bufferpools seja menos provável de falhar. O parâmetro mais importante HADR é o modo de sincronização HADR, que podem ser síncrono (sync) ou quase síncrono (nearsync).
A rede pode se tornar o gargalo em sistemas de DR. Por exemplo, se a taxa de registro de pico for de 20 MB / seg, enquanto que o rendimento da rede é de 15MB / seg, a taxa de transferência será limitado a 15MB / seg. Se isto não for aceitável, a rede deve ser revista e atualizada.
Uma rede privada dedicada é recomendada entre os servidores, por razões de desempenho e segurança. O HADR não criptografa o tráfego entre ambos, ou seja, dados de registro são enviados como são.
