Resolução de problemas: Potencial perda de dados com réplicas de grupos de disponibilidade de consolidação assíncrona

Aplica-se a: SQL Server

Depois de efetuar uma ativação pós-falha manual forçada num grupo de disponibilidade para uma réplica secundária de confirmação assíncrona, poderá verificar que a perda de dados é superior ao seu objetivo de ponto de recuperação (RPO). Ou, quando calcula a perda potencial de dados de uma réplica secundária de commit assíncrono usando o método em Monitor Performance for Always On Availability Groups, verifica que ela excede o seu RPO.

Uma réplica secundária de consolidação síncrona garante perda de dados nula, mas a perda potencial de dados de uma réplica secundária de consolidação assíncrona depende da quantidade de registo que ainda está à espera de ser escrita em disco na réplica secundária.

As secções seguintes descrevem as causas comuns de elevada perda potencial de dados numa réplica secundária com confirmação assíncrona, partindo do pressuposto de que não existe um problema sistémico de desempenho na instância do servidor que não esteja relacionado com os grupos de disponibilidade.

  1. A elevada latência da rede ou a baixa largura de banda da rede causam a acumulação de registos na réplica primária

  2. O gargalo de E/S do disco atrasa a consolidação do registo na réplica secundária

A elevada latência da rede ou a baixa taxa de transferência da rede causam acumulação de registos na réplica primária

A razão mais comum para as bases de dados excederem o seu RPO é que não podem ser enviadas para a réplica secundária suficientemente rapidamente.

Explanation

A réplica primária ativa o controlo de fluxo no envio do log quando ultrapassa o número máximo permitido de mensagens não confirmadas enviadas para a réplica secundária. Até que algumas destas mensagens sejam reconhecidas, não podem ser enviados mais blocos de log para a réplica secundária. Como a perda de dados só pode ser evitada quando forem reforçadas na réplica secundária, o acumular de mensagens de registo não enviadas aumenta a potencial perda de dados.

Diagnóstico e resolução

Um número elevado de mensagens reenviadas para a réplica secundária pode indicar alta latência e ruído de rede. Também pode comparar o valor do DMV log_send_rate com o objeto de desempenho Log Bytes Flushed/seg. Se os registos estiverem a ser esvaziados para o disco mais rapidamente do que enviados, a perda potencial de dados pode aumentar indefinidamente.

Além disso, é útil verificar os dois objetos SQL Server:Availability Replica > Flow Control Time (ms/sec) de desempenho e SQL Server:Availability Replica > Flow Control/sec. Multiplicar estes dois valores mostra-te, no último segundo, quanto tempo foi gasto à espera que o controlo de fluxo fosse liberado. Quanto maior for o tempo de espera no controlo de fluxo, menor será a taxa de envio.

As métricas seguintes são úteis para o diagnóstico da latência e do débito da rede. Pode usar outras ferramentas de Windows, como ping.exe e Network Monitor, para avaliar a latência e a utilização da rede.

  • DMV sys.dm_hadr_database_replica_states, log_send_queue_size

  • DMV sys.dm_hadr_database_replica_states, log_send_rate

  • Contador de desempenho SQL Server:Database > Log Bytes Flushed/sec

  • Contador de desempenho SQL Server:Database Mirroring > Send/Receive Ack Time

  • Contador de desempenho SQL Server:Availability Replica > Bytes Sent to Replica/sec

  • Contador de desempenho SQL Server:Availability Replica > Bytes Sent to Transport/sec

  • Contador de desempenho SQL Server:Availability Replica > Flow Control Time (ms/sec)

  • Contador de desempenho SQL Server:Availability Replica > Flow Control/sec

  • Contador de desempenho SQL Server:Availability Replica > Resent Messages/sec

Para resolver este problema, experimente aumentar a largura de banda da sua rede ou remover ou reduzir o tráfego desnecessário.

O gargalo de I/O do disco abranda o endurecimento logarítmico na réplica secundária

Dependendo da implementação do ficheiro da base de dados, o endurecimento dos logs pode abrandar devido à contenção de I/O com a carga de trabalho dos relatórios.

Explanation

A perda de dados é evitada assim que o bloco de registo é gravado de forma persistente no ficheiro de registo. Por isso, é fundamental isolar o ficheiro de registo do ficheiro de dados. Se o ficheiro de registo e o ficheiro de dados estiverem ambos mapeados para o mesmo disco rígido, uma carga de trabalho de relatórios com leituras intensivas no ficheiro de dados consumirá os mesmos recursos de E/S necessários para a operação de consolidação do registo. O endurecimento lento do tronco pode traduzir-se num reconhecimento lento da réplica primária, o que pode causar ativação excessiva do controlo de fluxo e longos tempos de espera no controlo de fluxo.

Diagnóstico e resolução

Se verificou que a rede não apresenta latência elevada nem baixa taxa de transferência, então deve investigar se existem contenções de E/S na réplica secundária. Consultas de SQL Server: Minimizar a E/S de disco são úteis para identificar contenções. Exemplos desse artigo são retirados abaixo para sua conveniência.

O script seguinte permite-lhe ver o número de leituras e escritas em cada ficheiro de dados e log para cada base de dados de disponibilidade a correr numa instância do SQL Server. Está ordenado pelo tempo médio de espera de E/S, em milissegundos. Note que os números são cumulativos desde a última vez que a instância do servidor foi iniciada. Por isso, deve calcular a diferença entre duas medições depois de decorrido algum tempo.

SELECT DB_NAME(database_id) AS   
   [Database Name] ,   
   file_id ,   
   io_stall_read_ms ,   
   num_of_reads ,   
   CAST(io_stall_read_ms / ( 1.0 + num_of_reads ) AS NUMERIC(10, 1)) AS [avg_read_stall_ms] ,   
   io_stall_write_ms ,   
   num_of_writes ,  
   CAST(io_stall_write_ms / ( 1.0 + num_of_writes ) AS NUMERIC(10, 1)) AS [avg_write_stall_ms] ,   
   io_stall_read_ms + io_stall_write_ms AS [io_stalls] ,   
   num_of_reads + num_of_writes AS [total_io] ,   
   CAST(( io_stall_read_ms + io_stall_write_ms ) / ( 1.0 + num_of_reads  
+ num_of_writes) AS NUMERIC(10,1)) AS [avg_io_stall_ms]  
FROM sys.dm_io_virtual_file_stats(NULL, NULL)  
WHERE DB_NAME(database_id) IN (SELECT DISTINCT database_name FROM sys.dm_hadr_database_replica_cluster_states)  
ORDER BY avg_io_stall_ms DESC;

A consulta seguinte fornece um instantâneo momentâneo (não cumulativo) das operações de E/S pendentes no seu sistema.

SELECT DB_NAME(mf.database_id) AS [Database] ,   
   mf.physical_name ,  
   r.io_pending ,   
   r.io_pending_ms_ticks ,   
   r.io_type ,   
   fs.num_of_reads ,   
   fs.num_of_writes  
FROM sys.dm_io_pending_io_requests AS r   
INNER JOIN sys.dm_io_virtual_file_stats(NULL, NULL) AS fs ON r.io_handle = fs.file_handle   
INNER JOIN sys.master_files AS mf ON fs.database_id = mf.database_id  
AND fs.file_id = mf.file_id  
ORDER BY r.io_pending , r.io_pending_ms_ticks DESC;

Pode comparar como as E/S de leitura e de escrita se comparam entre si para identificar contenção de E/S.

A seguir estão outros contadores de desempenho que podem ajudar a diagnosticar estrangulamentos de I/O:

  • Disco físico: todos os contadores

  • Disco Físico: Sec. média do disco/Transferência

  • SQL Server: Bases de Dados > Tempo de Espera para Escrita do Registo

  • SQL Server: Bases de Dados > Esperas de descarga do registo/segundo

  • SQL Server: Bases de > Dados Leituras do disco do Log Pool/seg

Se identificar um gargalo de E/S e colocar o ficheiro de registo e o ficheiro de dados no mesmo disco rígido, a primeira coisa que deve fazer é colocar o ficheiro de dados e o ficheiro de registo em discos separados. Esta melhor prática impede que a carga de trabalho de reporte interfira com o caminho de transferência de logs da réplica primária para o log buffer e com a sua capacidade de reforçar a transação na réplica secundária.

Conteúdo relacionado

  • Last updated on