MSSQLSERVER_35250

Artigo
05/23/2023

Aplica-se a: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 localizar o processo proprietário 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: executar 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 comparação com o padrão de "escutar tudo", talvez seja necessário definir URLs que usam 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. Verifique se o SQL Server está executando 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"

Share via