Мониторинг производительности для групп доступности Always On
Область применения:
SQL Server
Аспект производительности групп доступности AlwaysOn играет важную роль с точки зрения соблюдения соглашения об уровне обслуживания (SLA) для критически важных баз данных. Понимание того, как группа доступности передает журналы вторичным репликам, может помочь оценить цель времени восстановления (RTO) и целевую точку восстановления (RPO) для вашей системы доступности, а также выявить узкие места в малоэффективных группах доступности или репликах. Эта статья описывает процесс синхронизации, показывает, как вычислить некоторые основные метрики, а также содержит ссылки на некоторые распространенные сценарии по устранению неполадок с производительностью.
Процесс синхронизации данных
Чтобы оценить время полной синхронизации и выявить узкое место, вам нужно понять процесс синхронизации. Узкое место в производительности может находиться в любом месте процесса, и его обнаружение может помочь вам лучше разобраться в связанных с ним проблемах. Приведенные ниже рисунок и таблица иллюстрируют процесс синхронизации данных:
| Последовательность | Описание шага | Комментарии | Полезные метрики |
|---|---|---|---|
| 1 | Создание логов | Данные журнала записываются на диск. Этот журнал должен быть скопирован на вторичные копии. Записи журнала попадают в очередь отправки. | SQL Server: база данных > выгружено байтов журнала в секунду |
| 2 | Capture | Логи для каждой базы данных собираются и отправляются в соответствующую партнерскую очередь (одна на каждую пару база данных-реплика). Этот процесс сбора выполняется непрерывно, пока реплика доступности подключена и перемещение данных не приостановлено по любой причине, а пара база данных-реплика отображается как синхронизирующаяся или синхронизированная. Если процессу сбора не удается достаточно быстро сканировать сообщения и ставить их в очередь, очередь отправки журнала разрастается. |
SQL Server: Группа доступности > байты, отправленные в реплику в секунду, что является агрегированием суммы всех сообщений баз данных, поставленных в очередь для этой группы доступности. log_send_queue_size (КБ) и log_bytes_send_rate (КБ/с) на первичной реплике. |
| 3 | Отправить | Сообщения в каждой очереди базы данных и реплики удаляются из очереди и через проводную сеть передаются в соответствующую вторичную реплику. | SQL Server: реплика доступности > отправлено байт в транспортировку в секунду |
| 4 | Получение и кэширование | Каждая вторичная реплика получает и кэширует сообщение. | Счетчик производительности SQL Server: Реплика доступности > Байты журнала, полученные в секунду |
| 5 | Сохранение | Журнал записывается во вторичную реплику для сохранения. После очистки журнала отправляется подтверждение обратно в первичную реплику. После укрепления журнала потеря данных избегается. |
Счетчик производительности SQL Server: База данных > Записанные байты журнала в секунду Тип ожидания HADR_LOGCAPTURE_SYNC |
| 6 | Переделать | Повторная обработка записанных страниц на вторичной реплике. Страницы хранятся в очереди перезаписи, пока ожидают повторной обработки. |
SQL Server: реплика базы данных > восстановленные байты в секунду redo_queue_size (КБ) и redo_rate. Тип ожидания REDO_SYNC |
Шлюзы управления потоком
Для групп доступности предусмотрены шлюзы управления потоком на первичной реплике, позволяющие предотвратить чрезмерное потребление ресурсов, например сетевых ресурсов и ресурсов памяти, на всех репликах доступности. Эти шлюзы управления потоком не влияют на состояние работоспособности синхронизации у реплик доступности, но могут повлиять на общую производительность баз данных доступности, включая RPO.
После записи журналов на первичной реплике они подвергаются двум уровням элементов управления потоками. После достижения порога сообщений для любого из шлюзов сообщения журнала перестают отправляться в конкретную реплику или базу данных. Отправка сообщений возможна после получения подтверждений для отправленных сообщений, в результате чего число отправленных сообщений опускается ниже порогового значения.
Кроме шлюзов управления потоком существует и другой фактор, который может препятствовать отправке сообщений журнала. Синхронизация реплик гарантирует, что сообщения отправляются и применяются в порядке последовательности номеров журнала (LSN). Перед отправкой сообщения журнала его номер LSN также проверяется на соответствие с наименьшим подтвержденным номером LSN, чтобы убедиться, что он меньше одного из пороговых значений (в зависимости от типа сообщения). Если разрыв между двумя номерами LSN больше порогового значения, сообщения не отправляются. Когда разрыв меньше порогового значения, сообщения отправляются.
SQL Server 2022 увеличивает ограничения на количество сообщений, разрешенных каждым шлюзом. Использование флага трассировки 12310 также делает увеличенный предел доступным для следующих версий SQL Server, начиная с: SQL Server 2019 CU9, SQL Server 2017 CU18 и SQL Server 2016 SP1 CU16.
В следующей таблице сравниваются ограничения сообщений:
SQL Server 2022 и поддерживаемые версии SQL Server (начиная с SQL Server 2019 CU9, SQL Server 2017 CU18 и SQL Server 2016 с пакетом обновления 1 (SP1) с накопительным пакетом обновления 16 (CU16)), которые включают флаг трассировки 12310, на них распространяются следующие ограничения:
| Уровень | Количество шлюзов | Количество сообщений | Полезные метрики |
|---|---|---|---|
| Транспорт | 1 на копию доступности | 16384 | Расширенное событие database_transport_flow_control_action |
| База данных | 1 на базу данных доступности | 7168 |
DBMIRROR_SEND Расширенное событие hadron_database_flow_control_action |
Два полезных счетчика производительности — SQL Server: реплика доступности > поток управления в секунду и SQL Server: реплика доступности > время управления потоком (мс/с) — показывают, сколько раз активировалось управление потоком и сколько времени ушло на ожидание управления потоком за последнюю секунду. Более длительное время ожидания управления потоком приводит к увеличению RPO. Дополнительные сведения о типах проблем, которые могут привести к длительному времени ожидания в управлении потоком, см. в разделе Устранение неполадок: превышение RPO в группе доступности.
Оценка времени переключения (RTO)
RTO в вашем соглашении об уровне обслуживания зависит от времени переключения на резервный ресурс в рамках реализации вашей системы AlwaysOn в любой момент, что можно выразить следующей формулой:
Внимание
Если группа доступности содержит более одной базы данных доступности, то база данных доступности с наибольшим значением Tfailover становится ограничивающим фактором для соблюдения RTO.
Время обнаружения ошибки Tdetection — это время, необходимое системе для обнаружения сбоя. Это время зависит от параметров на уровне кластера, а не от отдельных реплик доступности. В зависимости от настроенного условия автоматической отказоустойчивости, переход может быть запущен в качестве мгновенного ответа на критическую внутреннюю ошибку SQL Server, такую как осиротевшие спин-блокировки. В этом случае обнаружение может выполняться настолько же быстро, насколько отчет об ошибке sp_server_diagnostics (Transact-SQL) отправляется в кластер WSFC (интервал по умолчанию составляет 1/3 времени ожидания проверки работоспособности). Переключение на резервный ресурс также может запускаться из-за истечения времени ожидания, например, при истечении времени ожидания для проверки работоспособности кластера (по умолчанию 30 секунд) или истечении срока действия аренды между библиотекой ресурсов и экземпляром SQL Server (по умолчанию 20 секунд). В этом случае время обнаружения равно времени ожидания. Дополнительные сведения см. в разделе о гибкой политике автоматического перехода на другой ресурс группы доступности (SQL Server).
Вторичной реплике необходимо лишь дождаться, чтобы журнализация успела дойти до конца журнала для готовности к аварийному переключению. Время повтора — Tredo — рассчитывается по следующей формуле:
где redo_queue — это значение в redo_queue_size, а redo_rate — это значение в redo_rate.
Время задержки при переключении, Toverhead, включает период, необходимый для перехода кластера WSFC на резервный узел и запуска баз данных в сеть. Это время обычно короткое и постоянное.
Оценка возможной потери данных (RPO)
Ваша RPO в соглашении об уровне обслуживания зависит от возможной потери данных при реализации Always On в любой момент времени. Эту возможную потерю данных можно выразить следующей формулой:
где log_send_queue — это значение log_send_queue_size, а скорость создания журнала — это значение SQL Server:Database > байты журнала, сброшенные в секунду.
Предупреждение
Если группа доступности содержит более одной базы данных доступности, то база данных доступности с наибольшим значением Tdata_loss становится ограничивающим фактором для соблюдения RPO.
Очередь на отправку журналов представляет все данные, которые могут быть потеряны при катастрофическом сбое. На первый взгляд, может показаться странным, что используется скорость создания журнала вместо скорости отправки журнала (см. log_send_rate). Однако не забывайте, что использование скорости отправки журнала дает вам лишь время для синхронизации, тогда как RPO измеряет потерю данных на основе скорости их генерации, а не на основе скорости синхронизации.
Еще проще оценить Tdata_loss можно с помощью last_commit_time. Динамическое представление управления на первичной реплике предоставляет это значение для всех реплик. Вы можете вычислить разницу между значением для первичной и вторичной реплик, чтобы оценить, насколько быстро журнал во вторичной реплике синхронизируется с журналом в первичной реплике. Как уже говорилось ранее, этот расчет не показывает возможную потерю данных в зависимости от скорости создания журнала, однако он обеспечивает довольно точное приближение.
Оценка RTO и RPO с помощью панели мониторинга SSMS
В группах доступности AlwaysOn значение RTO и RPO вычисляется и отображается для баз данных, размещенных на вторичных репликах. На панели мониторинга первичной реплики RTO и RPO сгруппированы по вторичной реплике.
Чтобы просмотреть RTO и RPO в панели мониторинга, сделайте следующее.
В SQL Server Management Studio разверните узел Высокий уровень доступности AlwaysOn, щелкните правой кнопкой мыши имя группы доступности и выберите команду Показать панель мониторинга.
Выберите "Добавить/Удалить столбцы" на вкладке "Группировать по". Проверьте как предполагаемое время восстановления (секунды) [RTO], так и предполагаемую потерю данных (время) [RPO].
Расчет RTO вторичной базы данных
Вычисление времени восстановления определяет, сколько времени требуется для восстановления вторичной базы данных после сбоя. Время переключения обычно короткое и постоянное. Время обнаружения зависит от настроек уровня кластера, а не от отдельных реплик доступности.
Для вторичной базы данных (DB_sec) вычисление и отображение RTO основаны на размерах redo_queue_size и redo_rate:
За исключением редких случаев, формула для вычисления RTO вторичной базы данных такова:
Расчет RPO вторичной базы данных
Для базы данных-получателя (DB_sec) вычисление и отображение RPO основаны на значениях is_failover_ready, last_commit_time и коррелированном значении last_commit_time ее базы данных-источника (DB_pri). Если database.is_failover_ready = 1, то данные синхронизированы, и при переключении на резервную базу потери данных не происходит. Если же это значение равно 0, то есть разрыв между last_commit_time базы данных-источника и last_commit_time базы данных-получателя.
Для базы данных-источника last_commit_time — это время, когда зафиксирована последняя транзакция. Для вторичной базы данных last_commit_time — это время последней фиксации транзакции на основной базе данных, которое также успешно закреплено на вторичной базе данных. Это число должно быть одинаковым для обеих баз данных. Разница между этими двумя значениями — это период времени, в течение которого незавершенные транзакции не зафиксированы в базе данных-получателе и будут потеряны в случае перехода.
Счетчики производительности, которые используются в формулах RTO и RPO
- redo_queue_size (КБ) [используется в RTO]: размер очереди повтора — это размер журнала транзакций между его last_received_lsn и last_redone_lsn. Значение last_received_lsn — это идентификатор блока журнала, указывающий точку, до которой все блоки журнала были получены вторичным экземпляром, на котором размещена вторичная база данных. Значение last_redone_lsn — это номер последовательности журнала последней записи журнала, заново обработанной во вторичной базе данных. Исходя из этих двух значений, можно найти идентификаторы начала блока журнала (last_received_lsn) и конечного блока журнала (last_redone_lsn). Расстояние между этими блоками журнала может указывать, какие блоки журнала транзакций еще не были выполнены повторно. Это измеряется в Килобайтах (КБ).
- redo_rate (КБ/с) [используется в RTO]: накопительное значение, показывающее, сколько журнала транзакций (КБ) было перезаписано во вспомогательной базе данных за прошедший период времени в Килобайтах(КБ)/секунду.
- last_commit_time (Datetime) [используется в RPO]: для базы данных-источника last_commit_time — это время, когда зафиксирована последняя транзакция. Для вторичной базы данных last_commit_time — это время последнего фиксации транзакции на основной базе данных, которое было успешно закреплено и на вторичной базе данных. Это значение на вторичном сервере должно быть синхронизировано с тем же значением на первичном сервере, поэтому разница между этими двумя значениями представляет собой оценку потери данных (RPO).
Оценка RTO и RPO с помощью динамических административных представлений
Можно выполнить запросы к динамическим административным представлениям sys.dm_hadr_database_replica_states и sys.dm_hadr_database_replica_cluster_states, чтобы оценить значения RPO и RTO базы данных. Ниже приведены запросы, которые создают хранимые процедуры, выполняющие обе эти задачи.
Примечание.
Убедитесь сначала создать и запустить хранимую процедуру для оценки RTO, так как создаваемые ею значения необходимы для выполнения хранимой процедуры, оценивающей RPO.
Создание хранимой процедуры для оценки RTO
- На целевой вторичной реплике создайте хранимую процедуру proc_calculate_RTO. Если эта хранимая процедура уже существует, сначала удалите и заново создайте ее.
if object_id(N'proc_calculate_RTO', 'p') is not null
drop procedure proc_calculate_RTO
go
raiserror('creating procedure proc_calculate_RTO', 0,1) with nowait
go
--
-- name: proc_calculate_RTO
--
-- description: Calculate RTO of a secondary database.
--
-- parameters: @secondary_database_name nvarchar(max): name of the secondary database.
--
-- security: this is a public interface object.
--
create procedure proc_calculate_RTO
(
@secondary_database_name nvarchar(max)
)
as
begin
declare @db sysname
declare @is_primary_replica bit
declare @is_failover_ready bit
declare @redo_queue_size bigint
declare @redo_rate bigint
declare @replica_id uniqueidentifier
declare @group_database_id uniqueidentifier
declare @group_id uniqueidentifier
declare @RTO float
select
@is_primary_replica = dbr.is_primary_replica,
@is_failover_ready = dbcs.is_failover_ready,
@redo_queue_size = dbr.redo_queue_size,
@redo_rate = dbr.redo_rate,
@replica_id = dbr.replica_id,
@group_database_id = dbr.group_database_id,
@group_id = dbr.group_id
from sys.dm_hadr_database_replica_states dbr join sys.dm_hadr_database_replica_cluster_states dbcs on dbr.replica_id = dbcs.replica_id and
dbr.group_database_id = dbcs.group_database_id where dbcs.database_name = @secondary_database_name
if @is_primary_replica is null or @is_failover_ready is null or @redo_queue_size is null or @replica_id is null or @group_database_id is null or @group_id is null
begin
print 'RTO of Database '+ @secondary_database_name +' is not available'
return
end
else if @is_primary_replica = 1
begin
print 'You are visiting wrong replica';
return
end
if @redo_queue_size = 0
set @RTO = 0
else if @redo_rate is null or @redo_rate = 0
begin
print 'RTO of Database '+ @secondary_database_name +' is not available'
return
end
else
set @RTO = CAST(@redo_queue_size AS float) / @redo_rate
print 'RTO of Database '+ @secondary_database_name +' is ' + convert(varchar, ceiling(@RTO))
print 'group_id of Database '+ @secondary_database_name +' is ' + convert(nvarchar(50), @group_id)
print 'replica_id of Database '+ @secondary_database_name +' is ' + convert(nvarchar(50), @replica_id)
print 'group_database_id of Database '+ @secondary_database_name +' is ' + convert(nvarchar(50), @group_database_id)
end
- Выполните proc_calculate_RTO с указанием имени целевой вторичной базы данных:
exec proc_calculate_RTO @secondary_database_name = N'DB_sec'
Выходные данные содержат значение RTO для вторичной реплики целевой базы данных. Сохраните group_id, replica_id, и group_database_id для использования в хранимой процедуре оценки RPO.
Пример выходных данных:
RTO базы данных DB_sec' — 0
group_id базы данных DB4 — F176DD65-C3EE-4240-BA23-EA615F965C9B
replica_id базы данных DB4 — 405554F6-3FDC-4593-A650-2067F5FABFFD
group_database_id базы данных DB4 — 39F7942F-7B5E-42C5-977D-02E7FFA6C392
Создайте хранимую процедуру для оценки RPO
- На первичной реплике создайте хранимую процедуру proc_calculate_RPO. Если он уже существует, сначала удалите его, а затем пересоздайте.
if object_id(N'proc_calculate_RPO', 'p') is not null
drop procedure proc_calculate_RPO
go
raiserror('creating procedure proc_calculate_RPO', 0,1) with nowait
go
--
-- name: proc_calculate_RPO
--
-- description: Calculate RPO of a secondary database.
--
-- parameters: @group_id uniqueidentifier: group_id of the secondary database.
-- @replica_id uniqueidentifier: replica_id of the secondary database.
-- @group_database_id uniqueidentifier: group_database_id of the secondary database.
--
-- security: this is a public interface object.
--
create procedure proc_calculate_RPO
(
@group_id uniqueidentifier,
@replica_id uniqueidentifier,
@group_database_id uniqueidentifier
)
as
begin
declare @db_name sysname
declare @is_primary_replica bit
declare @is_failover_ready bit
declare @is_local bit
declare @last_commit_time_sec datetime
declare @last_commit_time_pri datetime
declare @RPO nvarchar(max)
-- secondary database's last_commit_time
select
@db_name = dbcs.database_name,
@is_failover_ready = dbcs.is_failover_ready,
@last_commit_time_sec = dbr.last_commit_time
from sys.dm_hadr_database_replica_states dbr join sys.dm_hadr_database_replica_cluster_states dbcs on dbr.replica_id = dbcs.replica_id and
dbr.group_database_id = dbcs.group_database_id where dbr.group_id = @group_id and dbr.replica_id = @replica_id and dbr.group_database_id = @group_database_id
-- correlated primary database's last_commit_time
select
@last_commit_time_pri = dbr.last_commit_time,
@is_local = dbr.is_local
from sys.dm_hadr_database_replica_states dbr join sys.dm_hadr_database_replica_cluster_states dbcs on dbr.replica_id = dbcs.replica_id and
dbr.group_database_id = dbcs.group_database_id where dbr.group_id = @group_id and dbr.is_primary_replica = 1 and dbr.group_database_id = @group_database_id
if @is_local is null or @is_failover_ready is null
begin
print 'RPO of database '+ @db_name +' is not available'
return
end
if @is_local = 0
begin
print 'You are visiting wrong replica'
return
end
if @is_failover_ready = 1
set @RPO = '00:00:00'
else if @last_commit_time_sec is null or @last_commit_time_pri is null
begin
print 'RPO of database '+ @db_name +' is not available'
return
end
else
begin
if DATEDIFF(ss, @last_commit_time_sec, @last_commit_time_pri) < 0
begin
print 'RPO of database '+ @db_name +' is not available'
return
end
else
set @RPO = CONVERT(varchar, DATEADD(ms, datediff(ss ,@last_commit_time_sec, @last_commit_time_pri) * 1000, 0), 114)
end
print 'RPO of database '+ @db_name +' is ' + @RPO
end
- Выполните proc_calculate_RPO с использованием значений group_id, replica_id и group_database_id целевой вторичной базы данных.
exec proc_calculate_RPO @group_id= 'F176DD65-C3EE-4240-BA23-EA615F965C9B',
@replica_id = '405554F6-3FDC-4593-A650-2067F5FABFFD',
@group_database_id = '39F7942F-7B5E-42C5-977D-02E7FFA6C392'
- Результаты отображают значение RPO для целевой базы данных вторичной копии.
Мониторинг RTO и RPO
Этот раздел демонстрирует, как мониторить ваши группы доступности для метрик RTO и RPO. Эта демонстрация аналогична приведенной в учебнике по графическому пользовательскому интерфейсу Модель работоспособности AlwaysOn, часть 2. Расширение модели работоспособности.
Элементы расчетов для времени перехода на другой ресурс и возможной потери данных, описанные в разделах Оценка времени перехода на другой ресурс (RTO) и Оценка возможной потери данных (RPO), удобно предоставлены в виде метрик производительности в аспекте управления политиками Состояние реплики базы данных (см. раздел Просмотр аспектов управления на основе политик в объекте SQL Server). Вы можете отслеживать эти две метрики по расписанию и получать оповещения, когда метрики превышают значения RTO и RPO.
Приведенные скрипты создают две системные политики, выполняемые по собственным расписаниям со следующими характеристиками:
Политика RTO, которая не выполняется, если оценочное время аварийного переключения превышает 10 минут, оценка проводится каждые 5 минут.
Политика RPO, которая терпит неудачу, когда оценочная потеря данных превышает 1 час, оценивается каждые 30 минут.
Две эти политики имеют идентичную конфигурацию на всех репликах доступности.
Политики оцениваются на всех серверах, но только в группах доступности, для которых локальная реплика доступности является первичной. Если локальная реплика доступности не является первичной, политики не оцениваются.
Неудачи в политике удобно отображаются на панели мониторинга Always On, когда вы просматриваете её на первичной реплике.
Чтобы создать политики, выполните приведенные ниже инструкции на всех экземплярах сервера, входящих в группу доступности:
Запустите службу агента SQL Server, если она еще не запущена.
В SQL Server Management Studio в меню Сервис выберите пункт Параметры.
На вкладке SQL Server AlwaysOn выберите Включить определяемую пользователем политику AlwaysOn и нажмите кнопку ОК.
Этот параметр позволяет отобразить правильно настроенные пользовательские политики на панели мониторинга AlwaysOn.
Создайте условие управления на основе политик, используя следующие спецификации:
Имя:
RTOАспект: Состояние копии базы данных
Поле:
Add(@EstimatedRecoveryTime, 60)Оператор: <=
Значение:
600
Это условие не выполняется, когда потенциальное время для перехода на другой ресурс превышает 10 минут, включая дополнительные 60 секунд для обнаружения сбоя и перехода на другой ресурс.
Создайте второе условие управления на основе политик, используя следующие спецификации:
Имя:
RPOФасет: Состояние реплики базы данных
Поле:
@EstimatedDataLossОператор: <=
Значение:
3600
Это условие не выполняется, когда потенциальная потеря данных превышает 1 час.
Создайте третье условие управления на основе политик, используя следующие спецификации:
Имя:
IsPrimaryReplicaАспект: Группа доступности
Поле:
@LocalReplicaRoleОператор: =
Значение:
Primary
Это условие проверяет, является ли локальная реплика доступности первичной для данной группы доступности.
Создайте политику управления на основе политик, используя следующие спецификации:
Страница Общие:
Имя:
CustomSecondaryDatabaseRTOПроверка условия:
RTOПрименить к: каждый DatabaseReplicaState в IsPrimaryReplica AvailabilityGroup
Этот параметр обеспечивает, что политика оценивается только в группах доступности, для которых локальная реплика доступности является первичной.
Режим оценки: По расписанию
Расписание: CollectorSchedule_Every_5min
Включено: выбрано
Страница Описание:
Категория: Предупреждения базы данных доступности
Этот параметр позволяет отобразить результаты оценки политики на панели мониторинга AlwaysOn.
Описание: Текущая реплика имеет RTO более 10 минут, при условии, что процесс обнаружения и восстановления занимает 1 минуту. Следует немедленно рассмотреть проблемы с производительностью на этом экземпляре сервера.
Отображаемый текст: Превышено значение RTO.
Создайте вторую политику управления на основе политик, используя следующие спецификации:
Страница Общие:
Имя:
CustomAvailabilityDatabaseRPOПроверка условия:
RPOПротив целей: каждое DatabaseReplicaState в IsPrimaryReplica AvailabilityGroup
Режим оценки: По расписанию
Расписание: Расписание_сборщика_каждые_30мин
Включено: выбрано
Страница Описание:
Категория: Предупреждения базы данных доступности
Описание. База данных доступности превысила RPO в 1 час. Необходимо немедленно изучить проблемы с производительностью реплик доступности.
Отображаемый текст: Превышено значение RPO.
Когда вы закончите, будут созданы два новых задания агента SQL Server: одно для каждого расписания оценки политики. Эти задания должны иметь имена, начинающиеся с syspolicy_check_schedule.
Вы можете просмотреть журнал заданий, чтобы изучить результаты оценки. Ошибки оценки также заносятся в журнал приложений Windows (в средстве просмотра событий) с кодом события 34052. Можно также настроить агент SQL Server для отправки предупреждений о сбоях политик. Дополнительные сведения см. в разделе Настройка предупреждений для администраторов политик о сбоях политики.
Сценарии устранения неполадок с производительностью
Ниже перечислены распространенные сценарии устранения неполадок, связанные с производительностью.
| Сценарий | Описание |
|---|---|
| Устранение неполадок: превышение RTO в группе доступности | После автоматического переключения или планового ручного переключения без потери данных время переключения превышает целевое время восстановления (RTO). Или, когда вы оцениваете время переключения для вторичной реплики с синхронной фиксацией (например, партнера автоматического перехода), вы обнаруживаете, что это время превышает ваш RTO. |
| Устранение неполадок: группа доступности превысила RPO | После выполнения принудительного ручного переключения потеря данных превышает допустимый уровень потерь данных (RPO). Или при расчете возможной потери данных для вторичной реплики с асинхронным подтверждением вы обнаруживаете, что она превышает допустимый уровень потери данных (RPO). |
| Устранение неполадок: изменения в первичной реплике не отражены во вторичной | Клиентское приложение успешно изменяет первичную реплику, но запрос вторичной реплики показывает, что это изменение не отражено. |
Полезные расширенные события
Следующие расширенные события полезны при устранении проблем с репликами в состоянии Синхронизации.
| Имя события | Категория | Канал | Реплика высокой доступности |
|---|---|---|---|
| повторная синхронизация завершена | транзакции; | Отладка | Вторичные |
| повторная_запись_работника | транзакции; | Отладка | Второстепенные |
| дамп_сообщения_транспорта_hadr | alwayson |
Отладка | Основной |
| hadr_worker_pool_task | alwayson |
Отладка | Основной |
| процесс_дампа_основного_узла_hadr | alwayson |
Отладка | Основной |
| Журнал прогресса дампа HADR | alwayson |
Отладка | Основной |
| hadr_undo_of_redo_log_scan | alwayson |
Аналитический | Второстепенные |