Condividi tramite


MSSQLSERVER_35250

Si applica a: SQL Server

Dettagli

Attributo valore
Nome prodotto SQL Server
ID evento 35250
Origine evento MSSQLSERVER
Componente SQLEngine
Nome simbolico HADR_PRIMARYNOTACTIVE
Testo del messaggio La connessione alla replica primaria non è attiva. Il comando non può essere elaborato.

Spiegazione

Questo messaggio si verifica quando si tenta di aggiungere database secondari a un gruppo di disponibilità AlwaysOn. L'impossibilità di connettersi all'endpoint può in genere causare questo errore.

Azione utente

Opzione 1: Eseguire i passaggi direttamente in un notebook tramite Azure Data Studio

Informazioni su come installare Azure Data Studio

Opzione 2: seguire il passaggio manualmente**

Nota

Tutti i passaggi seguenti devono essere eseguiti sia nella replica primaria che nelle repliche secondarie problematiche.

1. Verificare che l'endpoint sia stato creato e avviato.

  • Eseguire la query seguente per individuare l'endpoint

    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
    

    Avviso

    Prestare attenzione quando si esegue il comando successivo perché può causare un tempo di inattività momentaneo per la replica.

  • È possibile usare questi comandi per riavviare l'endpoint individuato

    ALTER ENDPOINT hadr_endpoint STATE = STOPPED
    ALTER ENDPOINT hadr_endpoint STATE = STARTED
    

2. Controllare se è possibile connettersi all'endpoint

  • Usare telnet o Test-NetConnection per convalidare la connettività. Se l'endpoint è in ascolto e la connessione ha esito positivo, telnet mostrerà una schermata vuota con un cursore lampeggiante. In caso contrario, verrà visualizzato un errore di connessione da telnet. Per uscire da una connessione telnet riuscita, premere CTRL+]. Se si usa Test-NetConnection cercare o TcpTestSucceeded : True 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>
    

Problemi relativi al DNS:

Più processi in ascolto sulla stessa porta

  • Se la connessione telnet/Test-NetConnection funziona usando ServerName ma non riesce usando l'indirizzo IP, potrebbe essere presente più di un endpoint definito in tale server (un'altra istanza di SQL, ad esempio) configurato per l'ascolto su tale porta. Anche se lo stato dell'endpoint nell'istanza in questione mostra "STARTED" un'altra istanza potrebbe effettivamente avere l'associazione di porte e impedire all'istanza corretta di ascoltare e stabilire connessioni TCP. Per trovare il processo proprietario della porta 5022, ad esempio, eseguire questo comando:

    $port = "5022"
    Get-Process -Id (Get-NetTCPConnection -LocalPort $port).OwningProcess |Select-Object Name, ProductVersion, Path, Id
    

Endpoint bloccato (firewall, antivirus)

  • Se telnet o Test-NetConnection non riesce a connettersi, cercare firewall e/o software antivirus che potrebbe bloccare la porta dell'endpoint in questione. Controllare l'impostazione del firewall per verificare se è consentita la comunicazione della porta dell'endpoint tra le istanze del server che ospitano la replica primaria e la replica secondaria (porta 5022 per impostazione predefinita). Se si esegue SQL Server nella macchina virtuale di Azure, è anche necessario assicurarsi che il gruppo di sicurezza di rete (NSG) consenta il traffico verso la porta dell'endpoint. Controllare l'impostazione del firewall (e del gruppo di sicurezza di rete per la macchina virtuale di Azure) per verificare se è consentita la comunicazione della porta dell'endpoint tra le istanze del server che ospitano la replica primaria e la replica secondaria (porta 5022 per impostazione predefinita)

    Eseguire lo script di PowerShell seguente per verificare la presenza di regole di traffico in ingresso disabilitate

    Get-NetFirewallRule -Action Block -Enabled True -Direction Inbound |Format-Table
    
  • Acquisire un output netstat o Get-NetTCPConnection e verificare che lo stato sia LISTENING o ESTABLISHED in IP:Port per l'endpoint specificato

    netstat -a
    
    Get-NetTCPConnection -LocalPort <port_number>
    
  • È anche possibile trovare il processo proprietario della porta: eseguire un comando simile al seguente (ad esempio usando la porta 5022)

    $port = "5022"
    Get-Process -Id (Get-NetTCPConnection -LocalPort $port).OwningProcess |Select-Object Name, ProductVersion, Path, Id
    

3. Verificare la presenza di errori nel sistema

  • È possibile eseguire una query su sys.dm_hadr_availability_replica_states per individuare last_connect_error_number e diagnosticare più facilmente il problema di aggiunta. A seconda della replica in cui si è verificato un problema di comunicazione, è possibile eseguire query sia sul database primario che secondario:

    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
    

    Se il database secondario non è riuscito a comunicare con il server DNS, ad esempio o se la endpoint_url di una replica è stata configurata in modo non corretto durante la creazione del gruppo di disponibilità, è possibile ottenere i risultati seguenti nel last_connect_error_description:

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

4. Verificare che l'endpoint sia configurato per la porta/IP corretta per cui è definito il gruppo di disponibilità

  • Eseguire la query seguente sulla replica primaria e quindi su ogni replica secondaria che non riesce a connettersi. In questo modo è possibile trovare l'URL e la porta dell'endpoint

    select endpoint_url from sys.availability_replicas
    
  • Eseguire la query seguente per trovare gli endpoint e le porte

    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
    
  • Confrontare endpoint_url e porta da ogni query e assicurarsi che la porta del endpoint_url corrisponda alla porta definita per l'endpoint in ogni rispettiva replica

    Nota

    Se si usano indirizzi IP specifici per l'endpoint in ascolto, rispetto all'impostazione predefinita "Listen all", potrebbe essere necessario definire gli URL che usano l'indirizzo IP specifico anziché il nome di dominio completo.

5. Controllare se l'account del servizio di rete dispone dell'autorizzazione CONNECT per l'endpoint

  • Eseguire le query seguenti per elencare gli account che dispongono dell'autorizzazione di connessione all'endpoint nei server in questione e per visualizzare l'autorizzazione assegnata a ogni endpoint pertinente.

    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. Verificare la presenza di problemi di risoluzione dei nomi

  • Convalidare la risoluzione DNS usando nslookup o Resolve-DnsName sull'indirizzo IP e il nome:

    nslookup <IP_Address>
    nslookup <ServerName>
    
    Resolve-DnsName  -Name <ServerName>
    Resolve-DnsName  -Name <IP_address>
    
  • Il nome viene risolto nell'indirizzo IP corretto? L'indirizzo IP viene risolto nel nome corretto?

  • Verificare la presenza di voci di file HOSTS locali in ogni nodo che potrebbe puntare a un server non corretto. Dal prompt dei comandi stampare il file HOSTS usando questo comando:

    type C:\WINDOWS\system32\drivers\etc\hosts
    
    Get-Content 'C:\WINDOWS\system32\drivers\etc\hosts'
    
  • Controllare se sono presenti alias server per l'uso da parte di un client definito nelle repliche

7. Assicurarsi che SQL Server esegua una build recente (preferibilmente la build più recente)

  • Aggiornare le versioni di SQL Server per evitare problemi come KB3213703.

Per altre informazioni, vedere Creare un gruppo di disponibilità non riuscito con errore 35250 'Failed to join the database'