SQL Server 2016 – Testando uma das novas features do AlwaysON: Database Level Health Detection

Olá pessoal, tudo bem?

Após concluir os testes de failover no SQL Server 2014 AlwaysON que documentei em uma das publicações anteriores, resolvi executar dois deles novamente sobre a versão 2016 do SQL Server, visto que nela haverá uma nova funcionalidade que mudará o comportamento e consequentemente, o resultado de um destes testes.

Descrição do ambiente

Meu ambiente é muito similar ao utilizado nos testes de failover do SQL Server 2014, mas desta vez as máquinas se chamam SQL-AON11 e SQL-AON12, ambas com Windows Server 2016 Technical Preview 4 e SQL Server 2016 CTP 3.3. Todos os demais pré-requisitos para se configurar o AlwaysON também foram atendidos, como por exemplo, a criação de um cluster.

Fiz o restore do mesmo banco de dados utilizado no cenário anterior (AdventureWorks2014) usando as mesmas configurações de disco, ou seja, o sistema operacional instalado na unidade C, arquivos de dados na unidade E e arquivos de log na unidade F. São estes dois últimos discos que iremos remover para simular um problema de indisponibilidade.

Teste 1: Remover o disco de dados do banco de dados

Antes da indisponibilidade

Ambiente totalmente funcional. Nome virtual do grupo de disponibilidade e banco de dados AdventureWorks2014 completamente operacionais no servidor primário, conforme esperado.

Indisponibilidade do disco

Unidade E offline.

Disk Manager

image

Neste momento, nenhum failover foi acionado. O grupo de disponibilidade continua ativo na mesma máquina, porém, qualquer query que force o SQL Server a realizar uma leitura em disco não é realizada com sucesso. O SQL Server também não detectou que o banco de dados não está funcionando adequadamente e mantém o status “synchronized”.

Conclusão

No SQL Server 2016, em uma eventual indisponibilidade do arquivo de dados ainda não provoca a realização do failover, sendo necessário realizá-lo manualmente. Em comparação ao SQL Server 2014, nada mudou neste sentido.

Teste 2: Remover o disco de log do banco de dados

Antes da indisponibilidade

Ambiente totalmente funcional novamente.

Indisponibilidade do disco

Unidade F offline.

Disk Manager

image

Neste momento, considerando que meu ambiente não tem nenhuma transação em execução neste instante, nada acontece. O failover automático não é acionado e o SQL Server continua exibindo status “synchronized” no object explorer.

Ao executar um comando uma query que apenas selecione dados, ou seja, não tenha necessidade de escrever informações ao log, a consulta é processada e os dados são retornados com sucesso. Este mesmo comportamento não acontece quando uma transação que faça modificações nos dados (ou qualquer outro tipo que necessite escrever ao log).

No momento em que um comando Update (por exemplo) é executado, um erro é disparado, o SQL Server detecta que aquele banco de dados está com problemas e aciona o failover automático, mudando o grupo de disponibilidade para o servidor secundário (que esteja com o failover automático habilitado) imediatamente.

Failover Cluster Manager

image

Além de realizar o failover, o SQL Server altera o status do banco de dados naquele servidor onde o disco não está mais disponível para “Not synchronizing / Recovery Pending”.

Object Explorer

image

Finalmente, como esperado, as conexões direcionadas ao Virtual Name (neste ambiente, VN11) passam a ser executadas na máquina que assumiu o grupo de disponibilidade normalmente.

Management Studio

image

Conclusão

O SQL Server 2016, diferentemente de sua versão anterior, proverá melhor detecção a falhas em nível de banco de dados propriamente dito e assim acionará o failover automático quando o tipo de problema for detectável por ele, como foi o caso da indisponibilidade do arquivo de log especificamente.

Como vimos, o mesmo comportamento não se repetiu quando a falha ocorreu no disco de dados, significando que mesmo com o novo mecanismo de detecção à falhas implantado na versão CTP3.3 do SQL Server 2016 ainda há necessidade de se complementar a monitoração para que este tipo de problema seja contemplado.

Ativação da Funcionalidade

O acionamento da funcionalidade “Database Level Health Detection” pode ser habilitado na interface de criação do grupo de disponibilidade, como demonstrado na imagem abaixo:

image

Podemos ver também que, na versão 2016 do SQL Server, o wizard de criação do grupo de disponibilidade sofreu algumas mudanças, justamente para contemplar novas funções e recursos do AlwaysON Availability Groups.

Em um grupo já existente, que tenha sido atualizado do SQL Server 2014 para a nova versão ou que no momento da implantação, essa opção não tenha sido considerada, é possível ativar essa verificação através do painel de configuração, acessado pela opção “properties” do grupo de disponibilidade em questão.

Propriedades do grupo de disponibilidade

image

Conclusão Geral

Observamos nos testes apresentados acima uma das novidades do AlwaysON no SQL Server 2016 em funcionamento. Percebemos que, embora ainda não proteja contra todas as possíveis falhas, já possui melhorias em relação a detecção de problemas em nível de banco de dados.

Essa nova funcionalidade ajudará no processo de disaster recovery, visto que permitirá a realização do failover automático, reduzindo assim o downtime associado a detecção do problema e consequentemente os impactos dele, dando também maior tranquilidade ao administrador de banco de dados para atuar junto à resolução do problema.

Felipe de Assis

https://br.linkedin.com/in/fdassis

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s