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

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**

Remarque

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 prochaine commande, 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, 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 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 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 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 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 sur chaque réplica secondaire qui ne parvient pas à se connecter. Cela vous permet de 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, puis vérifiez que endpoint_url correspond au port défini pour le point de terminaison sur chaque réplica respectif

  Remarque

  Si vous utilisez des adresses IP spécifiques pour le point de terminaison à écouter, par rapport à la valeur par défaut « écouter tout », 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 en adresse IP correcte ? L’adresse IP est-elle résolue en 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érifier que votre serveur SQL Server exécute une build récente (de préférence la build la plus récente)

• 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 »