Параметр переключения при отказе для обнаружения работоспособности на уровне базы данных в группе доступности

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

Начиная с SQL Server 2016, при настройке группы доступности AlwaysOn стал доступен параметр определения уровня работоспособности базы данных (DB_FAILOVER). Функция определения уровня работоспособности баз данных замечает, когда база данных выходит из сетевого режима, в случае если возникают какие-либо неполадки, и инициирует автоматический переход группы доступности на другой ресурс. Примеры ситуаций, которые могут запустить проверку работоспособности, включают базу данных в подозрительном состоянии, отключенную базу данных и базу данных в состоянии восстановления (восстановление завершилось неудачей). Дополнительные сведения см. в статье Столбец состояния в sys.databases.

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

Преимущества параметра проверки работоспособности на уровне базы данных

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

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

Включение контроля работоспособности на уровне базы данных

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

Существует несколько простых способов включить параметр проверки работоспособности на уровне базы данных:

В среде SQL Server Management Studio подключитесь к ядру СУБД. В окне «Обозреватель объектов» щелкните правой кнопкой мыши узел Always On High Availability и запустите мастер создания новой группы доступности. На странице "Укажите имя" установите флажок Проверка работоспособности на уровне базы данных. Затем выполните действия на оставшихся страницах мастера.
Просмотрите Свойства существующей группы доступности в среде SQL Server Management Studio. Подключитесь к серверу SQL Server. В окне "Обозреватель объектов" разверните узел "Высокий уровень доступности Always On". Разверните "Группы доступности". Щелкните правой кнопкой мыши группу доступности и выберите пункт "Свойства". Выберите параметр Определение уровня работоспособности баз данных, а затем нажмите кнопку "ОК" или зафиксируйте изменение.

Синтаксис Transact-SQL для CREATE AVAILABILITY GROUP. Параметр DB_FAILOVER принимает значения ON или OFF.

CREATE AVAILABILITY GROUP [Contoso-ag]
WITH (DB_FAILOVER=ON)
FOR DATABASE [AutoHa-Sample]
REPLICA ON
    N'SQLSERVER-0' WITH (ENDPOINT_URL = N'TCP://SQLSERVER-0.DOMAIN.COM:5022',
      FAILOVER_MODE = AUTOMATIC, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT),
    N'SQLSERVER-1' WITH (ENDPOINT_URL = N'TCP://SQLSERVER-1.DOMAIN.COM:5022',
     FAILOVER_MODE = AUTOMATIC, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);

Синтаксис Transact-SQL для ALTER AVAILABILITY GROUP. Параметр DB_FAILOVER принимает значения ON или OFF.
```
ALTER AVAILABILITY GROUP [Contoso-ag] SET (DB_FAILOVER = ON);

ALTER AVAILABILITY GROUP [Contoso-ag] SET (DB_FAILOVER = OFF);
```

Предупреждения

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

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

Еще один пример: когда ядру СУБД SQL Server требуется считать страницу данных для выполнения запроса, а страница данных кэшируется в память буферного пула, то для выполнения запроса может не потребоваться чтение с диска с физическим доступом. Таким образом, отсутствующий или недоступный файл данных может не сразу вызвать автоматическое переключение при отказе, даже если включен параметр проверки работоспособности базы данных, поскольку состояние базы данных обновляется не сразу.

Аварийное переключение базы данных не зависит от гибкой политики аварийного переключения.

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

Управление и мониторинг контроля работоспособности на уровне базы данных

Dynamic Management Views (Динамические административные представления)

В системном DMV sys.availability_groups отображается столбец db_failover, который указывает, отключен (0) или включен (1) параметр определения уровня работоспособности базы данных.

select name, db_failover from sys.availability_groups

Пример вывода dmv:

имя	db_failover
Contoso-ag	1

Журнал ошибок

В журнале ошибок SQL Server (или в тексте, возвращаемом sp_readerrorlog) появится сообщение об ошибке 41653, когда в группе доступности произойдёт переключение при отказе из-за проверок работоспособности на уровне базы данных.

Например, в этом фрагменте журнала ошибок показано, что произошел сбой при записи в журнал транзакций из-за проблем с диском, а затем была остановлена база данных с именем AutoHa-Sample, в результате чего проверка работоспособности на уровне базы данных инициировала отработку отказа группы доступности.

2016-04-25 12:20:21.08 spid1s Ошибка: 17053, Серьезность: 16, Состояние: 1.

2016-04-25 12:20:21.08 spid1s SQLServerLogMgr::LogWriter: Обнаружена ошибка операционной системы 21 (устройство не готово). 2016-04-25 12:20:21.08 spid1s Ошибка записи во время сброса журнала.

2016-04-25 12:20:21.08 spid79 Ошибка: 9001, Серьезность: 21, Состояние: 4.

2016-04-25 12:20:21.08 spid79 Журнал для базы данных "AutoHa-Sample" недоступен. Проверьте журнал событий на наличие сообщений о связанных ошибках. Устраните все ошибки и заново запустите базу данных.

2016-04-25 12:20:21.15 spid79 Ошибка: 41653, Серьезность: 21, Состояние: 1.

2016-04-25 12:20:21.15 spid79 База данных "AutoHa-Sample" обнаружила ошибку (тип ошибки: 2 "DB_SHUTDOWN"), которая привела к сбою группы доступности "Contoso-ag". Дополнительные сведения об обнаруженных ошибках см. в журнале ошибок SQL Server. Если эта проблема сохраняется, обратитесь к системному администратору.

2016-04-25 12:20:21.17 spid79 Сведения о состоянии для базы данных "AutoHa-Sample" — зафиксированный номер LSN: "(34:664:1)" Номер LSN фиксации: "(34:656:1)" Время фиксации: "Apr 25 2016 12:19"

2016-04-25 12:20:21.19 spid15s Подключение Always On Availability Groups к вторичной базе данных прервано для первичной базы данных "AutoHa-Sample" на реплике доступности "SQLServer-0" с идентификатором реплики: {c4ad5ea4-8a99-41fa-893e-189154c24b49}. Это информационное сообщение. Вмешательство пользователя не требуется.

2016-04-25 12:20:21.21 spid75 Always On: локальная реплика группы доступности «Contoso-ag» готовится к переходу в роль разрешения по запросу кластера отказоустойчивой кластеризации Windows Server (WSFC). Это информационное сообщение. Вмешательство пользователя не требуется.

2016-04-25 12:20:21.21 spid75 Состояние локальной реплики доступности в группе доступности "ag" было изменено с "PRIMARY_NORMAL" на "RESOLVING_NORMAL". Состояние изменено, так как группа доступности переходит в режим "вне сети". Реплика переходит в автономный режим, поскольку связанная группа доступности была удалена или пользователь перевел связанную группу доступности в режим "вне сети" на консоли управления сервером отказоустойчивой кластеризации Windows (WSFC), или группа доступности переходит на другой экземпляр SQL Server. Дополнительные сведения см. в журнале ошибок SQL Server, консоли управления отказоустойчивой кластеризации Windows Server (WSFC) или журнале WSFC.

Расширенное событие sqlserver.availability_replica_database_fault_reporting

В SQL Server 2016 определено новое расширенное событие, запускаемое определением уровня работоспособности базы данных. Имя события — sqlserver.availability_replica_database_fault_reporting.

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

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

Пример скрипта сеанса расширенных событий

CREATE EVENT SESSION [AlwaysOn_dbfault] ON SERVER
ADD EVENT sqlserver.availability_replica_database_fault_reporting
ADD TARGET package0.event_file(SET filename=N'dbfault.xel',max_file_size=(5),max_rollover_files=(4))
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,
    MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=ON)
GO
ALTER EVENT SESSION AlwaysOn_dbfault ON SERVER STATE=START
GO

Выходные данные расширенного события

С помощью SQL Server Management Studio подключитесь к основному серверу SQL Server, разверните узел «Управление», а затем — узел «Расширенные события». Найдите сеанс (AlwaysOn_dbfault — это имя в приведённом выше примере) и разверните его, чтобы увидеть файлы вывода. Выберите выходной файл, после чего файл события откроется в новой вкладке.

Описание полей:

Данные столбца	Описание
availability_group_id	Идентификатор группы доступности.
имя_группы_доступности	Имя группы доступности.
availability_replica_id	Идентификатор реплики доступности.
Имя реплики доступности	Имя реплики доступности.
database_name	Имя базы данных, сообщившей о сбое.
database_replica_id	Идентификатор реплики базы данных доступности.
реплики, готовые к аварийному переключению	Количество синхронизированных вторичных реплик для автоматического переключения при отказе.
тип_ошибки	Указан идентификатор сбоя. Возможные значения: 0 — НЕТ 1 — неизвестно 2 — завершение работы
является_критическим	Это значение всегда должно возвращать true для XEvent, начиная с версии SQL Server 2016.

В этом примере выходных данных поле fault_type показывает, что в группе доступности Contoso-ag произошло критическое событие на реплике с именем SQLSERVER-1, связанное с базой данных AutoHa-Sample2, с типом сбоя 2 — завершение работы.

Поле	Значение
availability_group_id	24E6FE58-5EE8-4C4E-9746-491CFBB208C1
имя_группы_доступности	Contoso-ag
availability_replica_id	3EAE74D1-A22F-4D9F-8E9A-DEFF99B1F4D1
имя_реплики_доступности	SQLSERVER-1
database_name	AutoHa-Sample2
идентификатор реплики базы данных	39971379-8161-4607-82E7-098590E5AE00
failover_ready_replicas	1
тип неисправности	2
является_критическим	Истина

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2026-07-21