Habilitando o Fast-Start Failover em uma configuração Data Guard

O Fast-Start Failover é uma funcionalidade onde o broker Data Guard faz um fail over automático para um dos bancos standby, previamente selecionado, no caso de perca do banco primário. Caso o Fast-Start Failover esteja habilitado, nenhuma ação manual se faz necessária para que esta ação seja executada.

É uma funcionalidade bastante útil para diminuir o downtime do ambiente em caso de falha e proteger contra a perca de dados.

Qualquer modo de proteção pode ser utilizado na configuração Data Guard enquanto o Fast-Start Failover está habilitado, embora apenas os modos Maximum Availability e Maximum Protection possam garantir a operação de failover com zero data loss (sem perca de dados).

Para a implementação do Fast-Start Failover, estaremos utilizando um site onde nem o banco primário, nem nenhum dos standby da configuração Data Guard estão. Esse site, que chamamos de observer, monitora a disponibilidade do banco primário, e caso o mesmo perca a comunicação com o observer e o standby por um tempo maior que o definido na configuração do broker, o observer inicia um procedimento de failover automaticamente.

O ambiente

Para fins de demonstração, estaremos utilizando a seguinte configuração Data Guard:

Nesta configuração temos:

• orcl: é o banco primário;
• orcldg: é o banco standby físico;
• MaxPerformance: indica que a nossa configuração está em modo Maximum Performance;
• O Fast-Start Failover está desabilitado;

Alterando o modo de proteção

Para este exemplo, temos o objetivo de assegurar que não exista perca de dados em caso de falha do banco de dados primário, objetivo este que o modo de proteção atual, Maximum Performance, não nos fornece. Para este exemplo, estaremos alterando o modo de proteção para Maximum Availability.

Atualmente, a propriedade LogXptMode se encontra com o valor ‘ASYNC’ em ambos os bancos:

Esta propriedade é responsável pelo modo de transporte de redo. Neste caso, o modo ‘ASYNC’ é usado para o modo de proteção Maximum Performance, onde o commit das transações pode ser feito sem que exista uma confirmação de recebimento por parte dos destinos de redo.

Para habilitarmos o modo Maximum Availability, estaremos alterando esta propriedade para ‘SYNC’. Neste modo, as transações só serão commitadas quando os destinos de redo confirmarem o recebimento e a escrita do redo nos standby redo log files.

Para realizar a atualização utilizamos:

DGMGRL> EDIT DATABASE orcl SET PROPERTY 'LogXptMode'='SYNC';
DGMGRL> EDIT DATABASE orcldg SET PROPERTY 'LogXptMode'='SYNC';

Após a alteração feita, podemos alterar o modo de proteção utilizando:

DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;

Verificando a configuração podemos verificar que o modo de proteção foi atualizado:

Propriedades importantes

Antes de habilitar o Fast-Start Failover, podemos verificar a propriedade ‘FastStartFailoverThreshold’:

Esta propriedade é responsável por definir o tempo que o Observer tentará se conectar ao banco primário antes de executar o fail over para o standby definido. O standby para o qual será feito o fail over fica definido na propriedade FastStartFailoverTarget:

Neste cenário, em caso de falha do banco primário ‘orcl’, o banco alvo do fail over será o ‘orcldg’.

Habilitando o Fast-Start Failover

Para habilitar o Fast-Start Failover precisamos acessar o banco primário via DGMGRL no host Observer, aquele onde nem o banco primário nem o standby reside. É necessário para isso que este host possua ao menos o client administrador instalado. Além disso, é necessário que as entradas do banco primário e do standby existam no tnsnames do Observer.

Para habilitar o Fast-Start Failover, utilizamos:

DGMGRL> ENABLE FAST_START FAILOVER;

Executando o comando, podemos verificar que o modo foi habilitado em modo Zero Data Loss, que significa que, em caso de falha do banco primário, não haverá perca de dados em um fail over automático.

Podemos verificar a configuração do Fast-Start Failover usando:

DGMGRL> SHOW FAST_START FAILOVER;

O resultado é:

Esse comando nos mostra informações como:

• Threshold: tempo de espera antes de executar o fail over em caso de falha de comunicação com o banco primário;
• Active Target: o standby alvo do fail over;
• Potential Targets: bancos standby da configuração que são elegíveis para o fail over;
• Observer: o nome do observer;

Neste caso o Observer não está definido, pois ainda não foi iniciado. Para iniciá-lo utilizamos:

DGMGRL> START OBSERVER;

Neste caso, a sessão do DGMGRL não poderá ser utilizado para input de outros comandos. Podemos iniciar o Observer em background através do comando:

DGMGRL> START OBSERVER IN BACKGROUND;

Para que este comando funcione corretamente é preciso que o banco possua uma wallet configurada, a qual o Oracle utilizará para autenticar no banco para realizar o monitoramento. Caso o banco não possua uma wallet configurada podemos utilizar o comando ‘nohup’ do Linux para executar o comando, e salvar um log do funcionamento do mesmo:

$ nohup dgmgrl sys/senha@orcl "start observer file='/home/oracle/fsfo.dat'" -logfile /home/oracle/observer.log &

Com o Observer iniciado, podemos verificar mais informações sobre ele com o comando ‘SHOW OBSERVER’:

Por padrão, o nome do Observer é o mesmo que o hostname do local onde ele está sendo executado.

Agora podemos verificar que a informação foi atualizada no retorno do comando ‘SHOW FAST_START FAILOVER;’:

A partir deste momento, caso o banco primário falhe, o Observer irá aguardar 30 segundos, enquanto tenta se conectar com o banco primário, e caso não consiga, irá iniciar um fail over automaticamente.

Conclusão

A implementação do Fast-Start Failover facilita a administração da configuração Data Guard em casos de falha do banco primário, reduzindo o downtime da base e removendo a necessidade do DBA estar fazendo o processo de fail over manualmente.

Espero através deste artigo ter ajudado no entendimento do processo de Fast-Start Failover e na sua aplicação em configurações Data Guard.

Um grande abraço a todos!