Параметр определения уровня работоспособности базы данных группы доступности
Применимо к:
SQL Server
Начиная с SQL Server 2016, при настройке группы доступности AlwaysOn стал доступен параметр определения уровня работоспособности базы данных (DB_FAILOVER). Функция определения уровня работоспособности баз данных замечает, когда база данных выходит из сетевого режима, в случае если возникают какие-либо неполадки, и инициирует автоматический переход группы доступности на другой ресурс. Примеры, которые могут инициировать обнаружение работоспособности, включают базу данных в подозрительном режиме, базу данных в автономном режиме и базу данных в процессе восстановления (сбой восстановления). Дополнительные сведения см. в статье Столбец состояния в sys.databases.
Этот параметр включен для группы доступности в целом, поэтому определение уровня работоспособности базы данных отслеживает каждую базу данных в группе доступности. Он не может быть включен выборочно для конкретных баз данных в группе доступности.
Преимущества параметра определения уровня работоспособности базы данных
Параметр определения уровня работоспособности базы данных группы доступности является хорошим рекомендуемым вариантом для обеспечения высокого уровня доступности баз данных. Рекомендуется настроить его для всех групп доступности. Если высокая доступность приложения зависит от нескольких баз данных, объедините их в группу доступности с включенным параметром определения работоспособности базы данных.
Например, если параметр определения уровня работоспособности базы данных включен и SQL Server не удалось выполнить запись в файл журнала транзакций для одной из баз данных, состояние этой базы данных изменится и будет указывать на сбой. Вскоре произойдет отработка отказа группы доступности, после чего приложение сможет повторно подключиться и продолжить работу с минимальным нарушением после перехода баз данных в сетевой режим.
Включение определения уровня работоспособности базы данных
Несмотря на то, что это обычно рекомендуется сделать, параметр определения работоспособности базы данных отключен по умолчанию с целью обеспечения обратной совместимости с параметрами по умолчанию в предыдущих версиях.
Существует несколько простых способов включения параметра определения уровня работоспособности базы данных.
В среде SQL Server Management Studio подключитесь к ядру СУБД. В окне обозреватель объектов щелкните правой кнопкой мыши узел Always On Высокий уровень доступности и запустите мастер создания группы доступности. На странице "Укажите имя" установите флажок Определение уровня работоспособности баз данных. Затем выполните действия на оставшихся страницах мастера.
Просмотрите Свойства существующей группы доступности в среде 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. Два параметра являются независимыми.
Мониторинг определения уровня работоспособности базы данных и управление им
Динамические административные представления
В системном DMV sys.availability_groups отображается столбец db_failover, который указывает, отключен (0) или включен (1) параметр определения уровня работоспособности базы данных.
select name, db_failover from sys.availability_groups
Пример выходных данных DMV:
| name | db_failover |
|---|---|
| Contoso-ag | 1 |
ErrorLog
В журнале ошибок 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 к базе данных-получателю завершено для базы данных-источника "AutoHa-Sample" в реплике доступности "SQLServer-0" с ИД реплики: {c4ad5ea4-8a99-41fa-893e-189154c24b49}. Это информационное сообщение. Вмешательство пользователя не требуется.
2016-04-25 12:20:21.21 spid75 Always On: локальная реплика группы доступности "Contoso-ag" готовится к переходу к роли разрешения в ответ на запрос от кластера 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 должен находиться в пути к журналу ошибок 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_group_name | Имя группы доступности. |
| availability_replica_id | Идентификатор реплики доступности. |
| availability_replica_name | Имя реплики доступности. |
| database_name | Имя базы данных, сообщившей о сбое. |
| database_replica_id | Идентификатор реплики базы данных доступности. |
| failover_ready_replicas | Количество синхронизируемых вторичных реплик файлов для автоматического перехода в случае сбоя. |
| fault_type | Передан идентификатор сбоя. Возможные значения: 0 — отсутствует 1 — неизвестно 2 — завершение работы |
| is_critical | Это значение всегда должно возвращать true для XEvent, начиная с версии SQL Server 2016. |
В выходных данных этого примера fault_type показывает, что в группе доступности "Contoso-ag" в реплике "SQLSERVER-1" произошло критическое событие из-за имени базы данных "AutoHa-Sample2" с типом сбоя "2 — завершение работы".
| Поле | Значение |
|---|---|
| availability_group_id | 24E6FE58-5EE8-4C4E-9746-491CFBB208C1 |
| availability_group_name | Contoso-ag |
| availability_replica_id | 3EAE74D1-A22F-4D9F-8E9A-DEFF99B1F4D1 |
| availability_replica_name | SQLSERVER-1 |
| database_name | AutoHa-Sample2 |
| database_replica_id | 39971379-8161-4607-82E7-098590E5AE00 |
| failover_ready_replicas | 1 |
| fault_type | 2 |
| is_critical | Верно |
Связанные справочники
Enhance Always On Failover Policy to Test SQL Server Database Data and Log Drives (Улучшения политики перехода на другой ресурс Always On для тестирования данных базы данных и дисков журнала SQL Server)
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по