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

Статья
12/14/2024

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

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

Итоги

Группы доступности AlwaysOn SQL Server можно настроить для автоматической отработки отказа. Если на экземпляре 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 в конце файла. В результатах следует найти сообщение, похожее на следующее сообщение:

Не выполняется отработка отказа имени ресурса группы<, отработка отказа 3, отработка отказаThresholdSetting <Number>, computedFailoverThreshold 2>

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

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

Примечание.

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

Заключение

После анализа журнала вы обнаружите, что значение отработки отказа 3 больше, чем значение computedFailoverThreshold 2. Поэтому кластер Windows не может завершить операцию отработки отказа ресурса группы доступности партнеру отработки отказа.

Решение

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

Примечание.

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

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

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

Изменение любой группы доступности
Подключение 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 запускает команду диагностика. В этом примере сбой был вызван удалением разрешения состояния сервера view из NT AUTHORITY\SYSTEM учетной записи входа в экземпляре SQL Server, на котором размещена вторичная реплика автоматической отработки отказа.

Решение

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

Случай 3. Базы данных доступности не в состоянии СИНХРОНИЗИРОВАНЫ

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

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

Чтобы изучить и диагностировать причину неудачной отработки отказа, просмотрите журнал ошибок 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 состоянии. Дополнительные сведения о режимах доступности см. в режимах доступности в группах доступности AlwaysOn.

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

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

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

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

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

Заключение

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

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

Прежде чем выполнять отработку отказа из первичной реплики на вторичную реплику, 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, а затем убедитесь, что общая память или TCP/IP включена в клиентских протоколах для конфигурации собственного клиента SQL.

Пример набора 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\SYSTEM.

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

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

Итоги

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

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

Случай 1: "Максимальные сбои в указанном периоде" исчерпаны

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

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

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

Случай 3. Базы данных доступности не в состоянии СИНХРОНИЗИРОВАНЫ

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

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

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

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

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

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

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