Por que uma VPN rápida ainda atrasa uma confirmação SQL síncrona

Abra uma sessão de consulta no primário e observe o que uma escrita simples espera. Se o banco de dados pertence a um grupo de disponibilidade com confirmação síncrona e a secundária está conectada, parte dessa espera sai do edifício: os registros do log viajam para a réplica, são endurecidos lá, e a notícia desse endurecimento volta antes que a confirmação termine. A largura de banda não encurta essa viagem de ida e volta. O percurso abaixo segue o reconhecimento da tela até o disco remoto e de volta.

Comece pelo tipo de espera no primário

Uma escrita que espera na réplica remota aparece como uma espera relacionada ao log em vez de uma espera de CPU ou de bloqueio, e a duração da transação segue a viagem de ida e volta em vez do número de linhas. Muitas confirmações pequenas tornam isso evidente, porque cada uma paga a viagem separadamente. Uma única operação em massa esconde o mesmo custo dentro de um reconhecimento mais longo.

Ordene sua carga de trabalho por frequência de confirmação antes de concluir qualquer coisa sobre o enlace.

Leia o estado da réplica antes de ler a rede. Os contadores que importam são a fila de envio, a fila de redo e o estado de sincronização, e juntos mostram se a secundária acompanha ou fica para trás. Uma fila de envio crescente aponta para o transporte, enquanto uma fila de redo crescente aponta para o trabalho ou o armazenamento da própria secundária. São reparos diferentes, e nenhum melhora adicionando largura de banda.

Siga o reconhecimento até a secundária

Com confirmação síncrona, o primário espera a confirmação de que o log em questão foi endurecido na secundária antes de informar que a confirmação terminou. Endurecido significa durável no log, não reproduzido nas páginas de dados. Essa distinção é exatamente a razão pela qual uma secundária síncrona pode ficar atrás no redo enquanto ainda confirma o endurecimento.

Percorra o caminho em ordem e meça cada etapa em vez do conjunto. Os registros do log passam pelo transporte, a secundária os escreve e os descarrega, e o reconhecimento volta pelo mesmo caminho. O atraso do transporte, o agendamento da secundária e a latência do disco de log da secundária entram todos no total, e só o primeiro pertence ao dono da rede. Uma secundária cujo volume de log está saturado por outra coisa pode esticar cada confirmação enquanto o enlace fica ocioso.

SELECT ag.name AS ag_name, drs.database_id, drs.synchronization_state_desc,
       drs.log_send_queue_size, drs.redo_queue_size
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_groups AS ag ON ag.group_id = drs.group_id;

Tire essa fotografia antes e depois de uma escrita representativa em vez de uma vez numa tarde tranquila. A diferença é o que lhe diz qual fila se moveu enquanto a confirmação esperava.

Meça o caminho, não o enlace

Um teste de taxa de transferência mede a capacidade entre dois pontos que não são suas réplicas, sob uma carga que não é o seu trabalho. Peça ao dono da rede o atraso e a perda ao longo do caminho real da réplica enquanto o tráfego real corre, nos dois sentidos. A perda importa mais que a capacidade aqui, porque um segmento perdido custa uma retransmissão e toda confirmação espera um reconhecimento. Um enlace que parece excelente num teste de download ainda pode ser inadequado para um padrão de confirmações muito falante.

Mantenha intactas a segurança do transporte do banco de dados e os controles de acesso enquanto mede. Medir um caminho nunca é razão para contorná-los.

Correlacione os tempos com os contadores em vez de com a intuição. Se a fila de envio continua vazia e a confirmação ainda espera, o atraso está no reconhecimento ou na descarga da secundária. Se a fila de envio cresce de forma constante, o transporte ou a capacidade é a restrição. Anote qual observação sustentou a conclusão para que a próxima pessoa possa repetir a medição em vez da discussão.

O que o modo assíncrono realmente muda

A confirmação assíncrona remove a espera pelo reconhecimento de endurecimento da secundária, e é por isso que as escritas ficam mais rápidas e por isso que sua posição de durabilidade muda. O primário confirma a transação sem esse reconhecimento remoto. A secundária então pode ficar para trás, e esse atraso é a exposição.

Se o primário for perdido antes que o log alcance um alvo de comutação por falha utilizável, forçar o serviço nessa réplica descarta transações que o aplicativo já havia sido informado como confirmadas.

É uma decisão de ponto de recuperação e pertence ao dono do banco de dados, não a uma revisão de desempenho. Defina primeiro a janela de perda de dados tolerada, escolha o modo que a satisfaz e depois otimize dentro desse limite. As opções que mantêm a proteção síncrona incluem remover as viagens de confirmação evitáveis onde o aplicativo o permite, corrigir um gargalo medido de transporte ou armazenamento, e mover a réplica para que o reconhecimento percorra menos distância. Pese-as contra o requisito de durabilidade com o qual você começou, que não mudou.