MSSQLSERVER_35250

Article
05/23/2023

S’applique à :SQL Server

Détails

Attribut	Valeur
Nom du produit	SQL Server
ID de l’événement	35250
Source de l’événement	MSSQLSERVER
Composant	SQLEngine
Nom symbolique	HADR_PRIMARYNOTACTIVE
Texte du message	La connexion au réplica principal n’est pas active. Impossible de traiter la commande.

Explication

Ce message s’affiche quand vous tentez de joindre des bases de données secondaires à un groupe de disponibilité Always On. L’impossibilité de se connecter au point de terminaison peut généralement provoquer cette erreur.

Action de l'utilisateur

Option 1 : Exécuter les étapes directement dans un notebook via Azure Data Studio

Ouvrir un notebook dans Azure Data Studio

Installer Azure Data Studio

Option 2 : Suivre l’étape manuellement**

Notes

Toutes les étapes suivantes doivent être exécutées sur le réplica principal et sur le ou les réplicas secondaires problématiques.

1. Vérifiez que le point de terminaison est créé et démarré.

Exécutez la requête suivante pour découvrir le point de terminaison

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

Avertissement

Soyez prudent lors de l’exécution de la commande suivante, car elle peut entraîner un temps d’arrêt momentané pour le réplica.

Vous pouvez utiliser ces commandes pour redémarrer le point de terminaison que vous avez découvert
```
ALTER ENDPOINT hadr_endpoint STATE = STOPPED
ALTER ENDPOINT hadr_endpoint STATE = STARTED
```

2. Vérifiez si vous pouvez vous connecter au point de terminaison

Utilisez Telnet ou Test-NetConnection pour valider la connectivité. Si le point de terminaison est en train d’écouter et que la connexion réussit, telnet vous montre un écran vide avec un curseur qui clignote. Si ce n’est pas le cas, vous recevez une erreur de connexion de la part de telnet. Pour quitter une connexion telnet réussie, appuyez sur CTRL+]. Si vous utilisez Test-NetConnection, recherchez 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>
```

Problèmes DNS :

Si telnet/Test-NetConnection réussit sur l’adresse IP, mais échoue sur ServerName, il y a probablement un problème de résolution de noms ou DNS. Voir Rechercher les problèmes de résolution de noms

Plusieurs processus écoutent sur le même port

Si la connexion telnet/Test-NetConnection fonctionne avec ServerName, mais échoue avec l’adresse IP, il peut y avoir plusieurs points de terminaison définis sur ce serveur (peut-être une autre instance SQL) qui sont configurés pour écouter sur ce port. Bien que l’état du point de terminaison sur l’instance en question indique « STARTED », une autre instance peut en fait avoir la liaison de port et empêcher l’instance appropriée d’écouter et d’établir des connexions TCP. Pour rechercher le processus propriétaire du port 5022, par exemple, exécutez cette commande :
```
$port = "5022"
Get-Process -Id (Get-NetTCPConnection -LocalPort $port).OwningProcess |Select-Object Name, ProductVersion, Path, Id
```

Point de terminaison bloqué (pare-feu, antivirus)

Si telnet ou Test-NetConnection ne parvient pas à se connecter, recherchez le pare-feu et/ou le logiciel antivirus susceptibles de bloquer le port du point de terminaison en question. Vérifiez le paramètre du pare-feu pour voir s’il permet la communication de port du point de terminaison entre les instances de serveur qui hébergent le réplica principal et le réplica secondaire (port 5022 par défaut). Si vous exécutez SQL Server sur une machine virtuelle Azure, vous devez également vous assurer que le groupe de sécurité réseau (NSG) autorise le trafic vers le port du point de terminaison. Vérifiez le paramètre du pare-feu (et le NSG pour la machine virtuelle Azure) pour voir s’il permet la communication de port du point de terminaison entre les instances de serveur qui hébergent le réplica principal et le réplica secondaire (port 5022 par défaut)

Exécuter le script PowerShell suivant pour rechercher les règles de trafic entrant désactivées
```
Get-NetFirewallRule -Action Block -Enabled True -Direction Inbound |Format-Table
```
Capturez une sortie netstat ou Get-NetTCPConnection et vérifiez que l’état est LISTENING ou ESTABLISHED sur l’élément IP:Port du point de terminaison spécifié
```
netstat -a
```
```
Get-NetTCPConnection -LocalPort <port_number>
```
Vous pouvez également trouver le processus de propriétaire de port : exécutez une commande comme celle-ci (par exemple, à l’aide du port 5022)
```
$port = "5022"
Get-Process -Id (Get-NetTCPConnection -LocalPort $port).OwningProcess |Select-Object Name, ProductVersion, Path, Id
```

3. Rechercher les erreurs dans le système

Vous pouvez interroger sys.dm_hadr_availability_replica_states pour connaître le paramètre last_connect_error_number qui peut vous aider à diagnostiquer le problème de jointure. En fonction du réplica qui a rencontré des difficultés pour communiquer, vous pouvez interroger le réplica principal et le réplica secondaire :
```
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
```
Si le réplica secondaire n’a pas pu communiquer avec le serveur DNS, par exemple, ou si le paramètre endpoint_url d’un réplica a été configuré de façon incorrecte lors de la création du groupe de disponibilité, vous pouvez obtenir les résultats suivants dans le paramètre last_connect_error_description :

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

4. Vérifier que le point de terminaison est configuré pour l’adresse IP/le port pour lequel le groupe de disponibilité est défini

Exécutez la requête suivante sur le réplica principal, puis chaque réplica secondaire qui ne parvient pas à se connecter. Cela vous aidera à trouver l’URL et le port du point de terminaison.
```
select endpoint_url from sys.availability_replicas
```

Exécutez la requête suivante pour rechercher les points de terminaison et les ports

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

Comparez les paramètres endpoint_url et port de chaque requête et assurez-vous que le port du paramètre endpoint_url correspond au port défini pour le point de terminaison sur chaque réplica respectif.

Notes

Si vous utilisez des adresses IP spécifiques pour le point de terminaison sur lequel écouter, par opposition à la valeur par défaut « listen all », vous devrez peut-être définir des URL qui utilisent l’adresse IP spécifique plutôt que le nom de domaine complet.

5. Vérifier si le compte de service réseau dispose de l’autorisation CONNECT sur le point de terminaison

Exécutez les requêtes suivantes pour lister les comptes qui ont l’autorisation de connexion sur le point de terminaison sur le ou les serveurs en question, et pour afficher l’autorisation attribuée à chaque point de terminaison approprié.

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. Rechercher les problèmes de résolution de noms

Validez la résolution DNS à l’aide de nslookup ou de Resolve-DnsName sur l’adresse IP et le nom :

nslookup <IP_Address>
nslookup <ServerName>

Resolve-DnsName  -Name <ServerName>
Resolve-DnsName  -Name <IP_address>

Le nom est-il résolu sur l’adresse IP correcte ? L’adresse IP est-elle résolue sur le nom correct ?
Recherchez les entrées du fichier HOSTS local sur chaque nœud pouvant pointer vers un serveur incorrect. À partir de l’invite de commandes, imprimez le fichier HOSTS en utilisant ce qui suit :
```
type C:\WINDOWS\system32\drivers\etc\hosts
```
```
Get-Content 'C:\WINDOWS\system32\drivers\etc\hosts'
```
Vérifiez s’il existe des alias de serveur pour une utilisation par un client définis sur les réplicas

7. Vérifiez que votre SQL Server exécute une build récente (de préférence la dernière version)

Mettez à jour les versions SQL Server pour éviter de rencontrer des problèmes comme KB3213703.

Pour plus d’informations, reportez-vous à Échec de la création d’un groupe de disponibilité avec l’erreur 35250 « Impossible de joindre la base de données »