MSSQLSERVER_35250

Статья
05/23/2023

Применимо к:SQL Server

Сведения

Атрибут	значение
Название продукта	SQL Server
Идентификатор события	35250
Источник событий	MSSQLSERVER
Компонент	SQLEngine
Символическое имя	HADR_PRIMARYNOTACTIVE
Текст сообщения	Подключение к первичной реплике неактивно. Не удается обработать команду.

Пояснение

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

Действие пользователя

Вариант 1. Выполнение действий непосредственно в записной книжке с помощью Azure Data Studio

Откройте записную книжку в Azure Data Studio

Узнайте, как установить Azure Data Studio

Вариант 2. Выполнение действий вручную**

Заметка

Все следующие действия должны выполняться как в первичной, так и в неисправной вторичной реплике.

1. Убедитесь, что конечная точка создана и запущена

Чтобы обнаружить конечную точку, выполните следующий запрос.
```
SELECT
  tep.name as EndPointName,
  sp.name As CreatedBy,
  tep.type_desc,
  tep.state_desc,
  tep.port
FROM
  sys.tcp_endpoints tep
INNER JOIN sys.server_principals sp ON tep.principal_id = sp.principal_id
WHERE tep.type = 4
```
Предупреждение

Будьте внимательны при выполнении следующей команды, так как она может вызвать кратковременный простой реплики.
Чтобы перезапустить обнаруженную конечную точку, выполните следующие команды.
```
ALTER ENDPOINT hadr_endpoint STATE = STOPPED
ALTER ENDPOINT hadr_endpoint STATE = STARTED
```

2. Проверьте возможность подключения к конечной точке

Для проверки подключения используйте команды telnet или Test-NetConnection. Если конечная точка ожидает передачи данных и подключение будет установлено, telnet отобразит пустой экран с мигающим курсором. В противном случае вы получите от telnet сообщение об ошибке подключения. Чтобы выйти из установленного подключения telnet, нажмите клавиши CTRL+]. Если вы используете Test-NetConnection, смотрите результаты TcpTestSucceeded : True или TcpTestSucceeded : False.
```
telnet ServerName <port_number>
telnet IP_Address <port_number>
```
```
Test-NetConnection -ComputerName <ServerName> -Port <port_number>
Test-NetConnection -ComputerName <IP_address> -Port <port_number>
```

Проблемы с DNS

Если подключение с помощью telnet/Test-NetConnection к IP-адресу работает, но подключение по имени сервера установить не удается, вероятно, имеется проблема с DNS или разрешением имен. См. пункт Проверьте наличие проблем с разрешением имен

Множество процессов ожидают передачи данных на одном порту

Если подключение с помощью telnet/Test-NetConnection удается установить по имени сервера, но не удается по IP-адресу, возможно, на этом сервере определено несколько конечных точек (например, другой экземпляр SQL), для которых настроено ожидание передачи данных на текущем порту. Несмотря на то что конечная точка на рассматриваемом экземпляре находится в состоянии "ЗАПУЩЕНО", другая конечная точка может фактически занимать порт и не позволять первой конечной точке прослушивать и устанавливать соединения TCP. Чтобы найти процесс владения портом 5022, выполните следующую команду:
```
$port = "5022"
Get-Process -Id (Get-NetTCPConnection -LocalPort $port).OwningProcess |Select-Object Name, ProductVersion, Path, Id
```

Блокировка конечной точки (брандмауэром или антивирусом)

Если установить подключение с помощью telnet или Test-NetConnection не удается, проверьте, не блокируется ли нужный порт конечной точки брандмауэром или антивирусной программой. Проверьте параметры брандмауэра, чтобы узнать, разрешена ли связь для портов конечных точек между экземплярами серверов, на которых размещаются первичная и вторичная реплика (по умолчанию порт 5022). Если вы используете SQL Server на виртуальной машине Azure, также необходимо убедиться, что группа безопасности сети (NSG) разрешает трафик в порт конечной точки. Проверьте параметры брандмауэра (и группу безопасности сети для виртуальной машине Azure), чтобы узнать, разрешена ли связь для портов конечных точек между экземплярами серверов, на которых размещаются первичная и вторичная реплика (по умолчанию порт 5022).

Чтобы проверить наличие правил отключения входящего трафика, выполните следующий скрипт PowerShell:
```
Get-NetFirewallRule -Action Block -Enabled True -Direction Inbound |Format-Table
```
Получите выходные данные команды netstat или Get-NetTCPConnection и убедитесь, что для IP-адреса и порта заданной конечной точки указано состояние LISTENING (Ожидает передачи данных) или ESTABLISHED (Соединение установлено).
```
netstat -a
```
```
Get-NetTCPConnection -LocalPort <port_number>
```
Вы также можете найти процесс владения портом: выполните следующую команду (например, с помощью порта 5022)
```
$port = "5022"
Get-Process -Id (Get-NetTCPConnection -LocalPort $port).OwningProcess |Select-Object Name, ProductVersion, Path, Id
```

3. Проверьте наличие в системе ошибок

Вы можете отправить запрос к таблице sys.dm_hadr_availability_replica_states, чтобы получить номер последней ошибки подключения (last_connect_error_number), который может помочь в диагностике проблемы. В зависимости от реплики, к которой не удается установить подключение, вы можете выполнить запрос как к первичной, так и ко вторичной реплике.
```
select
  r.replica_server_name,
  r.endpoint_url,
  rs.connected_state_desc,
  rs.last_connect_error_description,
  rs.last_connect_error_number,
  rs.last_connect_error_timestamp
from
  sys.dm_hadr_availability_replica_states rs
  join sys.availability_replicas r on rs.replica_id = r.replica_id
where
  rs.is_local = 1
```
Например, если вторичной реплике не удалось установить связь с DNS-сервером или параметр endpoint_url реплики был настроен неверно при создании группы доступности, вы можете получить следующие результаты в last_connect_error_description:

DNS Lookup failed with error '11001(No such host is known)'

4. Проверьте настройку конечной точки на те IP-адрес и порт, для которых определена группа доступности

Выполните следующий запрос на первичной реплике, а затем на каждой вторичной реплике, которой не удается установить подключение. Это поможет определить URL-адрес и порт конечной точки.
```
select endpoint_url from sys.availability_replicas
```

Выполните следующий запрос, чтобы найти конечные точки и порты.

SELECT
  tep.name as EndPointName,
  sp.name As CreatedBy,
  tep.type_desc,
  tep.state_desc,
  tep.port
FROM
  sys.tcp_endpoints tep
  INNER JOIN sys.server_principals sp ON tep.principal_id = sp.principal_id
WHERE
  tep.type = 4

Сравните URL-адрес (endpoint_url) и порт конечной точки из каждого запроса и убедитесь, что порт из URL-адреса конечной точки (endpoint_url) совпадает с портом, указанным для конечной точки в каждой соответствующей реплике.

Заметка

Если для прослушивания конечной точки используются определенные IP-адреса, а не полное доменное имя по умолчанию, может потребоваться определить URL-адреса, использующие конкретный IP-адрес, а не полное доменное имя.

5. Проверьте наличие у учетной записи сетевой службы разрешения CONNECT для конечной точки

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

SELECT 
  perm.class_desc,
  prin.name,
  perm.permission_name,
  perm.state_desc,
  prin.type_desc as PrincipalType,
  prin.is_disabled
FROM sys.server_permissions perm
  LEFT JOIN sys.server_principals prin ON perm.grantee_principal_id = prin.principal_id
  LEFT JOIN sys.tcp_endpoints tep ON perm.major_id = tep.endpoint_id
WHERE 
  perm.class_desc = 'ENDPOINT'
  AND perm.permission_name = 'CONNECT'
  AND tep.type = 4;

SELECT 
  ep.name, 
  sp.state,
  CONVERT(nvarchar(38), suser_name(sp.grantor_principal_id)) AS grantor,
  sp.TYPE AS permission,
  CONVERT(nvarchar(46),suser_name(sp.grantee_principal_id)) AS grantee
FROM sys.server_permissions SP 
  INNER JOIN sys.endpoints ep  ON sp.major_id = ep.endpoint_id
AND EP.type = 4
ORDER BY Permission,grantor, grantee;

6. Проверьте наличие проблем с разрешением имен

Проверьте разрешение DNS, выполнив команду nslookup или Resolve-DnsName для соответствующих IP-адреса и имени:
```
nslookup <IP_Address>
nslookup <ServerName>
```
```
Resolve-DnsName  -Name <ServerName>
Resolve-DnsName  -Name <IP_address>
```
Разрешается ли имя в правильный IP-адрес? Разрешается ли IP-адрес в правильное имя?
Проверьте наличие записей в локальном файле HOSTS на каждом из узлов, которые могут указывать на неправильный сервер. Чтобы вывести на экран содержимое файла HOSTS, выполните следующую команду в командной строке:
```
type C:\WINDOWS\system32\drivers\etc\hosts
```
```
Get-Content 'C:\WINDOWS\system32\drivers\etc\hosts'
```
Проверьте, определены ли на репликах псевдонимы серверов, используемые клиентом.

7. Используйте свежую сборку SQL Server (рекомендуется последняя сборка)

Обновите версию SQL Server, чтобы предотвратить возникновение таких проблем, как KB3213703.

Дополнительные сведения см. в статье Создание группы доступности завершается сбоем с ошибкой 35250 "Не удалось присоединиться к базе данных"