É muito comum entre membros da comunidade técnica a ocorrência de discussões técnicas e troca de informações e conhecimentos, basicamente este é o real propósito de uma comunidade, trocar experiências, conhecimento e informações.

Estávamos Fabrício Lima (Site | Twitter) e Eu (Site | Twitter) em uma discussão muito interessante sobre o AlwaysOn Availability Groups (AG), discutindo algumas possibilidades e limitações para um cenário bastante específico que será descrito no decorrer deste blog post. Em resumo, queríamos ter a certeza da possibilidade (ou não) da configuração e perfeito funcionamento de um ambiente onde duas instâncias SQL Server com versões diferentes (2012 e 2014), instaladas no mesmo servidor fariam parte de dois AGs diferentes, tendo suas réplicas secundárias em outras duas instâncias instaladas em outro servidor, ambos obviamente no mesmo cluster.

O teste e o resultado estão detalhados a seguir:

O ambiente:

• Domain Controller
  • Servidor Windows Server 2012 R2 – (WS2012-DC)

• CLUSTERSQL-01 (Node01)
  • Servidor Windows Server 2012 R2 – (WS2012R2-01)
    • SQL Server 2012
    • SQL Server 2014

• CLUSTERSQL-01 (Node02)
  • Servidor Windows Server 2012R2 – (WS2012R2-02)
    • SQL Server 2012
    • SQL Server 2014

Cenário desejado:

O cenário final desejado seria conforme resumido na introdução deste artigo dois Availability Groups (AGs), sendo:

• Node01
  • WS2012R2-01
    • SQL Server 2012 “SQL2012-01” – Stand alone- AG_2012 (Primary)
    • SQL Server 2014 “SQL2014-01” – Stand alone – AG_2014 (Primary)

• Node02
  • WS2012R2-02
    • SQL Server 2012 “SQL2012-02“- Stand alone- AG_2012 (Primary)
    • SQL Server 2014 “SQL2014-02“- Stand alone – AG_2014 (Primary)

• Um Availability Group chamado AG_2012, configurado na instância SQL2012-01, que está instalado no servidor WS2012R2-01 de forma Stand Alone, tendo como réplica secundária a instância SQL2012-02 que está instalada de forma Stand Alone no servidor WS2012R2-02.

• Um Availability Group chamado AG_2014, configurado na instância SQL2014-01, que está instalado no servidor WS2012R2-01 de forma Stand Alone, tendo como réplica secundária a instância SQL2014-02 que está instalada de forma Stand Alone no servidor WS2012R2-02.

Problema(s) Encontrado(s):

• Problema 1:

  • O erro abaixo foi propositalmente provocado para mostrar uma premissa para a criação de um Availability Group. Os arquivos de dados (.MDF) e log de transações (.LDF) devem obrigatoriamente estar no mesmo diretório, ou seja seus metadados devem ser os mesmos em todas as réplicas.
  • Se durante a criação do Availability Grou (AG) for escolhida a opção de backup para um compartilhamento e restore pelo próprio wizard, o caminho do banco de origem (réplica onde se está criando o AG) deve existir nas réplicas secundárias, caso contrário o erro abaixo será exibido.
  • Para correção deste erro, basta corrigir / criar o caminho dos arquivos do banco de dados na origem.

• Problema 2:

  • O segundo problema encontrado, que também foi o motivador deste blog post, é relacionado à possibilidade de Múltiplos AGs para Múltiplas instâncias, conforme previamente demonstrado no cenário desejado.
  • O problema deu-se pelo fato de já existir um endpoint do tipo “Mirror endpoint”, que é utilizado pelo AlwaysOn Availability Group, entre os servidores WS2012R2-01 e WS2012R2-02 respondendo pela porta default que é a 5022.
  • Durante a criação do segundo AG com mesma origem e mesmo destino, o erro abaixo foi reportado, informando que o endpoint em questão já estava sendo utilizado por outro processo (no caso, o AG_2012).
  • Para correção imediata do problema, foi necessário voltar alguns passos e alterar a porta do que o novo endpoint utilizará, permitindo assim que existam 2 caminhos (endpoints) distintos para ambos os AGs (um para cada)

Conclusão:

Com base nos requisitos que motivaram o início dos testes, e após a realização dos mesmos, pudemos confirmar que é possível criar em um mesmo servidor, múltiplas instâncias com versões diferentes (ou não) do SQL Server com Múltiplos AlwaysOn Availability Groups configurados, replicando para outro servidor com situação semelhante.

Como na maioria dos cenários onde não há certeza plena do comportamento de uma situação ou configuração específica, é sempre muito prudente fazer testes para validar e se ter certeza de tal comportamento.

Aproveito para deixar a recomendação do blog do Fabrício Lima, que esteve juntamente comigo, pensando e realizando estes testes, é um blog com excelente conteúdo técnico e ótimas dicas.

• Fabrício Lima (Site | Twitter)

Grande Abraço,

Edvaldo Castro

http://edvaldocastro.com

Tweets by edvaldocastro02