[SQL Server AlwaysOn AG] Required Synchronized Secondaries To Commit


O SQL Server 2017 trouxe uma novidade interessante para o AlwaysOn Availability Groups (AG); hoje vamos falar sobre a opção: Required_Synchronized_Secondaries_To_Commit.

Pra entender o papel desta nova opção é importante entender como o AG se comporta quando está configurado para operar no modo síncrono.

Para facilitar a nossa “prosa” vamos considerar que temos um AG com duas réplicas: "X" e "Y". Essas réplicas estão operando em modo síncrono e com failover automático habilitado. Vamos considerar também que nosso cluster está com seu witness quorum devidamente configurado.

A réplica X é nossa réplica primária, nela ocorrem escritas e leituras. A réplica Y é nossa réplica secundária, se uma falha ocorrer na réplica X é esperado que a réplica Y assuma automaticamente. Como essas réplicas estão operando em modo síncrono, toda modificação realizada na réplica X só será confirmada (comitada) quando esta modificação também for registrada no t-log da réplica secundária. Em geral réplicas síncronas operam com o status “SINCRONIZED” (sincronizado).

 

Agora, o que acontece se a réplica secundária (Y) for desligada?

Como o cluster está com o witness quorum devidamente configurado, por padrão a réplica X continuará operando normalmente, atendendo o workload de escrita e leitura. Toda modificação efetuada nesse período ficará em uma fila na réplica primária até que a réplica secundária retorne.

Quando a réplica secundária retornar, ela solicitará à réplica primária todas as modificações que ocorreram durante o período que ela ficou offline. Se essa fila for grande, a réplica secundária poderá demorar algum tempo para voltar a ficar 100% sincronizada com a réplica primária e durante esse período ela operará com o status “SINCRONIZING” (sincronizando).

Se neste período a réplica primária falhar, não teremos failover automático para a réplica Y, pois como ela estava com a sincronização atrasada, não seria seguro que ela assumisse automaticamente. Nesse cenário teríamos 2 opções: “ressuscitar” nossa réplica X ou fazer um forced failover para a réplica Y para que ela assumisse o papel de réplica primária, porém, como ela estava atrasada, inevitalmente perderíamos dados nesse processo.

 

Como evitar que isso aconteça?

É aí que entra a nova opção Required_Synchronized_Secondaries_To_Commit.

Nessa opção definimos quantas réplicas síncronas precisam persistir a transação para que esta seja confirmada na réplica primária.

Se habilitarmos esta opção em nosso AG fictício, quando a réplica secundária (Y) for desligada, nenhuma nova transação ocorrerá na réplica primária. Todas as conexões na réplica primária serão encerradas e nenhuma nova conexão será estabelecida (nos bancos que fazem parte do AG) até que a réplica secundária retorne… e não somente retorne, mas que retorne ao estado SINCRONIZED (sincronizado). A seguir temos alguns exemplos de mensagens de erros que podemos encontrar nessa situação:

Remote harden of transaction 'INSERT' (ID 0x000000000002c92f 0000:000015ea) started at Jun  5 2018 12:06PM 
in database 'AdventureWorks2014' at LSN (48:944:3) failed.

 

Msg 988, Level 14, State 1, Line 8
Unable to access database 'AdventureWorks2014' because it lacks a quorum of nodes for high availability.
Try the operation again later.

Essa nova opção aumenta a segurança das transações, mas também aumenta a importância das réplicas secundárias síncronas, portanto é importante garantir que a infraestrutura das réplicas esteja adequada para trabalhar neste modelo (com atenção especial na latência de disco e rede).

Esta opção é uma propriedade do AG e pode ser habilitada/desabilitada a qualquer momento, sem a necessidade de reiniciar o SQL Server.

Referências adicionais

ALTER AVAILABILITY GROUP

Até +

Silas Mendes

 

============================
The code and techniques described in this blog are presented to the reader ‘as is’, without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by any of the authors or Microsoft. Further, the authors shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. Your use of the information contained in these pages, is at your sole risk.
Comments (0)

Skip to main content