Fale Conosco

Converse com nossos especialistas e descubra como transformar seus dados em informações seguras, disponíveis e acessíveis.

Endereço

Rua Angelo Antonello, 93 – Sala 62, Centro – Farroupilha/RS – CEP: 95170-492

Contato Comercial

Email: contato@cdbdatasolutions.com.br
Telefone: (54) 3401-1471

Laboratório de Alterações de Arquivos do AG

  • Por Rodrigo Crespi e Tiago Crespi
  • 28/02/2022
  • 7 Visualizações

Olá, pessoal!

Neste post falaremos de algumas características do AlwaysOn Availability Group (AG), sendo três alterações de estrutura de banco de dados, assim entenderemos como elas irão se comportar com o AG.

A pouco tempo fizemos alguns laboratórios para verificar o impacto das mudanças em um ambiente crítico e relativamente grande com o AG. Uma observação importante é que neste ambiente não há como fazer o Seeding por questões de estrutura das VMs envolvidas.

O que precisávamos responder com o laboratório era:

  • Qual seria o comportamento do AG com a movimentação dos arquivos de dados para novas unidades? E se haveria alguma forma de fazer esta mudança sem refazer o AG.
  • Se criarmos um arquivo de dados novo em um banco de dados no AG qual será o comportamento da réplica?
  • É possível criar uma replicação tendo como nó primário da mesma, o nó secundário do AG?

Vamos esclarecer uma pergunta por vez!

Primeiro Tópico:

Em nossos testes encontramos somente uma forma de fazer isso e com algumas restrições. Segue os passos a serem seguidos:

1- Pausar a replicação dos bancos;

2- Parar os serviços do SQL Server em ambos os nós;

3- Copiar\mover os arquivos dos bancos para as novas unidades;

4- Alterar as letras das novas unidades para as mesmas letras das unidades originais;

5- Iniciar novamente os serviços do SQL Server;

6- Reiniciar a sincronização dos bancos.

Quais são as restrições para esta atividade?

1 – Tempo de parada:
Por ser um ambiente crítico o tempo de parada é mínimo. Para esta atividade teremos que agendar uma janela de parada com o cliente, pois todos os bancos desta instância ficariam indisponíveis enquanto a cópia dos arquivos é feita. A estimativa de tempo é difícil de mensurar, deve-se levar em consideração o tamanho dos arquivos, velocidade do disco de origem e destino, latência de rede entre os storages etc.

2 – Movimentação de arquivos:
Se os arquivos forem movidos para unidades já existentes e que já tenham arquivos de outros bancos, estes “outros” bancos apontarão para uma unidade que, provavelmente, não existirá mais.

Quais os problemas encontrados?

Em um dos testes mesmo seguindo todos os passos, ainda assim o AG não voltou a sincronização, nos logs a informação é que não poderia sincronizar, porém não especificava o motivo. Provavelmente, durante a cópia, os nós perderam o LSN da sincronização. Neste caso a alternativa é tirar o banco do AG e incluir novamente, o que implicaria em fazer um backup full, de um log e copiar os backups de um nó para outro. No caso do cliente os nós estão em regiões geográficas diferentes e sendo um banco grande (muitos terabytes) seu backup full também é o que dificulta o processo de reconfiguração do AG.

Segundo tópico:

Criar um arquivo de dados novo para o banco de dados é bem tranquilo no AG, quando um novo arquivo é criado o AG sincroniza através dos nós automaticamente.

Entretanto, se na configuração dos SQL Server participantes do AG o parâmetro de unidade padrão estiverem diferentes o AG irá criar um arquivo de dados nos nós secundários conforme as configurações dos do caminho padrão das instâncias. Um exemplo disto é se no nó principal as unidades D: e L: correspondem a dados e log respectivamente, e no nó secundário as unidades são E: e G: o novo arquivo de dados no nó principal será criado no D: e nó Secundário no E:

O melhor cenário é ter em ambos os nós as mesmas unidades configuradas assim a alocação será natural. Mas, também podemos revisar antes da atividade e ajustar os caminhos conforme a movimentação.

Terceiro tópico:

Esta é uma questão que depois do teste fez sentido e percebemos que nem precisava ter feito o teste, mas valeu pela experiência.

E a resposta para a pergunta é NÃO, não tem como fazer uma replicação transacional a partir do nó secundário do AG.

“Mesmo que o nó secundário esteja como somente leitura?”

Mesmo assim, porque na replicação transacional o SQL Server utiliza marcações no Log de transação para controlar a replicação e isso implica em ter permissão de gravação no banco, mesmo que seja somente no log de transações.

“Mas por que não adicionar somente mais um nó no AG e utilizar este terceiro nó como leitura?”

Foi cogitada a replicação transacional porque esta réplica seria utilizada somente para leituras de integrações para cargas de DW e BI, sendo assim não precisaríamos replicar todo o banco de dados, ou seja, a réplica seria somente das tabelas necessárias para as integrações e ainda poderíamos aplicar filtros de data para pegar somente os últimos registros das tabelas.

“E por que não criar a réplica a partir do nó primário?”

Porque isso implicaria em mais uma leitura competindo com os recursos do ERP.

Por hoje era isso pessoal e espero que tenhamos ajudado vocês com estas informações.

Até a próxima!