MSSQLSERVER_35250

Artículo
05/23/2023

Se aplica a: SQL Server

Detalles

Attribute	Valor
Nombre del producto	SQL Server
Id. de evento	35250
Origen de eventos	MSSQLSERVER
Componente	SQLEngine
Nombre simbólico	HADR_PRIMARYNOTACTIVE
Texto del mensaje	La conexión a la réplica principal no está activa. No se puede procesar el comando.

Explicación

Este mensaje se muestra al intentar unir bases de datos secundarias a un grupo de disponibilidad Always On. Habitualmente, la imposibilidad de conectarse al punto de conexión puede provocar este error.

Acción del usuario

Opción 1: Ejecute los pasos directamente en un cuaderno a través de Azure Data Studio

Apertura de un cuaderno en Azure Data Studio

Instalación de Azure Data Studio

Opción 2: Seguir el paso manualmente**

Nota:

Todos los pasos siguientes deben ejecutarse tanto en la réplica principal como en las réplicas secundarias problemáticas.

1. Asegúrese de que el punto de conexión se ha creado e iniciado.

Ejecute la siguiente consulta para detectar el punto de conexión:

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

Advertencia

Tenga cuidado al ejecutar el comando siguiente, ya que puede provocar un tiempo de inactividad momentáneo en la réplica.

Puede usar estos comandos para reiniciar el punto de conexión detectado.

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

2. Compruebe si puede conectarse al punto de conexión.

Utilice telnet o Test-NetConnection para validar la conectividad. Si el punto de conexión está escuchando y la conexión se realiza correctamente, telnet mostrará una pantalla en blanco con un cursor parpadeante. Si no es así, se le mostrará un error de conexión de telnet. Para salir de una conexión de Telnet correcta, presione CTRL+]. Si usa Test-NetConnection, busque TcpTestSucceeded : True o 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 de DNS:

Si la conexión telnet/Test-NetConnection se establece correctamente con la IP, pero no con ServerName, es posible que haya un problema de resolución de nombres o DNS. Vea Comprobación de problemas de resolución de nombres.

Varios procesos que escuchan en el mismo puerto

Si la conexión telnet/Test-NetConnection funciona usando ServerName, pero no usando la dirección IP, entonces es posible que haya más de un punto de conexión definido en ese servidor (quizás, otra instancia de SQL) que esté configurado para escuchar en ese puerto. Aunque el estado del punto de conexión de la instancia en cuestión muestra "STARTED" (INICIADO), otra instancia puede tener realmente el enlace de puerto e impedir que la instancia correcta escuche y establezca conexiones TCP. Para buscar el proceso propietario del puerto 5022, por ejemplo, ejecute este comando:
```
$port = "5022"
Get-Process -Id (Get-NetTCPConnection -LocalPort $port).OwningProcess |Select-Object Name, ProductVersion, Path, Id
```

Punto de conexión bloqueado (firewall o anti-virus)

Si telnet o Test-NetConnection no se conecta, compruebe si hay algún firewall o antivirus que pueda estar bloqueando el puerto del punto de conexión en cuestión. Compruebe la configuración de firewall para ver si permite la comunicación de puerto del punto de conexión entre las instancias de servidor que hospedan la réplica principal y la secundaria (el puerto 5022 de forma predeterminada). Si está ejecutando SQL Server en máquina virtual de Azure, además, deberá asegurarse de que el grupo de seguridad de red permita el tráfico al puerto del punto de conexión. Compruebe la configuración de firewall (y el grupo de seguridad de red, para la máquina virtual de Azure) para ver si permite la comunicación de puerto del punto de conexión entre las instancias de servidor que hospedan la réplica principal y la secundaria (el puerto 5022 de forma predeterminada).

Ejecute el siguiente script de PowerShell para comprobar las reglas de tráfico de entrada deshabilitadas.
```
Get-NetFirewallRule -Action Block -Enabled True -Direction Inbound |Format-Table
```
Capture una salida de netstat o Get-NetTCPConnection y compruebe que el estado es LISTENING o ESTABLISHED en el valor de IP:Port del punto de conexión especificado.
```
netstat -a
```
```
Get-NetTCPConnection -LocalPort <port_number>
```

También puede encontrar el proceso de propietario del puerto: ejecute un comando como este (por ejemplo, mediante el puerto 5022).

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

3. Compruebe si hay errores en el sistema.

Puede consultar la vista de administración única sys.dm_hadr_availability_replica_states de last_connect_error_number, que puede ayudarle a diagnosticar el problema de combinación. Dependiendo de cuál era la réplica con dificultades para comunicarse, puede consultar tanto la réplica principal como la secundaria:
```
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 ejemplo, si la secundaria no pudo comunicarse con el servidor DNS o si el parámetro endpoint_url de una réplica se configuró incorrectamente al crear el grupo de disponibilidad, es posible que obtenga los siguientes resultados en last_connect_error_description:

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

4. Asegúrese de que el punto de conexión esté configurado para la dirección IP o el puerto correctos para los que se ha definido el grupo de disponibilidad.

Ejecute la siguiente consulta en la réplica principal y, a continuación, en cada réplica secundaria que no se pueda conectar. Esto lo ayudará a encontrar el puerto y la dirección URL del punto de conexión.
```
select endpoint_url from sys.availability_replicas
```

Ejecute la consulta siguiente para buscar los puntos de conexión y los puertos:

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 y el puerto de cada consulta, y asegúrese de que el puerto de endpoint_url coincida con el puerto definido para el punto de conexión en cada réplica correspondiente.

Nota:

Si usa direcciones IP específicas para que el punto de conexión escuche, frente al valor predeterminado de "escuchar todo", es posible que tenga que definir direcciones URL que usen la dirección IP específica en lugar del FQDN.

5. Compruebe si la cuenta de servicio de red tiene permiso de conexión al punto de conexión.

Ejecute las consultas que hay a continuación para enumerar las cuentas que tienen permiso de conexión al punto de conexión en los servidores concretos, así como para mostrar el permiso asignado a cada punto de conexión 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. Compruebe si hay problemas de resolución de nombres.

Valide la resolución DNS mediante nslookup o Resolve-DnsName en la dirección IP y el nombre:

nslookup <IP_Address>
nslookup <ServerName>

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

¿El nombre se resuelve con la dirección IP correcta? ¿La dirección IP se resuelve con el nombre correcto?
Compruebe si hay entradas del archivo HOSTS local en cada nodo que puedan estar apuntando a un servidor incorrecto. En el símbolo del sistema, imprima el archivo HOSTS con lo siguiente:
```
type C:\WINDOWS\system32\drivers\etc\hosts
```
```
Get-Content 'C:\WINDOWS\system32\drivers\etc\hosts'
```
Compruebe si hay definidos alias de servidor para que los use un cliente en las réplicas.

7. Asegúrese de que su instancia de SQL Server está ejecutando una compilación reciente (preferiblemente, la más reciente).

Actualice SQL Server para protegerse frente a problemas como KB3213703.

Para obtener más información, consulte No se pudo crear un grupo de disponibilidad; error 35250 "No se pudo combinar la base de datos".

Compartir a través de