Partilhar via


MSSQLSERVER_35250

Aplica-se: SQL Server

Detalhes

Atributo Valor
Nome do produto SQL Server
ID do evento 35250
Origem do Evento MSSQLSERVER
Componente SQLEngine
Nome simbólico HADR_PRIMARYNOTACTIVE
Texto da mensagem A conexão com a réplica primária não está ativa. O comando não pode ser processado.

Explicação

Essa mensagem é exibida ao tentar unir bancos de dados secundários a um grupo de disponibilidade Always On. A incapacidade de se conectar ao ponto de extremidade normalmente pode causar esse erro.

Ação do usuário

Opção 1: executar as etapas diretamente em um notebook usando o Azure Data Studio

Saiba como instalar o Azure Data Studio

Opção 2: seguir a etapa manualmente**

Observação

Todas as etapas a seguir devem ser executadas na réplica Primária e nas réplicas Secundárias problemáticas.

1. Verificar se o ponto de extremidade foi criado e iniciado.

  • Execute a consulta a seguir para descobrir o ponto de extremidade.

    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
    

    Aviso

    Tenha cuidado ao executar o próximo comando, pois isso pode causar um tempo de inatividade momentâneo na réplica.

  • Você pode usar esses comandos para reiniciar o ponto de extremidade descoberto.

    ALTER ENDPOINT hadr_endpoint STATE = STOPPED
    ALTER ENDPOINT hadr_endpoint STATE = STARTED
    

2. Verificar se você pode se conectar ao ponto de extremidade

  • Use telnet ou Test-NetConnection para validar a conectividade. Se o ponto de extremidade estiver ouvindo e a conexão for bem-sucedida, o telnet mostrará uma tela em branco com um cursor piscando. Caso contrário, você receberá um erro de conexão do telnet. Para sair de uma conexão telnet bem-sucedida, pressione CTRL +]. Se você usar o Test-NetConnection, procure TcpTestSucceeded : True ou 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>
    

Problemas com o DNS:

Vários processos escutando na mesma porta

  • Se a conexão do telnet/Test-NetConnection funcionar usando o ServerName, mas não funcionar usando o endereço IP, pode haver mais de um ponto de extremidade definido no servidor (talvez outra instância SQL) que esteja configurado para escutar nessa porta. Embora o status do ponto de extremidade na instância em questão mostre "INICIADO", outra instância pode realmente ter a associação de porta e impedir que a instância correta escute e estabeleça conexões TCP. Para encontrar o processo de propriedade da porta 5022, por exemplo, execute este comando:

    $port = "5022"
    Get-Process -Id (Get-NetTCPConnection -LocalPort $port).OwningProcess |Select-Object Name, ProductVersion, Path, Id
    

Ponto de extremidade bloqueado (firewall, antivírus)

  • Se o telnet ou Test-NetConnection falhar ao se conectar, procure o firewall e/ou software antivírus que possa estar bloqueando a porta do ponto de extremidade em questão. Verifique a configuração do firewall para ver se ele permite comunicação da porta do ponto de extremidade entre as instâncias do servidor que hospedam a réplica primária e secundária (por padrão, a porta 5022). Se você estiver executando o SQL Server na VM do Azure, além disso, precisará garantir que o NSG (grupo de segurança de rede) permita o tráfego para a porta do ponto de extremidade. Verifique a configuração do firewall (e NSG para VM do Azure) para ver se ele permite comunicação da porta do ponto de extremidade entre as instâncias do servidor que hospedam a réplica primária e secundária (por padrão, a porta 5022).

    Execute o script do PowerShell a seguir para verificar as regras de tráfego de entrada desabilitadas

    Get-NetFirewallRule -Action Block -Enabled True -Direction Inbound |Format-Table
    
  • Capture uma saída netstat ou Get-NetTCPConnection e verifique se o status está em ESCUTA ou ESTABELECIDO na Porta IP para o ponto de extremidade especificado

    netstat -a
    
    Get-NetTCPConnection -LocalPort <port_number>
    
  • Você também pode encontrar o processo de propriedade da porta: execute um comando como este (por exemplo, usando a porta 5022)

    $port = "5022"
    Get-Process -Id (Get-NetTCPConnection -LocalPort $port).OwningProcess |Select-Object Name, ProductVersion, Path, Id
    

3. Verificar se há erros no sistema

  • Você pode consultar o sys.dm_hadr_availability_replica_states pelo last_connect_error_number, que pode ajudar você a diagnosticar o problema de ingresso. Dependendo de qual réplica estava tendo dificuldade de comunicação, você pode consultar a primária e a secundária:

    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
    

    Por exemplo, se a secundária não puder se comunicar com o servidor DNS ou se a endpoint_url de uma réplica for configurada incorretamente ao criar o grupo de disponibilidade, você poderá obter os seguintes resultados no last_connect_error_description:

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

4. Verificar se o ponto de extremidade está configurado para o IP/porta correto para o qual o AG está definido

  • Execute a consulta a seguir na primária e, em seguida, em cada réplica secundária que está falhando na conexão. Isso o ajudará a localizar a URL e a porta do ponto de extremidade.

    select endpoint_url from sys.availability_replicas
    
  • Execute a consulta a seguir para localizar os pontos de extremidade e as portas.

    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
    
  • Compare endpoint_url e a porta de cada consulta e verifique se a porta da endpoint_url corresponde à porta definida para o ponto de extremidade em cada réplica correspondente.

    Observação

    Se você estiver usando endereços IP específicos para o ponto de extremidade escutar, em vez do padrão de "ouvir tudo", talvez seja necessário definir URLs que usem o endereço IP específico em vez do FQDN.

5. Verificar se a conta de serviço de rede tem permissão CONNECT para o ponto de extremidade

  • Execute as consultas a seguir para listar as contas que têm permissão de conexão para o ponto de extremidade no(s) servidor(es) em questão e para mostrar a permissão atribuída a cada ponto de extremidade relevante.

    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. Verificar se há problemas de resolução de nomes

  • Valide a resolução DNS usando nslookup ou Resolve-DnsName no endereço IP e o nome:

    nslookup <IP_Address>
    nslookup <ServerName>
    
    Resolve-DnsName  -Name <ServerName>
    Resolve-DnsName  -Name <IP_address>
    
  • O nome resolve para o endereço IP correto? O endereço IP resolve para o nome correto?

  • Verifique se há entradas de arquivo HOSTS locais em cada nó que podem estar apontando para um servidor incorreto. No Prompt de Comando, imprima o arquivo HOSTS usando:

    type C:\WINDOWS\system32\drivers\etc\hosts
    
    Get-Content 'C:\WINDOWS\system32\drivers\etc\hosts'
    
  • Verifique se há Aliases de Servidor para Uso por um Cliente definido nas réplicas.

7. Garantir que o seu SQL Server está funcionando em um build recente (preferencialmente o build mais recente)

  • Atualize as versões do SQL Server para proteger contra problemas como KB3213703.

Para saber mais, confira Criar Falhas de Grupo de Disponibilidade com o Erro 35250 "Falha ao ingressar no banco de dados"