Para agentes de IA: hay un índice de documentación disponible en https://www.mongodb.com/es/docs/llms.txt — versiones en markdown de todas las páginas están disponibles agregando .md a cualquier ruta URL.
Docs Menu

Solucionar problemas de conexión de los nodos privados

Nota

Esta página se aplica tanto a Atlas Infinite como a Atlas Core.

Revise las secciones de esta página para diagnosticar y resolver problemas comunes de conexión de nodos privados.

1

Para ver el estado de cada nodo privado:

  1. En Atlas, se debe ir a la página Database & Network Access del proyecto.

    1. Si aún no aparece, se debe seleccionar la organización que contiene el proyecto en el menú Organizations de la barra de navegación.

    2. Si aún no se muestra, seleccione su proyecto en el menú Projects de la barra de navegación.

    3. En la barra lateral, haz clic en Database & Network Access en la sección Security.

      La página Acceso a la base de datos y a la red se muestra.

  2. En la barra lateral, haga clic en Private Endpoint.

  3. Revisa los estados.

    Los campos Atlas Endpoint Service Status y Endpoint Status muestran el estado de cada nodo privado.

Consulta los siguientes estados para ayudarte a determinar el estado de tus conexiones de nodos privados:

Atlas Endpoint Service Status

Estado
Descripción

Crear vínculo privado

Atlas está creando el equilibrador de carga de red y los recursos VPC.

Fallido

Se ha producido un fallo del sistema.

Disponible

El balanceador de carga de red Atlas y el servicio de endpoint VPC han sido creados y están listos para recibir solicitudes de conexión.

Borrando

Atlas está borrando el servicio de nodo privado.

Endpoint Status

Estado
Descripción

No configurado

Atlas creó el balanceador de carga de red y el servicio de punto final de VPC, pero AWS aún no ha creado el punto final de interfaz. Haga clic en Edit y complete el asistente para crear el punto final de interfaz.

Aceptación pendiente

AWS ha recibido la solicitud de conexión desde su endpoint de la interfaz al servicio de endpoint VPC de Atlas.

Pendiente

AWS está estableciendo la conexión entre tu endpoint de la interfaz y el servicio de puntos finales de Atlas VPC.

Fallido / Rechazado

AWS no pudo establecer una conexión entre los recursos de Atlas VPC y el punto final de la interfaz en su VPC. Este estado puede aparecer como Failed o Rejected según el motivo del error.

Las causas comunes incluyen:

  • Falta la región de la lista de regiones de puntos finales aceptadas

  • ID de Endpoint VPC incorrecto

  • Problemas transitorios de AWS

Si ha confirmado que su configuración es correcta y el fallo se debe a retrasos temporales de AWS, puede usar el botón Retry en la interfaz de usuario de Atlas para volver a intentar la conexión. Si el problema persiste, haga clic en Edit para corregir el ID del punto final o verifique que la región del punto final esté incluida en las regiones de puntos finales aceptadas.

Para obtener más información sobre la solución de problemas de nodos privados con errores, consulte Solucionar problemas de conexión de nodos privados.

IMPORTANTE: Si tu Endpoint de Interfaz falla, es posible que veas el siguiente mensaje:

No dns entries found for endpoint vpce-<guid>,
your endpoint must be provisioned in at least one subnet.
Click "Edit" to fix the problem.

Este mensaje indica que no especificó una subred cuando creó la conexión de AWS PrivateLink. Para resolver este error:

  1. Haga clic en Edit.

  2. Haga clic en Back.

  3. Especifica al menos una subred.

  4. Sigue las instrucciones restantes para crear la conexión AWS PrivateLink.

Disponible

Los recursos de Atlas VPC están conectados al endpoint de la interfaz en su VPC. Puedes conectarte a los clústeres de Atlas en esta región usando AWS PrivateLink.

Borrando

Atlas está removiendo el punto de conexión de la interfaz del servicio de punto de conexión privado.

2
  1. Para que cada recurso se conecte a sus clústeres de Atlas utilizando AWS PrivateLink, el grupo de seguridad del recurso debe permitir el tráfico saliente a las direcciones IP privadas del endpoint de la interfaz en todos los puertos (1024-65535).

    Para aprender más, se puede consultar Agregar reglas a un grupo de seguridad.

  2. Tu grupo de seguridad del endpoint de interfaz debe permitir el tráfico entrante en todos los puertos desde cada recurso que necesite conectarse a tus clústeres de Atlas usando AWS PrivateLink.

    Direcciones IP de instancia de lista de acceso o grupos de seguridad para permitir que el tráfico proveniente de ellas llegue al grupo de seguridad del endpoint de la interfaz.

Las siguientes secciones describen los problemas comunes de conectividad entre nodos privados de diferentes regiones y cómo resolverlos.

Si olvidaste especificar la región donde se encuentra el endpoint de consumo durante el envío, el estado del endpoint en Atlas pasa a Failed o Rejected porque el servicio de endpoint no puede localizar ni aceptar la conexión.

Para resolver este problema:

1

Agregue la región faltante a la lista de regiones de endpoint aceptadas. Para obtener más información, consulte Administrar regiones de endpoint aceptadas.

2

Después de agregar la región, regresa a la tarjeta del servicio de endpoint y haz clic en el botón Retry al lado de la entrada de endpoint fallida.

Advertencia

No borres un punto de enlace fallido si es el único nodo registrado con ese servicio privado de nodo. Si eliminas el último endpoint, todo el servicio de endpoint se elimina automáticamente y debes reiniciar todo el proceso de configuración.

Si envía un ID de punto final de AWS VPC incorrecto (por ejemplo, un error tipográfico o un ID de un servicio o VPC diferente), el estado del punto final en Atlas cambia a Failed o Rejected porque el servicio de punto final no puede localizar ni aceptar la conexión.

Este problema se puede resolver utilizando uno de los siguientes métodos.

Para corregir el ID en la entrada de punto final existente:

1

En la tarjeta del servicio de endpoint, encuentra la entrada de endpoint fallida.

2
  1. Haga clic en el botón Edit en la columna Actions.

  2. En el modal, actualiza el campo VPC Endpoint ID con la ID correcta.

  3. Haga clic en Save para actualizar el ID.

    Atlas intenta aceptar el endpoint correcto.

Para reemplazar la entrada fallida con un nuevo punto final:

1

Agrega un nuevo endpoint usando el ID de endpoint correcto. Para obtener más información, consulta Configura un extremo privado para un clúster dedicado.

2

Una vez que se acepte el endpoint correcto con éxito (el estado se mostrará como Available), puedes borrar la entrada fallida del endpoint.

Advertencia

No borres un punto de enlace fallido si es el único nodo registrado con ese servicio privado de nodo. Si eliminas el último endpoint, todo el servicio de endpoint se elimina automáticamente y debes reiniciar todo el proceso de configuración.

Si falla un envío de punto de conexión y ya has verificado que:

  • La región necesaria está incluida en las regiones de endpoints aceptadas para el servicio de nodos privados.

  • El ID del punto final enviado es correcto y corresponde al punto final de VPC que creó en AWS.

El fallo podría deberse a un problema transitorio de AWS o a un error en el proceso de aceptación inicial.

Nota

Incluso después de que el punto final se encuentre en el estado Pending Acceptance en AWS, puede haber un ligero retraso en la actualización de todos los recursos en segundo plano. Los puntos finales entre regiones, en particular, podrían tardar 30 segundos adicionales en ser detectables por el servicio de puntos finales de Atlas en una región diferente.

Para resolver este problema:

1

En la tarjeta del servicio de terminales, localice la entrada de terminal fallida (el estado se muestra como Failed o Rejected).

2

Haz clic en el botón Retry en la columna Actions para intentar establecer la conexión nuevamente.

Advertencia

No borres un punto de enlace fallido si es el único nodo registrado con ese servicio privado de nodo. Si eliminas el último endpoint, todo el servicio de endpoint se elimina automáticamente y debes reiniciar todo el proceso de configuración.

Cuando un cliente en la VPC se conecta a un clúster de Atlas utilizando una de estas cadenas de conexión con reconocimiento de nodo privado, el cliente intenta establecer una conexión con el balanceador de carga en la VPC de Atlas a través de uno de los endpoints de la interfaz. El mecanismo de resolución de DNS del cliente gestiona a qué endpoint de la interfaz se resuelve el nombre de host. Si un endpoint de la interfaz no está disponible, se utiliza el siguiente. Esto es opaco para el driver o cualquier otro mecanismo de conexión. El driver solo es consciente del nombre de host en el registro SRV o en la cadena de conexión.

Registro SRV para cadenas de conexión con reconocimiento de nodos de la lista de semillas DNS

El siguiente ejemplo muestra el registro SRV para un clúster de una sola región habilitado para AWS PrivateLink, mostrando tres puertos únicos definidos para pl-0-us-east-1.k45tj.mongodb.net:

$ nslookup -type=SRV _mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
_mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1026 pl-0-us-east-1.k45tj.mongodb.net.
_mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1024 pl-0-us-east-1.k45tj.mongodb.net.
_mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1025 pl-0-us-east-1.k45tj.mongodb.net.

En el ejemplo precedente:

  • _mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net es el registro SRV al que hace referencia la cadena de conexión de mongodb+srv://cluster0-pl-0.k45tj.mongodb.net.

  • pl-0-us-east-1.k45tj.mongodb.net es el nombre de host de cada nodo en un clúster de Atlas en una región para la cual has configurado AWS PrivateLink.

  • 1024, 1025 y 1026 son puertos únicos que Atlas asigna en el balanceador de carga para cada nodo del set de réplicas de Atlas en la región para la que has habilitado AWS PrivateLink. Todos los nodos en un set de réplicas de Atlas son accesibles a través del mismo nombre de host, donde el balanceador de carga resuelve los nodos individuales por su puerto único.

Resolución de DNS del nombre de host en cadenas de conexión y registros SRV con reconocimiento de nodos privados

El nombre de host en el registro SRV y la cadena de conexión estándar es un registro DNS Canonical Name (CNAME) que se resuelve al nombre DNS regional específico del punto final que AWS genera para el punto final de la interfaz. Existe un registro DNS ALIAS para cada subred de su VPC en la que implementó el punto final de la interfaz. Cada registro ALIAS contiene la dirección IP privada del punto final de la interfaz para esa subred.

El siguiente ejemplo muestra la búsqueda DNS del nombre de host en el registro SRV y en la cadena de conexión estándar, incluyendo el nombre DNS regional específico del punto final para el punto final de la interfaz y sus registros DNS ALIAS:

$ nslookup pl-0-us-east-1.k45tj.mongodb.net
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
pl-0-us-east-1.k45tj.mongodb.net
canonical name = vpce-024f5b57108c8d3ed-ypwbxwll.vpce-svc-02863655456245e5c.us-east-1.vpce.amazonaws.com.
Name: vpce-024f5b57108c8d3ed-ypwbxwll.vpce-svc-02863655456245e5c.us-east-1.vpce.amazonaws.com
Address: 10.0.30.194
Name: vpce-024f5b57108c8d3ed-ypwbxwll.vpce-svc-02863655456245e5c.us-east-1.vpce.amazonaws.com
Address: 10.0.20.54
$ mongosh "mongodb+srv://aws-replica-set-7-pl-0-lb.22qdu.mongodb-dev.net/" --apiVersion 1 --username sarah
Enter password: *****
Current Mongosh Log ID: 68910f1754be6d9adc74e399
Connecting to: mongodb+srv://<credentials>@aws-replica-set-7-pl-0-lb.22qdu.mongodb-dev.net/?appName=mongosh+2.5.6
MongoNetworkError: Client network socket disconnected before secure TLS connection was established
{"t":{"$date":"2025-08-04T19:48:17.649+00:00"},"s":"I", "c":"NETWORK",
"id":22942, "ctx":"listener","msg":"Connection refused because there are
too many open connections","attr":{"remote":"54.172.143.8:33205",
"isLoadBalanced":false,"uuid":{"uuid":{"$uuid":"e52e9c14-7648-430a-bc2e-95292347b7e0"}},
"connectionId":380,"connectionCount":58}}
  • Puedes ver la IP de origen del cliente en los registros mongos de los clústeres particionados que se conectan a través de nodos privados.

  • Puedes ver la IP de origen del cliente en los registros de mongod para los sets de réplicas que se conectan a través de nodos privados.

  • Puedes ver la IP de origen del cliente en los registros de auditoría para ambos set de réplicas y clústeres fragmentados que se conectan a través de Endpoints Privados.

  • Esta funcionalidad es compatible con AWS para las siguientes versiones:

    • 8.1 y v8.1.0+

    • 8.0 y v8.0.10+

    • 7.0 y v7.0.22+

  • La dirección IP de origen del cliente y el puerto se indican en el campo sourceClient. Ese valor es 10.50.4.23 en el ejemplo anterior.

    {"t":{"$date":"2025-07-21T12:15:42.123+00:00"},"s":"I","c":"NETWORK",
    "id":22943,"ctx":"listener","msg":"Connection accepted","attr":{"remote":"192.168.100.55:31245",
    "isLoadBalanced":true,"sourceClient":"10.50.4.23:50123","uuid":{"uuid":{"$uuid":"12345678-abcd-4321-abcd-87654321abcd"}},
    "connectionId":345,"connectionCount":19}}

Reunir estos detalles requiere usar la herramienta jq, que se puede descargar del sitio web jq.

La siguiente query proporciona el número de conexiones creadas desde una dirección IP de cliente en particular. Puedes recopilar la dirección IP privada exacta de origen de la VPC utilizando el atributo sourceClient.

grep 'Connection accepted' mongod.log | jq -r '(.attr.sourceClient // .attr.remote)' | awk -F: '{print $1}' | sort | uniq -c | sort -rn
25957 192.168.254.155
25957 192.168.253.161
25957 192.168.248.236
14420 10.70.2.254
14420 10.70.2.116

La siguiente query proporciona el número de conexiones creadas por cada driver. Esto es útil en escenarios donde los clientes pueden usar diferentes drivers para diferentes aplicaciones.

more mongodb.log| grep 'NETWORK' | jq -r '.attr.doc.driver.name' | grep -v null | sort | uniq -c | sort -rn
56447 mongo-go-driver
21633 mongo-java-driver|sync
75 mongo-java-driver|sync|Airbyte
4 nodejs|Mongoose

Para un análisis más detallado de los recuentos de conexiones y detalles del controlador, puedes utilizar el siguiente script de Python, que proporciona información completa sobre el número de conexiones creadas y terminadas, junto con los nombres de los controladores y detalles de la versión.

import json
import sys
def process_log_file(json_file_path):
# Dictionary to store the filtered data
filtered_data = {}
with open(json_file_path, "r") as json_file:
# Read the file line by line
for line in json_file:
# Parse each line as a separate JSON object
data = json.loads(line)
if 'msg' in data and data['msg'] == 'client metadata':
# Extract the relevant data from the JSON object
drivername = data['attr']['doc']['driver']['name']
driverversion = data['attr']['doc']['driver']['version']
connectionid = data['ctx']
# Create a unique key for the driver based on name and version
driver_key = (drivername, driverversion)
# Add the connection ID to the driver's set of connections
if driver_key not in filtered_data:
filtered_data[driver_key] = {'connections': set(), 'opencount': 0, 'closedcount': 0}
filtered_data[driver_key]['connections'].add(connectionid)
filtered_data[driver_key]['opencount'] += 1
if 'msg' in data and data['msg'] == 'Connection ended':
connectionid = data['ctx']
# Check if the connection ID exists in any driver's connections
for driver_data in filtered_data.values():
if connectionid in driver_data['connections']:
driver_data['closedcount'] += 1
driver_data['connections'].remove(connectionid)
# Print the filtered data for each driver
for driver_key, driver_data in filtered_data.items():
print('Driver:', driver_key)
print('Connection Opened:', driver_data['opencount'])
print('Connection Closed:', driver_data['closedcount'])
if __name__ == '__main__':
# Check if a JSON file argument is provided
if len(sys.argv) < 2:
print("Please provide the path to a JSON file as an argument.")
sys.exit(1)
# Extract the JSON file path from the command-line arguments
json_file_path = sys.argv[1]
# Process the log file
process_log_file(json_file_path)
Driver: ('mongo-go-driver', 'v1.12.0-cloud')
Connection Opened: 14368
Connection Closed: 14362
Driver: ('mongo-go-driver', 'v1.12.1')
Connection Opened: 42056
Connection Closed: 41958
Driver: ('mongo-java-driver|sync', '4.11.1')
Connection Opened: 18012
Connection Closed: 17987
Driver: ('mongo-java-driver|sync', '4.8.2')
Connection Opened: 3621
Connection Closed: 3610
Driver: ('nodejs|Mongoose', '4.17.1|6.12.0')
Connection Opened: 3
Connection Closed: 1
Driver: ('mongo-go-driver', 'v1.13.0')
Connection Opened: 23
Connection Closed: 20
Driver: ('mongo-java-driver|sync|Airbyte', '4.11.0')
Connection Opened: 75
Connection Closed: 75
Driver: ('nodejs|Mongoose', '4.17.2|6.13.0')
Connection Opened: 1
Connection Closed: 0

Podemos sugerir que los clientes incluyan el nombre de la aplicación en la cadena de conexión para especificar diferentes aplicaciones que se conectan al clúster. Al utilizar la appName, podemos identificar qué aplicación está creando múltiples conexiones al clúster en el futuro. Consulta la sección Configuración Miscelánea de nuestra documentación para obtener más detalles sobre el uso de appName en la cadena de conexión. Además, puedes usar el comando db.currentOp().appname para ver las operaciones actuales asociadas con el nombre de la aplicación. La siguiente query proporciona detalles del appName con el número de conexiones creadas por esa aplicación en particular.

more mongodb.log| grep 'NETWORK' | jq -r '.attr.doc.application.name' | grep -v null | sort | uniq -c | sort -rn
10809 niyo-*******-api
8616 MongoDB CPS Module v13.17.2.8878 (git: 70c0b932f47f4f0b3e82a75e223f39ed9635b47f)
7203 niyo-ns*****
5752 MongoDB Automation Agent v13.17.2.8878 (git: 70c0b932f47f4f0b3e82a75e223f39ed9635b47f)
3601 *****-auth-service

Los detalles proporcionados ayudan a identificar los factores específicos que contribuyen al elevado número de conexiones. Al analizar la IP del cliente de origen, los metadatos del cliente, el uso del driver y los nombres de las aplicaciones, puedes identificar qué elementos son responsables del aumento de conexiones y determinar las áreas necesarias para investigar. Este enfoque dirigido le permite descartar otros factores menos relevantes y concentrarse en abordar las cuestiones relacionadas con la información destacada, agilizando en última instancia el proceso de mitigación y optimizando el rendimiento del clúster.

Los puntos finales privados solo están disponibles en clústeres de varias regiones si hay un nodo dentro de cada región que cubre el clúster que tenga configurado un punto final privado. Para obtener más información sobre la configuración de nodos privados multirregionales, consulta Nodos privados regionalizados para clústeres particionados multirregionales.

indexación de cadena de conexión para clústeres multiregionales

Después de configurar un nodo privado para una nueva región e implementar nodos de clúster en esa región, puede que se encuentre con el siguiente error cuando utilice su nodo privado para conectarse al clúster:

DNSHostNotFound: Failed to look up service "<MongoDB service name>"

Este error ocurre cuando el índice de tu cadena de conexión cambia automáticamente y tu cliente se reinicia, lo que provoca una búsqueda SRV DNS. La cadena de conexión del endpoint privado para un clúster multirregional utiliza un índice de 0. Si tu cadena de conexión utiliza un índice diferente, MongoDB actualiza automáticamente la cadena de conexión para usar el índice 0.

Por ejemplo, puedes configurar dos nodos privados para una región. Si remueves el primer punto final privado, tu cadena de conexión utiliza un índice de 1 y se parece a lo siguiente:

mongodb+srv://cluster1-psc-0.4uyx2d.mongodb.net

Luego, supón que configuras unos nodos privados para una nueva región en tu clúster y posteriormente añades nodos de clúster a esa región. Ahora tu clúster incluye varias regiones, y tu cadena de conexión se actualizará para usar un índice de 0:

mongodb+srv://cluster1-psc-1.4uyx2d.mongodb.net

Para evitar posibles problemas de conectividad después del próximo reinicio de su cliente, confirme que está utilizando la cadena de conexión del endpoint privado indexado en cero para conectarse a su clúster. Puedes acceder a la cadena de conexión actualizada del endpoint privado desde la UI o la API de Atlas después de que se completen los cambios en tu clúster.

Puedes utilizar las herramientas nslookup y telnet para probar la conectividad desde tu aplicación a tus nodos privados en Atlas.

1

Ejecute nslookup con la bandera -type=SRV para obtener los números de puerto asociados con cada uno de los nodos de su clúster.

nslookup -type=SRV _mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
_mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1026 pl-0-us-east-1.k45tj.mongodb.net.
_mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1024 pl-0-us-east-1.k45tj.mongodb.net.
_mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1025 pl-0-us-east-1.k45tj.mongodb.net.
2

Desde tu entorno de aplicación, con uno de los puertos listados (por ejemplo, 1026, 1024 o 1025 en el resultado del ejemplo anterior), ejecuta el siguiente comando telnet para probar la conectividad:

telnet pl-0-<xyz>.mongodb.net 1024
telnet pl-0-<xyz>.mongodb.net 1025
telnet pl-0-<xyz>.mongodb.net 1026

Para ver el estado de cada nodo privado:

1
  1. Si aún no aparece, se debe seleccionar la organización que contiene el proyecto en el menú Organizations de la barra de navegación.

  2. Si aún no se muestra, seleccione su proyecto en el menú Projects de la barra de navegación.

  3. En la barra lateral, haz clic en Database & Network Access en la sección Security.

La página Acceso a la base de datos y a la red se muestra.

2
3

Los campos Atlas Endpoint Service Status y Endpoint Status muestran el estado de cada nodo privado.

Consulta los siguientes estados para ayudarte a determinar el estado de tus conexiones de nodos privados:

Atlas Endpoint Service Status
Estado
Descripción

Crear vínculo privado

Atlas está creando recursos de balanceador de carga y VNet.

Fallido

Se ha producido un fallo del sistema.

Disponible

Atlas creó el balanceador de carga y el servicio privado de Azure Private Link. El servicio Azure Private Link está listo para recibir solicitudes de conexión.

Borrando

Atlas está eliminando Azure Private Link.

Endpoint Status
Estado
Descripción

No configurado

Atlas creó el balanceador de carga y el servicio Azure Private Link, pero aún no has creado un punto de conexión privado. Haz clic en Edit y completa el asistente para crear el nodo privado.

Iniciando

Atlas aún no ha aceptado la conexión a tu punto de enlace privado.

Fallido

Azure no pudo establecer una conexión entre los recursos de Atlas VNet y el punto de conexión privado en su VNet. Haga clic en Edit, verifique que la información proporcionada sea correcta y, a continuación, vuelva a crear el punto de conexión privado.

Disponible

Los recursos Atlas VNet están conectados al nodo privado en tu VNet. Puedes conectarte a clústeres de Atlas en esta región usando Azure Private Link.

Borrando

Atlas está removiendo la conexión de endpoint privado del Servicio de Azure Private Link.

Advertencia

No borres un punto de enlace fallido si es el único nodo registrado con ese servicio privado de nodo. Si eliminas el último endpoint, todo el servicio de endpoint se elimina automáticamente y debes reiniciar todo el proceso de configuración.

Cuando un cliente en el VNet se conecta a un clúster de Atlas usando una de estas cadenas de conexión compatibles con el nodo privado, el cliente intenta establecer una conexión con el servicio Private Link en el VNet de Atlas a través de la interfaz de red del nodo privado. El servicio Private Link envía tráfico a través de un balanceador de carga estándar de Azure a los nodos de clúster de Atlas que implementaste en esa región. El mecanismo de resolución de DNS del cliente gestiona la conversión del nombre de host a la dirección IP privada de la interfaz de red. El driver solo es reconoce el nombre de host en la cadena de conexión y escucha en un puerto por cada nodo del set de réplicas del clúster.

Registro SRV para cadenas de conexión con reconocimiento de nodos de la lista de semillas DNS

El siguiente ejemplo muestra el registro SRV de un clúster de una sola región habilitado para Azure Private Link, mostrando tres puertos únicos definidos para pl-0-eastus2.uzgh6.mongodb.net:

$ nslookup -type=SRV _mongodb._tcp.cluster0-pl-0.uzgh6.mongodb.net
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
_mongodb._tcp.cluster0-pl-0.uzgh6.mongodb.net service = 0 0 1024 pl-0-eastus2.uzgh6.mongodb.net.
_mongodb._tcp.cluster0-pl-0.uzgh6.mongodb.net service = 0 0 1025 pl-0-eastus2.uzgh6.mongodb.net.
_mongodb._tcp.cluster0-pl-0.uzgh6.mongodb.net service = 0 0 1026 pl-0-eastus2.uzgh6.mongodb.net.

En el ejemplo precedente:

  • _mongodb._tcp.cluster0-pl-0.uzgh6.mongodb.net es el registro SRV al que hace referencia la cadena de conexión.

  • pl-0-eastus2.uzgh6.mongodb.net es el nombre del host de cada nodo en un clúster de Atlas en una región para la que ha configurado Azure Private Link.

  • 10241025 y 1026 son puertos exclusivos que Atlas asigna en el balanceador de carga para cada nodo de set de réplicas de Atlas en la región para la que habilitó Azure Private Link. Todos los nodos en un Atlas set de réplicas son accesibles mediante el mismo nombre de host, con el balanceador de carga resolviendo cada nodo por su puerto individual.

Resolución de DNS del nombre de host en cadenas de conexión y registros SRV con reconocimiento de nodos privados

El nombre de host en el registro SRV y la cadena de conexión estándar es un registro DNS A que se resuelve en la dirección IP privada de la interfaz de red del punto final privado.

El siguiente ejemplo muestra la consulta de DNS para el nombre de host en el registro SRV y en la cadena de conexión estándar:

$ nslookup pl-0-eastus2.uzgh6.mongodb.net
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: pl-0-eastus2.uzgh6.mongodb.net
Address: 10.0.0.4

Los puntos finales privados solo están disponibles en clústeres de varias regiones si hay un nodo dentro de cada región que cubre el clúster que tenga configurado un punto final privado. Para obtener más información sobre la configuración de nodos privados multirregionales, consulta Nodos privados regionalizados para clústeres particionados multirregionales.

indexación de cadena de conexión para clústeres multiregionales

Después de configurar un nodo privado para una nueva región e implementar nodos de clúster en esa región, puede que se encuentre con el siguiente error cuando utilice su nodo privado para conectarse al clúster:

DNSHostNotFound: Failed to look up service "<MongoDB service name>"

Este error ocurre cuando el índice de tu cadena de conexión cambia automáticamente y tu cliente se reinicia, lo que provoca una búsqueda SRV DNS. La cadena de conexión del endpoint privado para un clúster multirregional utiliza un índice de 0. Si tu cadena de conexión utiliza un índice diferente, MongoDB actualiza automáticamente la cadena de conexión para usar el índice 0.

Por ejemplo, puedes configurar dos nodos privados para una región. Si remueves el primer punto final privado, tu cadena de conexión utiliza un índice de 1 y se parece a lo siguiente:

mongodb+srv://cluster1-psc-0.4uyx2d.mongodb.net

Luego, supón que configuras unos nodos privados para una nueva región en tu clúster y posteriormente añades nodos de clúster a esa región. Ahora tu clúster incluye varias regiones, y tu cadena de conexión se actualizará para usar un índice de 0:

mongodb+srv://cluster1-psc-1.4uyx2d.mongodb.net

Para evitar posibles problemas de conectividad después del próximo reinicio de su cliente, confirme que está utilizando la cadena de conexión del endpoint privado indexado en cero para conectarse a su clúster. Puedes acceder a la cadena de conexión actualizada del endpoint privado desde la UI o la API de Atlas después de que se completen los cambios en tu clúster.

Puedes utilizar las herramientas nslookup y telnet para probar la conectividad desde tu aplicación a tus nodos privados en Atlas.

1

Ejecute nslookup con la bandera -type=SRV para obtener los números de puerto asociados con cada uno de los nodos de su clúster.

nslookup -type=SRV _mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
_mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1026 pl-0-us-east-1.k45tj.mongodb.net.
_mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1024 pl-0-us-east-1.k45tj.mongodb.net.
_mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1025 pl-0-us-east-1.k45tj.mongodb.net.
2

Desde tu entorno de aplicación, con uno de los puertos listados (por ejemplo, 1026, 1024 o 1025 en el resultado del ejemplo anterior), ejecuta el siguiente comando telnet para probar la conectividad:

telnet pl-0-<xyz>.mongodb.net 1024
telnet pl-0-<xyz>.mongodb.net 1025
telnet pl-0-<xyz>.mongodb.net 1026

Para ver el estado de cada nodo privado:

1
  1. Si aún no aparece, se debe seleccionar la organización que contiene el proyecto en el menú Organizations de la barra de navegación.

  2. Si aún no se muestra, seleccione su proyecto en el menú Projects de la barra de navegación.

  3. En la barra lateral, haz clic en Database & Network Access en la sección Security.

La página Acceso a la base de datos y a la red se muestra.

2
3

Los campos Atlas Endpoint Service Status y Endpoint Status muestran el estado de cada nodo privado.

Consulta los siguientes estados para ayudarte a determinar el estado de tus conexiones de nodos privados:

Atlas Endpoint Service Status

Estado
Descripción

Crear vínculo privado

Atlas está creando el equilibrador de carga de red y los recursos VPC.

Fallido

Se ha producido un fallo del sistema.

Disponible

Atlas creó el balanceador de carga de red y el servicio de punto final de VPC. El servicio de punto final privado está listo para recibir solicitudes de conexión.

Borrando

Atlas está borrando el servicio de nodo privado.

Endpoint Status

Estado
Descripción

Iniciando

Atlas aún no está conectado a tus nodos privados y aún no ha aceptado los nodos privados.

Esperando al usuario

Los recursos de VPC en Atlas están listos para su uso. Debe configurar los endpoints dentro de su VPC ejecutando el script de comandos shell.

Verificado.

Atlas verificó los puntos finales dentro de su VPC, pero aún no ha aceptado el punto final privado en su VPC de Google Cloud. Es posible que el Endpoint Status tarde varios minutos en convertirse en Available.

Disponible

Los recursos de Atlas VPC están conectados al nodo privado de tu Google Cloud VPC. Atlas ha aceptado los endpoints. Puede conectarse a los clústeres de Atlas en esta región usando GCP Private Service Connect.

Activo

Atlas está listo para usar recursos de VPC. Atlas ha aceptado los endpoints. Se asigna una VM a la conexión de servicio privada.

Fallido

Google Cloud no pudo establecer una conexión entre los recursos de Atlas VPC y el punto de conexión privado en su VPC de Google Cloud. Haga clic en Edit, verifique que la información proporcionada sea correcta y, a continuación, vuelva a crear el punto de conexión privado.

Nota: Si ves el mensaje de error "No se pudo encontrar el extremo en GCP. Verifique que el nombre del endpoint sea correcto y que se haya creado en el proyecto correcto de GCP, y vuelva a intentarlo. Puede que haya escrito mal el nombre de su nodo privado o que aún deba crearlo. Para resolver esto, haz clic en Edit y asegúrate de que los campos sean correctos.

Deleted

Eliminaste manualmente el endpoint privado de una región en Atlas. También debes borrar los nodos privados en Google Cloud para borrar los recursos. Eliminación pendiente del grupo de regiones.

Advertencia

No borres un punto de enlace fallido si es el único nodo registrado con ese servicio privado de nodo. Si eliminas el último endpoint, todo el servicio de endpoint se elimina automáticamente y debes reiniciar todo el proceso de configuración.

4

Para cada recurso que necesita conectarse a sus Clústeres de Atlas usando GCP Private Service Connect, debe permitir el tráfico saliente a las direcciones IP privadas de la regla de reenvío en todos los puertos (1024-65535). Consulta Gestión de la seguridad del consumidor para PSC para más información.

Los puntos finales privados solo están disponibles en clústeres de varias regiones si hay un nodo dentro de cada región que cubre el clúster que tenga configurado un punto final privado. Para obtener más información sobre la configuración de nodos privados multirregionales, consulta Nodos privados regionalizados para clústeres particionados multirregionales.

indexación de cadena de conexión para clústeres multiregionales

Después de configurar un nodo privado para una nueva región e implementar nodos de clúster en esa región, puede que se encuentre con el siguiente error cuando utilice su nodo privado para conectarse al clúster:

DNSHostNotFound: Failed to look up service "<MongoDB service name>"

Este error ocurre cuando el índice de tu cadena de conexión cambia automáticamente y tu cliente se reinicia, lo que provoca una búsqueda SRV DNS. La cadena de conexión del endpoint privado para un clúster multirregional utiliza un índice de 0. Si tu cadena de conexión utiliza un índice diferente, MongoDB actualiza automáticamente la cadena de conexión para usar el índice 0.

Por ejemplo, puedes configurar dos nodos privados para una región. Si remueves el primer punto final privado, tu cadena de conexión utiliza un índice de 1 y se parece a lo siguiente:

mongodb+srv://cluster1-psc-0.4uyx2d.mongodb.net

Luego, supón que configuras unos nodos privados para una nueva región en tu clúster y posteriormente añades nodos de clúster a esa región. Ahora tu clúster incluye varias regiones, y tu cadena de conexión se actualizará para usar un índice de 0:

mongodb+srv://cluster1-psc-1.4uyx2d.mongodb.net

Para evitar posibles problemas de conectividad después del próximo reinicio de su cliente, confirme que está utilizando la cadena de conexión del endpoint privado indexado en cero para conectarse a su clúster. Puedes acceder a la cadena de conexión actualizada del endpoint privado desde la UI o la API de Atlas después de que se completen los cambios en tu clúster.

Puedes utilizar las herramientas nslookup y telnet para probar la conectividad desde tu aplicación a tus nodos privados en Atlas.

1

Ejecute nslookup con la bandera -type=SRV para obtener los números de puerto asociados con cada uno de los nodos de su clúster.

nslookup -debug -type=SRV _mongodb._tcp.cluster1-psc-0.j735c.mongodb.net
Server: 127.0.2.2
Address: 127.0.2.2#53
------------
QUESTIONS:
_mongodb._tcp.cluster1-psc-0.j735c.mongodb.net, type = SRV, class = IN
ANSWERS:
-> _mongodb._tcp.cluster1-psc-0.j735c.mongodb.net
service = 0 0 1024 pl-0-us-central1-gcp.j735c.mongodb.net.
ttl = 60
-> _mongodb._tcp.cluster1-psc-0.j735c.mongodb.net
service = 0 0 1025 pl-0-us-central1-gcp.j735c.mongodb.net.
ttl = 60
-> _mongodb._tcp.cluster1-psc-0.j735c.mongodb.net
service = 0 0 1026 pl-0-us-central1-gcp.j735c.mongodb.net.
ttl = 60
AUTHORITY RECORDS:
ADDITIONAL RECORDS:
------------
Non-authoritative answer:
_mongodb._tcp.cluster1-psc-0.j735c.mongodb.net service = 0 0 1024 pl-0-us-central1-gcp.j735c.mongodb.net.
_mongodb._tcp.cluster1-psc-0.j735c.mongodb.net service = 0 0 1025 pl-0-us-central1-gcp.j735c.mongodb.net.
_mongodb._tcp.cluster1-psc-0.j735c.mongodb.net service = 0 0 1026 pl-0-us-central1-gcp.j735c.mongodb.net.
Authoritative answers can be found from:
telnet pl-0-us-central1-gcp.j735c.mongodb.net 1024
2

Desde tu entorno de aplicación, con uno de los puertos listados (por ejemplo, 27017 en el resultado del ejemplo anterior), ejecuta el siguiente comando telnet para probar la conectividad:

telnet pl-0-<xyz>.mongodb.net 27017
Califique esta página

En esta página