Escolha uma Página

SQL Server e suas versões

Um banco de dados em AG pode estar off-line, e mesmo assim, a instância pode permanecer ativa e operacional no cluster. No SQL Server 2014 e em versões anteriores, o failover não seria acionado porque o estado geral da instância ainda está “up”.

No SQL Server 2016, todos os bancos de dados dentro da AG afetada falham. Esse comportamento é opcional, logo por padrão, ele não será ativado. Para ter esse padrão, o administrador precisará habitar a diretiva.

Como o DTC (Microsoft Distributed Transaction Control) faz parte do sistema operacional Windows, a Microsoft fez modificações no Windows Server 2016 e na API, para que o SQL Server 2016 possa apoiá-lo completamente. Portanto, sua instância do SQL Server 2016 deve residir em um sistema operacional Windows Server 2016 para que o DTC seja suportado. Isso também será suportado no Windows Server 2012 Release 2, assim que o pacote KB3090973 estiver instalado.

Réplicas Síncronas

Existem dois tipos de réplicas secundárias dentro de um AG: assíncrona e síncrona. Com a replicação síncrona, a transação deve ser registrada no log da réplica antes que ela possa enviar uma confirmação (acknowledgement) para a réplica primária. Para que uma réplica secundária seja um destino de failover automático, ela deve ser uma réplica síncrona.

No SQL Server 2014, podem haver três réplicas síncronas, mas apenas duas delas podem ser designadas como alvos de failover automáticos. Isso significa que essas duas réplicas síncronas seriam o principal alvo de failover de uma para a outra. No SQL Server 2016, todas as três réplicas síncronas agora podem ser designadas como destinos de failover. Como resultado, se um problema ocorrer durante, ou mesmo após um failover, a terceira réplica síncrona também poderia participar como um destino de failover.

Transporte de log otimizado

A comunicação síncrona dos dados de log entre réplicas pode ser problemática em ambientes com muita transferência de dados. A medida que o tempo avança e a latência do processo de confirmação síncrona aumenta, o desempenho do primário é afetado.

A Microsoft simplificou o pipeline entre as réplicas síncronas para obter melhor taxa de transferência de dados de log do AlwaysOn. Contudo, se o throughput for muito rápido, haverá mais atividades de “redo” a serem processadas ao replicar registros de log para recuperação de banco de dados.

Portanto, a Microsoft também está trabalhando para permitir que a operação de “redo” se torne paralela. Ao invés de melhorar o percentual sobre a taxa de transferência no SQL Server 2014 para o 2016, o comportamento estará mais próximo de uma instância standalone em termos de throughput.

Load balancing em réplicas secundárias configuradas para leitura:

No SQL Server 2014, o uso do AG Listener para direcionar leituras a réplicas secundárias é suportado por meio da lista de roteamento. Mas a primeira réplica da lista obtém mais atividade porque sempre é tentada primeiro.

Gráfico com réplica primária e secundária do sql server

Há muitas mudanças vindo por aí! Em breve, vamos mostrar um hands-on sobre Load Balancing. Até a próxima!

Quer receber as novidades de e-commerce em primeira mão?

x