[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