Устранение неполадок автоматической отработки отказа в SQL Server Always On средах

Статья
03/24/2023

Эта статья поможет устранить проблемы, возникающие при автоматической отработке отказа в Microsoft SQL Server.

Оригинальная версия продукта: SQL Server
Исходный номер базы знаний: 2833707

Сводка

SQL Server Always On группы доступности можно настроить для автоматической отработки отказа. Если в экземпляре SQL Server, где размещается основной реплика, обнаружена проблема работоспособности, основную роль можно перевести в партнера по автоматической отработки отказа (вторичная реплика). Однако вторичная реплика не всегда может быть переведена на основную роль. В некоторых случаях его можно перевести только на RESOLVING роль. В этой ситуации ни реплика не будет иметь основной роли, если только основной реплика не вернется в работоспособное состояние. Кроме того, базы данных доступности будут недоступны.

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

Симптомы при успешном запуске автоматической отработки отказа

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

The state of the local availability replica in availability group '\<Group name>' has changed from 'RESOLVING_NORMAL' to 'PRIMARY_PENDING'  
The state of the local availability replica in availability group '\<Group name>' has changed from 'PRIMARY_PENDING' to 'PRIMARY_NORMAL'

Снимок экрана: журнал ошибок при успешном запуске автоматической отработки отказа.

Примечание.

Дополнительный реплика успешно переходит из RESOLVING_NORMAL состояния в PRIMARY_NORMAL состояние .

Симптомы, если автоматическая отработка отказа завершается неудачно

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

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

Снимок экрана: реплики доступности в SQL Server Management Studio.

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

Вариант 1. Значение "Максимальное число сбоев в указанном периоде" исчерпано

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

Чтобы исследовать и диагностировать причину неудачной отработки отказа, просмотрите журнал кластера Windows (Cluster.log), а затем проверка свойство .

Шаг 1. Просмотр данных в журнале кластера Windows (Cluster.log)

Используйте Windows PowerShell для создания журнала кластера Windows на узле кластера, на котором размещается основной реплика. Для этого выполните следующий командлет в окне PowerShell с повышенными привилегиями на экземпляре SQL Server, где размещается основной реплика:
```
Get-ClusterLog -Node <SQL Server node name> -TimeSpan 15
```
[! ПРИМЕЧАНИЯ]
- Параметр -TimeSpan 15 на этом шаге предполагает, что диагностируемая проблема возникла в течение предыдущих 15 минут.
- По умолчанию файл журнала создается в папке %WINDIR%\cluster\reports.
Откройте файл Cluster.log в Блокноте, чтобы просмотреть журнал кластера Windows.
В Блокноте выберите Изменить>поиск и найдите строку failoverCount в конце файла. В результатах вы найдете сообщение, похожее на следующее:

Отсутствие отработки отказа группы <Имя> ресурса, failoverCount 3, failoverThresholdSetting <Number>, computedFailoverThreshold 2

Шаг 2. Проверка максимального числа сбоев в свойстве Указанного периода

Запустите диспетчер отказоустойчивости кластеров.
В области навигации выберите Роли.
В области Роли щелкните правой кнопкой мыши кластеризованный ресурс и выберите пункт Свойства.
Перейдите на вкладку Отработка отказа и выберите максимальное количество сбоев в значении Указанный период .

Примечание.

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

Заключение

После анализа журнала вы обнаружите, что значение failoverCount3 больше значения computedFailoverThreshold2. Таким образом, кластер Windows не может завершить операцию отработки отказа ресурса группы доступности партнеру по отработку отказа.

Решение

Чтобы устранить эту проблему, увеличьте значение Максимальное число сбоев в указанном периоде .

Примечание.

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

Случай 2. Недостаточно разрешений учетной записи NT Authority\SYSTEM

Библиотека DLL ресурса ядра СУБД SQL Server подключается к экземпляру SQL Server, в котором размещается основной реплика, с помощью ODBC для мониторинга работоспособности. Учетные данные входа, используемые для этого подключения, являются локальной учетной записью SQL Server NT AUTHORITY\SYSTEM входа. По умолчанию этой локальной учетной записи входа предоставляются следующие разрешения:

Изменение любой группы доступности
Connect SQL
Просмотр состояния сервера

Если у учетной NT AUTHORITY\SYSTEM записи входа отсутствуют какие-либо из этих разрешений для партнера по автоматической отработки отказа (дополнительное реплика), то SQL Server не может запустить обнаружение работоспособности при автоматической отработки отказа. Таким образом, дополнительный реплика не может перейти на основную роль. Чтобы изучить и диагностировать, является ли это причиной, просмотрите журнал кластера Windows. Для этого выполните следующие действия:

Используйте Windows PowerShell для создания журнала кластера Windows на узле кластера. Для этого выполните следующий командлет в окне PowerShell с повышенными привилегиями на экземпляре SQL Server, где размещается дополнительный реплика, который не перешел в основную роль:
```
Get-ClusterLog -Node <SQL Server node name> -TimeSpan 15
```
Откройте файл Cluster.log в Блокноте, чтобы просмотреть журнал кластера Windows.
Найдите запись об ошибке, похожую на следующий текст:

Не удалось выполнить команду диагностика. У пользователя нет разрешения на выполнение этого действия.

Заключение

Файл Cluster.log сообщает, что при выполнении SQL Server команды диагностика возникает проблема с разрешениями. В этом примере сбой был вызван удалением разрешения "Просмотр состояния сервера" из NT AUTHORITY\SYSTEM учетной записи входа в экземпляре SQL Server, где размещается вторичная реплика пары автоматической отработки отказа.

Решение

Чтобы устранить эту проблему, предоставьте учетной NT AUTHORITY\SYSTEM записи входа достаточные разрешения для обнаружения работоспособности библиотеки DLL ресурса ядра СУБД SQL Server.

Случай 3. Базы данных доступности не в состоянии SYNCHRONIZED

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

Дополнительные сведения о необходимых условиях для автоматической отработки отказа см. в разделе Условия, необходимые для автоматической отработки отказа, а реплики синхронной фиксации поддерживают два параметра в разделах Режимы отработки отказа и Отработки отказа (Always On группы доступности).

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

Одна или несколько баз данных не синхронизированы или не присоединены к группе доступности.

Снимок экрана: журнал ошибок SQL Server в случае 3.

Чтобы проверка, находились ли базы данных доступности SYNCHRONIZED в состоянии , выполните следующие действия.

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

Примечание.

Нулевое значение для любой базы данных доступности может предотвратить автоматическую отработку отказа. Это значение указывает, что база данных доступности не SYNCHRONIZEDбыла .
```
SELECT database_name, is_failover_ready FROM sys.dm_hadr_database_replica_cluster_states WHERE replica_id IN (SELECT replica_id FROM sys.dm_hadr_availability_replica_states)
```

Заключение

Для успешной автоматической отработки отказа группы доступности требуется, чтобы все базы данных доступности были в SYNCHRONIZED состоянии . Дополнительные сведения о режимах доступности см. в разделе Режимы доступности в Always On группах доступности.

Случай 4. Конфигурация принудительного шифрования протокола выбрана для клиентских протоколов на вторичном реплика (целевом источнике), хотя реплика не настроен для шифрования

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

Чтобы проверка для этой конфигурации:

Запустите диспетчер конфигурации SQL Server.
В левой области щелкните правой кнопкой мыши конфигурацию SQL Native Client 11.0 и выберите Пункт Свойства.
В диалоговом окне проверка параметр Принудительное шифрование протокола. Если задано значение Да, измените значение на Нет.
Повторно протестировать отработку отказа.

Снимок экрана: свойства конфигурации SQL Native Client 11.0 в диспетчер конфигурации SQL Server.

Заключение

SQL Server Always On мониторинг работоспособности использует локальное подключение ODBC для мониторинга работоспособности SQL Server. Принудительное шифрование протокола должно быть включено в разделе Конфигурация клиента диспетчер конфигурации SQL Server только в том случае, если в SQL Server в диспетчер конфигурации SQL Server в SQL Server Раздел "Конфигурация сети". Дополнительные сведения см. в разделе Включение зашифрованных подключений к ядру СУБД.

Случай 5. Проблемы с производительностью на вторичном реплика или узле приводят к сбою проверок работоспособности Always On

Перед отработки отказа с основного реплика на дополнительный реплика библиотека DLL ресурсов ядра СУБД SQL Server подключается к дополнительному реплика, чтобы определить работоспособность реплика. Если это подключение завершается сбоем из-за проблем с производительностью на вторичном реплика, автоматическая отработка отказа не выполняется.

Чтобы исследовать и диагностировать, является ли это причиной, выполните следующие действия.

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

0000110c.00002bcc::2020/08/06-01:17:54.943 INFO  [RCM] move of group AOCProd01AG from CO2ICMV3SQL09(1) to CO2ICMV3SQL10(2) of type MoveType::Manual is about to succeed, failoverCount=3, lastFailoverTime=2020/08/05-02:08:54.524 targeted=true 
00002a54.0000610c::2020/08/06-01:18:44.929 ERR   [RES] SQL Server Availability Group <AOCProd01AG>: [hadrag] ODBC Error: [08001] [Microsoft][SQL Server Native Client 11.0]Unable to complete login process due to delay in opening server connection (0) 
00002a54.0000610c::2020/08/06-01:18:44.929 INFO  [RES] SQL Server Availability Group <AOCProd01AG>: [hadrag] Could not connect to SQL Server (rc -1) 
00002a54.0000610c::2020/08/06-01:18:44.929 INFO  [RES] SQL Server Availability Group <AOCProd01AG>: [hadrag] SQLDisconnect returns following information 
00002a54.0000610c::2020/08/06-01:18:44.929 ERR   [RES] SQL Server Availability Group <AOCProd01AG>: [hadrag] ODBC Error: [08003] [Microsoft][ODBC Driver Manager] Connection not open (0) 
00002a54.0000610c::2020/08/06-01:18:44.931 ERR   [RES] SQL Server Availability Group <AOCProd01AG>: [hadrag] Failed to connect to SQL Server 
00002a54.0000610c::2020/08/06-01:18:44.931 ERR   [RHS] Online for resource AOCProd01AG failed.

Такая ситуация может возникнуть, если отработка отказа выполняется на SQL Server-вторичную реплика, имеющую существующую рабочую нагрузку. Это может задержать ответ SQL Server на попытку подключения к работоспособности HADR и предотвратить успешную попытку отработки отказа.

Чтобы определить, существует ли давление на системные планировщики, используйте SQL Server Management Studio для запуска следующего скрипта на дополнительном реплика:

USE MASTER 
GO  
WHILE 1=1 
BEGIN 
PRINT convert(varchar(20), getdate(),120) 
DECLARE @max INT; 
SELECT @max = max_workers_count 
FROM sys.dm_os_sys_info; 
SELECT GETDATE() AS 'CurrentDate',  
       @max AS 'TotalThreads',  
       SUM(active_Workers_count) AS 'CurrentThreads',  
       @max - SUM(active_Workers_count) AS 'AvailableThreads',  
       SUM(runnable_tasks_count) AS 'WorkersWaitingForCpu',  
       SUM(work_queue_count) AS 'RequestWaitingForThreads' 
       --SUM(current_workers_count) AS 'AssociatedWorkers' 
FROM sys.dm_os_Schedulers 
WHERE STATUS = 'VISIBLE ONLINE'; 
wait for delay '0:0:15' 
END

Ниже приведен пример выходных данных предыдущего запроса:

CurrentDate	TotalThreads	CurrentThreads	AvailableThreads	WorkersWaitingForCpu	RequestWaitingForThreads
2020-10-06 01:27:01.337	1216	361	855	33	0
2020-10-06 01:27:08.340	1216	1412	-196	22	76
2020-10-06 01:27:15.340	1216	1304	-88	2	161
2020-10-06 01:27:22.340	1216	1242	-26	21	185
2020-10-06 01:27:29.343	1216	1346	-130	19	476
2020-10-06 01:27:36.350	1216	1350	-134	9	630
2020-10-06 01:27:43.353	1216	1346	-130	13	539
2020-10-06 01:27:50.360	1216	1378	-162	5	328
2020-10-06 01:27:57.360	1216	197	1019	0	0

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

Решение

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

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

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

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

Используйте Windows PowerShell для создания журнала кластера Windows на узле кластера. Для этого выполните следующий командлет в окне PowerShell с повышенными привилегиями на экземпляре SQL Server, где размещается дополнительный реплика, который не перешел в основную роль. Журнал кластера будет создан за последние 60 минут действий.
```
Get-ClusterLog -Node <SQLServerNodeName> -TimeSpan 60
```
Чтобы просмотреть журнал кластера Windows, откройте файл Cluster.log в Блокноте.
Найдите строку "Подключиться к SQL Server", которая попадает во время события неудачной отработки отказа.
Просмотрите последующие сообщения входа с помощью идентификатора потока (см. следующий снимок экрана), чтобы сопоставить события, связанные с событием входа. В следующем примере показан поиск по запросу "Подключиться к SQL Server". Здесь также показано использование идентификатора потока (слева) для поиска других диагностика, описывающих причину сбоя попытки подключения.

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

Пример набора 1

[hadrag] ODBC Error: [08001] [Microsoft][SQL Server Native Client 11.0]SQL Server Network
Interfaces: No client protocols are enabled and no protocol was specified in the connection
string [xFFFFFFFF]. (268435455)

Решение

Запустите диспетчер конфигурации SQL Server, а затем убедитесь, что в разделе Клиентские протоколы для конфигурации собственного клиента SQL включена общая память или TCP/IP.

Пример набора 2

[hadrag] ODBC Error: [08001] [Microsoft][SQL Server Native Client 11.0]SQL Server Network
Interfaces: Server doesn't support requested protocol [xFFFFFFFF]. (268435455)

Решение

Пример набора 3

000010b8.00001764::2020/12/02-16:52:49.808 ERR [RES] SQL Server Availability Group : [hadrag]
ODBC Error: [42000] [Microsoft][SQL Server Native Client 11.0][SQL Server]Cannot alter the availability
group 'ag', because it does not exist or you do not have permission. (15151)
000010b8.00000fd0::2020/12/02-17:01:14.821 ERR [RES] SQL Server Availability Group: [hadrag]
ODBC Error: [42000] [Microsoft][SQL Server Native Client 11.0][SQL Server]The user does not have permission to perform this action. (297)
000010b8.00001838::2020/12/02-17:10:04.427 ERR [RES] SQL Server Availability Group : [hadrag]
ODBC Error: [42000] [Microsoft][SQL Server Native Client 11.0][SQL Server]Login failed for user
'SQLREPRO\NODE2$'. Reason: The account is disabled. (18470)

Решение

Ознакомьтесь с вариантом 2. Недостаточно разрешений для учетной записи NT Authority\SYSTEM.

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

Устранение неполадок автоматической отработки отказа в SQL Server Always On средах

Сводка

Симптомы при успешном запуске автоматической отработки отказа

Симптомы, если автоматическая отработка отказа завершается неудачно

Вариант 1. Значение "Максимальное число сбоев в указанном периоде" исчерпано

Шаг 1. Просмотр данных в журнале кластера Windows (Cluster.log)

Шаг 2. Проверка максимального числа сбоев в свойстве Указанного периода

Случай 2. Недостаточно разрешений учетной записи NT Authority\SYSTEM

Случай 3. Базы данных доступности не в состоянии SYNCHRONIZED

Случай 5. Проблемы с производительностью на вторичном реплика или узле приводят к сбою проверок работоспособности Always On

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

Пример набора 1

Пример набора 2

Пример набора 3

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

Дополнительные ресурсы