Поделиться через

Устранение неполадок: возможная потеря данных для реплик групп доступности с асинхронной фиксацией

  • Статья

Область применения: SQL Server

После выполнения принудительного перехода на другой ресурс вручную для группы доступности на вторичной реплике с асинхронной фиксацией вы можете обнаружить, что потери данных превышают целевую точку восстановления (RPO). Или при вычислении возможной потери данных для вторичной реплики с асинхронной фиксацией с использованием метода, описанного в разделе Мониторинг производительности для групп доступности AlwaysOn, вы обнаруживаете, что она превышает RPO.

Вторичная реплика с синхронной фиксацией гарантирует нулевую потерю данных, однако возможная потеря данных для вторичной реплики с асинхронной фиксацией зависит от того, какой объем журнала все еще ожидает сохранения на вторичной реплике.

Следующие разделы описывают распространенные причины для высокого уровня возможной потери данных вторичной реплики с асинхронной фиксацией, при условии, что у вас нет общесистемной проблемы с производительностью в экземпляре сервера, который не связан с группами доступности.

  1. Большая задержка в сети или низкая пропускная способность сети вызывает накопление журнала на первичной реплике

  2. Узкое место дисковых операций ввода-вывода замедляет сохранение журналов на вторичной реплике

Большая задержка в сети или низкая пропускная способность сети вызывает накопление журнала на первичной реплике

Самая распространенная причина превышения RPO для баз данных заключается в том, что их невозможно достаточно быстро отправить на вторичную реплику.

Описание

Первичная реплика активирует управление потоком для отправки журнала, когда превышено максимальное допустимое число неподтвержденных сообщений, передаваемых на вторичную реплику. Пока некоторые из этих сообщений не будут подтверждены, на вторичную реплику невозможно отправить дополнительные блоки журнала. Так как потерю данных можно предотвратить только в том случае, если сообщения были сохранены на вторичной реплике, накопление неотправленных сообщений журнала повышает возможную потерю данных.

Диагностика и способ устранения

Большое число сообщений, повторно отправляемых на вторичную реплику, может указывать на большую задержку в сети и высокий уровень шума. Вы также можете сравнить значение динамического административного представления log_send_rate с объектом производительности "Сброшено байтов журнала в секунду". Если журналы записываются на диск быстрее, чем отправляются, возможная потеря данных может увеличиваться бесконечно.

Кроме того, полезно проверить два объекта производительности — SQL Server:Availability Replica > Flow Control Time (ms/sec) и SQL Server:Availability Replica > Flow Control/sec. Умножив эти два значения, можно узнать, сколько времени за последнюю секунду ушло на ожидание очистки управления потоком. Чем больше время ожидания управления потоком, тем ниже скорость отправки.

Приведенные ниже метрики полезны при диагностике задержки в сети и пропускной способности. Для оценки задержки и использования сети можно применять другие средства Windows, например ping.exe и сетевой монитор.

  • Динамическое административное представление sys.dm_hadr_database_replica_states, log_send_queue_size

  • Динамическое административное представление sys.dm_hadr_database_replica_states, log_send_rate

  • Счетчик производительности SQL Server:Database > Log Bytes Flushed/sec

  • Счетчик производительности SQL Server:Database Mirroring > Send/Receive Ack Time

  • Счетчик производительности SQL Server:Availability Replica > Bytes Sent to Replica/sec

  • Счетчик производительности SQL Server:Availability Replica > Bytes Sent to Transport/sec

  • Счетчик производительности SQL Server:Availability Replica > Flow Control Time (ms/sec)

  • Счетчик производительности SQL Server:Availability Replica > Flow Control/sec

  • Счетчик производительности SQL Server:Availability Replica > Resent Messages/sec

Чтобы устранить эту проблему, попробуйте повысить пропускную способность сети либо устранить или снизить ненужный сетевой трафик.

Узкое место дисковых операций ввода-вывода замедляет сохранение журналов на вторичной реплике

В зависимости от развертывания файла базы данных сохранение журнала может замедлить работу из-за состязания операций ввода-вывода с рабочей нагрузкой отчетов.

Описание

Потеря данных предотвращается сразу после записи блока журнала в файл журнала. Поэтому важно изолировать файл журнала от файла данных. Если файл журнала и файл данных сопоставлены с одним жестким диском, рабочая нагрузка отчетов с большим объемом операций, считывающих файл данных, будет потреблять те же ресурсы ввода-вывода, необходимые для сохранения журнала. Медленное сохранение журнала может замедлить подтверждение первичной реплики, что может привести к чрезмерной активации и длительному ожиданию управления потоком.

Диагностика и способ устранения

Если вы убедились, что в сети не наблюдаются высокая задержка или низкая пропускная способность, следует изучить вторичную реплику на наличие состязаний ввода-вывода. Запросы из статьи SQL Server: минимизация дискового ввода/вывода полезны для обнаружения конфликтов. Для удобства ниже представлены примеры из этой статьи.

Приведенный ниже скрипт позволяет просмотреть количество операций чтения и записи в каждом файле данных и журнала для каждой базы данных доступности, запущенной на экземпляре SQL Server. Он сортируется по среднему времени простоя ввода-вывода в миллисекундах. Обратите внимание, что эти значения накапливаются с момента последнего запуска экземпляра сервера. Поэтому нужно использовать разницу между двумя измерениями по истечении некоторого времени.

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;

Приведенный ниже запрос предоставляет моментальный снимок ожидающих запросов ввода-вывода в системе на определенный момент времени (не накопительный).

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;

Вы можете сравнить операции чтения и записи ввода-вывода, чтобы определить состязание ввода-вывода.

Ниже приведены некоторые другие счетчики производительности, которые могут помочь выявить узкие места ввода-вывода.

  • Физический диск: все счетчики

  • Физический диск: среднее время обращения к диску (с)

  • SQL Server: Базы данных > Время ожидания сброса журнала

  • SQL Server: Базы данных > Ожиданий сброса журнала в секунду

  • SQL Server: Базы данных > Операций чтения диска пула журнала в секунду

Если вы обнаруживаете узкое место ввода-вывода и поместили файл журнала и файл данных на одном жестком диске, прежде всего следует разнести эти файлы по разным дискам. Эта рекомендация предотвращает влияние рабочей нагрузки отчетов на путь передачи журнала из первичной реплики в буфер журнала, а также на возможность сохранения транзакции на вторичной реплике.

Следующие шаги

Устранение проблем с производительностью в SQL Server (применяется к SQL Server 2012)