Loading…

Managed Instance (#16) – É verdade que nossa instância já vem com um AlwaysOn AG configurado?

Fala Pessoal,

Esse é mais um post da série sobre o Azure SQL Database Managed Instance.

E ai Fabrício, é verdade mesmo que o MI (Managed Instance) já vem com um AlwaysOn AG ou é papo de vendedor e palestrante???

Resposta de consultor.  Depende!  =)

Como já respondi no post #14, o MI já vem com um AlwaysOn AG quando contratamos o Tier Business Critical.

Vamos comprovar isso agora.

Vou executar essa query abaixo nos 2 Managed Instance que tenho, General Purpose e Business Critical:

Segue o resultado da execução no General Purpose:

  • Repare que temos apenas 1 linha por base de dados.
  • Interessante o ID que é gerado para as bases Master e Model. Diferente do On premise.

Segue agora o resultado da query no Tier Business Critical:

WOW!

Comentários:

  • Agora temos 4 linhas por base de dados.
  • A coluna is_primary_replica nos diz que temos 1 instância primária e 3 réplicas.
  • As bases de sistema Master, Model e Msdb também sáo replicadas no AG, ou seja, nossos jobs e logins já são replicados automaticamente. Essa é uma feature que só vai ser liberada no SQL Server 2019 e o MI já está usando. Isso é mais um exemplo de que com o MI você terá as melhorias do SQL Server muito antes de estarem disponíveis para uso no On Premise.

Que top Fabrício!!! =)

Quer dizer que agora não tenho que me preocupar com licença enterprise, configuração de cluster, criação manual do AlwaysOn, Manutenção do AlwaysOn e etc???

R: Exato. Com o Business Critical, você só se preocupa em usar.

Como disse no post anterior, o Failover do Business Critical é muito mais rápido que o failover do General purpose, devido a esse AlwaysOn AG que é configurado por trás dos panos. A tecnologia utilizada para replicação dos dados é diferente do General Purpose.

Vamos criar uma base nova no Business Critical e ver se ela já entra no AlwaysOn.

Repare que demorou 20 segundos para criar uma base vazia. Esse tempo já inclui a configuração do AlwaysOn AG.

Se restaurar uma base grande no Business Critical, o tempo de restore dela será maior que na General Purpose devido ao tempo de replica do AlwaysOn AG. Depois posso fazer um post com esse teste.

Após a criação da base, rodei a query novamente, mas agora acrescentando a coluna replica_id:

Pronto. Já está lá nossa nova base com o AlwaysOn configurado. Reparem o replica_id diferente para cada réplica.

Top demais!

Fabrício, é verdade que consigo usar uma das réplicas como leitura?

R: Sim. É posssível!

Como faço isso?

Para acessar a réplica read only que está disponível para uso temos que passar o parâmetro “ApplicationIntent=ReadOnly” na String de conexão que faremos com o banco. Segue um exemplo de uso com o SSMS :

1 – Ao logar no SSMS, clique em Options

2 – Clique na aba Additional Connection Parameters

3 – “ApplicationIntent = ReadOnly”

 

Com o comando abaixo conseguimos comprovar que estamos na réplica Read_Only:

Ao tentar fazer qualquer operação diferente de leitura nessa réplica vamos receber o erro abaixo:

 

Agora vamos fazer um select na réplica para confirmar que funciona:

Muito TOP.

No próximo post vamos fazer um teste simulando um ambiente de produção para ver como essa réplica pode nos ajudar no balanceamento de performance do ambiente.

Não perca!

Caso ainda não tenha visto, seguem os posts anteriores:

 

Gostou dessa Dica?

Curta, comente, compartilhe…

Assine meu canal no Youtube , curta minha página no Facebook  ou siga nossa página no Instagram para receber Dicas de Leituras, Vídeos e Eventos sobre SQL Server.

Até o próximo post.

Abraços,

Fabrício Lima

Microsoft Data Platform MVP

Consultor e Instrutor SQL Server

Trabalha com SQL Server desde 2006

Deixe uma resposta

%d blogueiros gostam disto: