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

Abrir o notebook no 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:

• Se o telnet/Test-NetConnection funcionar com o endereço IP, mas não funcionar com o ServerName, provavelmente há um problema de resolução de nome ou de DNS. Consulte Verificar se há problemas de resolução de nomes

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"