Eu tenho um AlwaysON AG com uma réplica primária e uma secundária no modo de confirmação síncrona. Todos os bancos de dados no AG têm crescimento automático desabilitado (política padrão dentro da organização). Há uma manutenção de hardware planejada no servidor que hospeda a réplica secundária que fará com que o servidor fique offline por 4 a 8 horas. Meu entendimento é que, quando isso acontecer, o estado conectado da réplica secundária mudará para DISCONNECTED, a fila de envio dos bancos de dados na réplica primária acumulará registros de log de transações não enviados. Enquanto a réplica secundária permanecer offline, todos os registros de log atuais permanecerão ativos (o crescimento automático está desabilitado), os backups de log de transações não truncarão o log com o potencial de preenchimento do log. Alguém por favor pode confirmar se isso está correto? Existe alguma maneira de mitigar isso, ie.
Esse foi o meu entendimento, mas depois de ler este artigo msdn https://msdn.microsoft.com/en-us/library/ff877931%28v=sql.110%29.aspx?f=255&MSPPError=-2147217396 Estou confuso. Há uma observação que afirma: "Se o período de tempo limite da sessão primária for excedido por uma réplica secundária, a réplica primária mudará temporariamente para o modo de confirmação assíncrona para essa réplica secundária. modo de confirmação."
Isso se aplica à minha situação descrita acima e, em caso afirmativo, isso significa que o potencial de preenchimento da transação é mitigado por design? Essa mudança temporária no modo de confirmação pode ser vista ao consultar sys.availabilty_replicas ou por meio de qualquer evento estendido ou é uma mudança puramente oculta?
Sim, você está 100% correto!
A mitigação não é com o modo que as réplicas a executam, é removendo essa réplica do AG.
Sim, isso é o que acontecerá se você não mudar nada. Não, o log de transações ainda será preenchido. Independentemente dos modos síncrono ou assíncrono, o primário deve manter todos os blocos de log necessários para a réplica mais atrasada.
Em seu cenário, há apenas duas réplicas, uma primária e uma secundária. O secundário ficará offline por um tempo. Você já disse corretamente o que vai acontecer, a fila de envio vai aumentar conforme a réplica estiver offline e assim permanecer. Isso acontece independentemente do modo.
A mitigação é remover a réplica que ficará inativa por um longo período de tempo. Isso permite que o primário trunque corretamente o log com backups de log de transação adequados.
Depois que o secundário estiver de volta, desde que foi expulso do AG, todos os bancos de dados participantes desse AG estarão em um estado de restauração. Para voltar a um bom estado estável e trazer a réplica de volta para o AG, pegue os backups de log que foram executados durante o período em que a réplica secundária estava off-line e aplique-os aos bancos de dados, deixando-os em estado de restauração (sem recuperação) . Quando chegar perto, pause todos os backups de log de transação no primário e junte a réplica de volta ao AG. Retome os backups de log no primário.