MSSQLSERVER_35250

Применимо к: SQL Server (все поддерживаемые версии)

Сведения

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

Пояснение

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

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

Вариант 1. Выполнение действий непосредственно в записной книжке с помощью 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-адресу, возможно, на этом сервере определено несколько конечных точек (например, другой экземпляр 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 "Не удалось присоединиться к базе данных"