MSSQLSERVER_35250

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

Cette erreur se produit lorsque vous essayez de joindre des bases de données secondaires à un groupe de disponibilité Always On, mais que vous ne pouvez pas vous connecter au point de terminaison.

Action utilisateur

Remarque

Exécutez toutes les étapes suivantes sur le réplica principal et 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 AS tep
     INNER JOIN sys.server_principals AS sp
         ON tep.principal_id = sp.principal_id
WHERE tep.type = 4;

Avertissement

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

Utilisez 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 écoute et que la connexion réussit, telnet affiche un écran vide avec un curseur clignotant. Si ce n’est pas le cas, vous recevez une erreur de connexion 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 ou Test-NetConnection réussit à l’adresse IP, mais ne parvient pas à le ServerNamefaire, il existe probablement un problème de résolution dns ou de nom. Consultez Rechercher les problèmes de résolution de noms.

Plusieurs processus à l’écoute sur le même port

Si telnet ou Test-NetConnection fonctionne à l’aide ServerName, mais échouez à l’aide de l’adresse IP, il peut y avoir plusieurs points de terminaison définis sur ce serveur (une autre instance SQL peut-être) configurée pour écouter sur ce port. Bien que l’état du point de terminaison sur l’instance en question indique STARTED, une autre instance peut réellement avoir la liaison de port et empêcher l’instance correcte d’écouter et d’établir des connexions TCP. Pour rechercher le processus propriétaire du port 5022, 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 les logiciels 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 vérifier que le groupe de sécurité réseau (NSG) autorise le trafic vers le port du point de terminaison. Vérifiez le paramètre de pare-feu et de groupe de sécurité réseau (pour machine virtuelle Azure) pour voir s’il autorise la communication entre les ports de 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écutez le script PowerShell suivant pour vérifier 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 un LISTENING ou ESTABLISHED sur le IP:Port point de terminaison spécifié :

netstat -a

Get-NetTCPConnection -LocalPort <port_number>

Vous pouvez également trouver le processus propriétaire du 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 le sys.dm_hadr_availability_replica_states DMV pour le last_connect_error_number problème de jointure qui peut vous aider à diagnostiquer le problème de jointure. Selon le réplica qui rencontre des problèmes de communication, vous pouvez interroger les réplicas principaux et secondaires.

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 AS rs
     INNER JOIN sys.availability_replicas AS r
         ON rs.replica_id = r.replica_id
WHERE rs.is_local = 1;

Si le réplica secondaire ne peut pas communiquer avec le serveur DNS, par exemple, ou si les réplicas endpoint_url sont configurés de manière incorrecte lors de la création du groupe de disponibilité, vous pouvez voir les résultats suivants dans les last_connect_error_descriptionrésultats suivants :

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

4. Vérifiez que le point de terminaison est configuré pour l’adresse IP et le port appropriés définis par le groupe de disponibilité pour

Exécutez la requête suivante sur le réplica principal, puis sur chaque réplica secondaire qui ne parvient pas à se connecter. Cette requête vous aide à 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 AS tep
      INNER JOIN sys.server_principals AS sp
          ON tep.principal_id = sp.principal_id
WHERE tep.type = 4;

Comparez et portez endpoint_url à partir de chaque requête. Vérifiez que le port à partir des correspondances correspond au port que vous avez défini pour le point de endpoint_url terminaison sur chaque réplica respectif.

Remarque

Si vous utilisez des adresses IP spécifiques pour que le point de terminaison écoute, au lieu de 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 répertorier les comptes disposant d’une autorisation de connexion au point de terminaison sur 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 AS perm
      LEFT OUTER JOIN sys.server_principals AS prin
          ON perm.grantee_principal_id = prin.principal_id
      LEFT OUTER JOIN sys.tcp_endpoints AS 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 AS SP
      INNER JOIN sys.endpoints AS 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 en adresse IP correcte ? L’adresse IP est-elle résolue en nom correct ?

Recherchez les entrées de fichier HOSTS locales sur chaque nœud qui peut pointer vers un serveur incorrect. À partir de la ligne de commande, imprimez le fichier HOSTS à l’aide de cette commande :

type C:\WINDOWS\system32\drivers\etc\hosts

Get-Content 'C:\WINDOWS\system32\drivers\etc\hosts'

Vérifiez s’il existe un alias de serveur créé ou supprimé pour une utilisation par un client défini sur les réplicas

7. Vérifiez que votre serveur SQL Server exécute une build récente

Recherchez la dernière build.

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

Pour plus d’informations, consultez Échec de la création d’un groupe de disponibilité avec l’erreur 35250 « Échec de la jointure de la base de données »

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2026-01-27