É possível utilizar AG com versões diferentes de SQL? (Passo a passo de como montar um AG básico)

 Olá pessoal, hoje estou trazendo um blog de cara nova e um novo tipo de postagem, geralmente eu faço postagens sobre T-SQL que é uma linguagem que eu amo, mas hoje gostaria de trazer algum diferente. Hoje irei falar sobre SQL  AlwaysOn AG(availability group), eu não irei entrar muito afundo nesse assunto, pois ele renderia uma série de posts, nesse post estarei demonstrando como criar um AG básico para fins de estudo, mas nada impede de você usar esses passos para começar a pensar em uma solução de HA/DR para sua empresa.

Antes de responder a pergunta desse post, vamos criar o ambiente:

Primeiro é necessário ter um ambiente em cluster(WSFCI), o que não daria tempo de demonstrar nesse post, então irei deixar uma dica de livro, onde existe um passo a passo para criar um ambiente de alta disponibilidade com AlwaysON FCI. Melhor livro de FCI em pt-br "SQL SERVER 2014 -ALTA DISPONIBILIDADE NA PRÁTICA COM ALWAYSON FAILOVER CLUSTER INSTANCES", deixarei um link no final do artigo de onde comprar :)

Demonstração gráfica do ambiente:

Visualização do  "Failover Cluster manager"- NODES:

Como falei, não irei demonstrar como "subir" um ambiente com cluster, pois isso demandaria um bom tempo, mas deixei o livro para que possam aprender :)

Irei levar em consideração que você já tenha o ambiente em cluster e irei demonstrar o passo a passo para inserir uma base no AG:

Antes de começarmos os passos, verifique se a opção"  Enabled Alwayson..." Estar ativa. essa opção fica no Configuration manageer"

Passo 1  - Gerar Backup full das databases que irão colocar no AG, de preferencia em um disco onde os dois nós possam enxergar o arquivo

backup database  Northwind to disk = 'C:\temp\bkp\nofull.bak'

Passo 2 - Realizar o restore WITHNORECOVEY  no node secundário (Esse passo pode ser pulado, caso você opte por utilizar o "Automatic seeding", uma ótima opção, mas cuidado, pois em bases muito grandes pode ser lento, nesse laboratório mesmo a base sendo pequena, optei, pelo "Join Only", onde eu preciso fazer os passos 1 e 2.

Passo 3 - Adicionar um grupo de disponibilidade:

No node primário, clique em "Alwayson High availability" -> "New availability  Group Wizard..." 

              

Irá abrir uma tela para selecionar o nome do grupo de disponibilidade, fica a sua escolha:

Na próxima tela, você irá selecionar as databases, importante que essa database esteja com um backup full:

Na próxima tela, iremos selecionar a instância que abrigará a réplica secundária:

Eu destaquei o "availability   mode", pois acho uma configuração importante, irei resumir abaixo:

"Asynchronous-Commit Availability Mode", nesse modo o SQL não esperará o log de transações ser comitados nas réplicas secundárias, por esse motivo não é possível ter o "failover automático", pois esse modo permite "data loss", esse modo é recomendado em situações onde  existe uma distância geográfica entre os nodes, ou em situações onde, caso haja algum com o node secundário não afete o primário.

"Synchronous-Commit Availability Mode", nesse modo o SQL irá aguardar o log de transações gravar os dados nas réplicas secundárias para então dar o "commit" na réplica primária, esse modo permite "Failover automático", pois  ele garante  que não irá acontecer data loss.

Próxima tela, você irá escolher a réplica secundária:

Essa é a parte onde iremos escolher como iremos realizar a "Junção" das réplicas, como mencionei acima, optei pelo "Join Only", que pode ser usada pois realizar o backup full e restauramos esse arquivo na réplica secundária, com a opção "NoRecovery":

SUCESSO:

visão do AG:

Chegamos ao fim da instalação do nosso AG, para nosso lab, MAS  ainda continua, vamos responder a pergunta do post, aqui não tem fake news rs.

Reparem que nesse momento, estou no SQL 2016 e essa query não retorna nada:

Vamos fazer o failover pra réplica secundária que é nosso SQL2019:

Como eu deixei a opção " Asynchronous-Commit Availability Mode", o SQL dar um aviso de "Potential data loss"

Failover concluído com sucesso:

Reparem que agora o SQL2019 é o primário e o SQL2016 o secundário:

No sql2019 (réplica primária) irei inserir um registro:

Inserir um registro e ele retornou na minha query:

Por algum motivo, precisamos voltar o node, realizar o "fallback", será que o processo de fallback irá acontecer sem erros?

Mesmo processo:

Opa, SEM ERROS...

Vamos olhar novamente....

Reparem que mesmo que o fallback não deu erro, o SQL não consegue mais sincronizar as réplicas, ou seja tudo que foi feito no SQL2019 não será replicado no SQL2016:

Mas e se a gente fazer um "resume".. vamos tentar...:

Hum, mas parece que foi hein :0 

OLHE NOVAMENTE ABAIXO:

É... Não foi :(

Vamos ver se aquele insert vai aparecer no SQL2016?

NADA!! Como o esperado.

Conclusão:

Não é possível realizar o fallback para versões anteriores, como sempre o SQL não nos deixar fazer o downgrade, sem novidades até aqui, CUIDADO, pois apesar do processo de fallback não apresentar erros aparente, isso não significa que funcionou.

 Por hoje é isso pessoal, espero que tenham gostado de estarem comigo nesse post.  Até mais, abraços :)

Links de apoio:

https://docs.microsoft.com/pt-br/sql/database-engine/availability-groups/windows/availability-modes-always-on-availability-groups?view=sql-server-ver15

https://docs.microsoft.com/pt-br/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server?view=sql-server-ver15

https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/automatic-seeding-secondary-replicas?view=sql-server-ver15

Link do Livro:

https://www.amazon.com.br/Microsoft-Server-2014-Disponibilidade-Pr%C3%A1tica/dp/8536512997