O Atlas fornece várias cadeias de conexão. Estas strings permitem que você se conecte aos seus clusters a partir de contextos públicos e privados. O Atlas sempre atribui strings de conexão únicas a clusters para que nenhum cluster compartilhe nome de host ou strings de conexão no Atlas.
Como identifico qual cadeia de conexão meu aplicativo usa?
A estrutura do URI da connection string indica o tipo de string. Se você tiver criado uma conexão de emparelhamento ou um endpoint privado, o Atlas exibirá mais de uma dessas opções para seu uso.
Por que meu cluster tem múltiplas cadeias de conexão?
Para se conectar ao Atlas, aponte seus aplicativos para um URI para se comunicar com um cluster. O Atlas cria clusters com mais de um nó ou host. Cada nó tem seu próprio nome de host que se resolve para um endereço IP. O URI, conhecido como uma connection string, ao qual o Atlas se conecta, pode ter mais de um nome de host. Configure o Atlas para aceitar conexões para os hosts de cluster a partir de endereços IP permitidos.
O Atlas protege conexões de endereços IP públicos por meio de autenticação e TLS. Se você quiser se conectar a endereços IP privados, você pode usar:
Essas funcionalidades gerenciam a comunicação em endereços IP internos dentro de redes seguras.
O Atlas fornece mais de uma cadeia de conexão ao usar redes seguras. Cada rede oferece uma string que se resolve para endereços IP diferentes.
Todos os clusters têm uma string de conexão padrão. Isso é resolvido para o cluster:
Endereços IP públicos para conexões de Internet e
Endereços IP privados de VPC para clusters da AWS quando resolvidos a partir de uma VPC emparelhada.
Use essa string para aplicativos que se conectam pela Internet ou que se conectam a clusters emparelhados na AWS.
Os clusters com redes emparelhadas têm uma string de conexão de IP privado para emparelhamento. Essa string é resolvida para endereços IP disponíveis para:
Redes emparelhadas no Azure ou Google Cloud
Clusters emparelhados da AWS com um serviço de DNS personalizado.
Use esta cadeia de conexão com aplicativos conectados:
Em uma rede emparelhada do Azure ou do Google Cloud
Para clusters AWS quando usar a AWS com DNS personalizado.
Os clusters da AWS ou do Azure em regiões com endpoints privados configurados têm uma ou mais connection strings. Cada string é resolvida para o endereço IP privado de uma interface de rede em sua VPC ou VNet que se conecta diretamente a um balancer de carga na VPC ou VNet do Atlas. Use essas connection strings com aplicativos que se conectam a endpoints privados.
Posso usar uma única string de conexão SRV do MongoDB para um cluster multirregional com link privado?
Sim, você pode usar uma única SRV string de conexão para um cluster multirregional com link privado no MongoDB Atlas. A SRV string de conexão é resolvida automaticamente para os nós apropriados nas regiões. No entanto, certifique-se de que sua configuração de rede permita a conectividade entre regiões por meio de pontos de extremidade privados. Para AWS e Azure, isso envolve a configuração do emparelhamento VPC/VNet entre regiões. Para o Google Cloud, você precisa configurar o acesso global para o Private Service Connect.
Para saber mais, consulte a documentação para pontos de extremidade privados.
O que isso média para os clusters do Google Cloud ou do Azure no modo somente emparelhamento?
Antes de 31 de março de 2020, era necessário habilitar o modo somente emparelhamento para se conectar a bancos de dados em clusters do Azure ou do Google Cloud em rede de mesmo nível. Este modo:
Afetou a resolução global de DNS e
Limitou quaisquer conexões de banco de dados fora da rede com emparelhamento.
Vários horizontes elevam essas restrições e desbloqueiam as seguintes funcionalidades adicionais:
Para aproveitar várias possibilidades, execute as seguintes tarefas:
Atualize as cadeias de conexão existentes do seu aplicativo para usar IP privado para cadeias de conexão de emparelhamento.
Conecte-se usando as strings descritas em Por que meu cluster tem várias cadeias de conexão.
Observação
No momento, você pode continuar se conectando aos seus clusters usando cadeias de conexão habilitadas para emparelhamento existentes. O modo Peering-Only impede o acesso à funcionalidade aprimorada e às limitações reduzidas de vários horizontes. Para usar os novos recursos e remover as limitações antigas, o MongoDB exige que você use as novas cadeias de conexão.
O meu cluster do Azure com o emparelhamento de VNet pode abranger várias regiões?
Sim.
Altere seus aplicativos para se conectarem usando a string de conexão de IP privado para emparelhamento. Essa alteração permite que seus aplicativos se conectem a partir de redes emparelhadas usando a UI ou a API.
Para expandir para mais regiões, desative primeiro o modo somente emparelhamento nos clusters existentes do Azure.
Como faço para desativar o modo somente de emparelhamento?
Para desativar o modo somente emparelhamento usando:
No Atlas, vá para a página Clusters do seu projeto.
Se ainda não tiver sido exibido, selecione a organização que contém seu projeto no menu Organizations na barra de navegação.
Se ainda não estiver exibido, selecione o projeto desejado no menu Projects na barra de navegação.
Na barra lateral, clique em Clusters sob o título Database.
A página Clusters é exibida.
Atualize todos os aplicativos para usar IP privado para connection strings de emparelhamento.
Altere quaisquer URLem sua aplicação que use seus clusters do Atlas para usar IP privado para emparelhamento de strings de conexão.
No Atlas, vá para a página Project Settings.
Se ainda não tiver sido exibido, selecione a organização que contém seu projeto no menu Organizations na barra de navegação.
Se ainda não estiver exibido, selecione o projeto desejado no menu Projects na barra de navegação.
Na barra lateral, clique no ícone ao lado de Project Overview.
A página Configurações do projeto é exibida.
Verifique se todos os clusters do seu projeto usam o MongoDB 7.0 ou posterior.
Chame o ponto de extremidade de API get all para retornar todos os clusters e suas versões do MongoDB:
Observação
Este comando curl usa um token de acesso à conta de serviço (OAuth 2.0) para autenticar em vez de chaves API. Para saber mais, consulte Introdução à Atlas Administration API.
Exemplo
curl --header "Authorization: Bearer {ACCESS-TOKEN}" \ --header "Accept: application/json" \ --header "Content-Type: application/json" \ --include \ --request GET "https://cloud.mongodb.com/api/atlas/v1.0/groups/{GROUP-ID}/clusters?pretty=true"
Se for bem-sucedida, a resposta deverá incluir:
{ "results": [{ ... "mongoDBMajorVersion": "6.0", "mongoDBVersion": "6.0.14", ... },{ ... "mongoDBMajorVersion": "6.0", "mongoDBVersion": "6.0.12", ... } ] }
Atualize todos os aplicativos para usar IP privado para connection strings de emparelhamento.
Altere quaisquer URLem sua aplicação que use seus clusters do Atlas para usar IP privado para emparelhamento de strings de conexão.
Desative o modo IP privado nos seus clusters.
Chame o ponto de extremidade da API para desabilitar o modo de IP privado.
Exemplo
Usando curl, você invocaria este comando:
curl --header "Authorization: Bearer {ACCESS-TOKEN}" \ --header "Accept: application/json" \ --header "Content-Type: application/json" \ --include \ --request PATCH "https://cloud.mongodb.com/api/atlas/v1.0/groups/{GROUP-ID}/privateIpMode?pretty=true" \ --data ' { "enabled" : false }'
Altere {GROUP-ID} para o ID do seu projeto.
Se for bem-sucedido, a resposta exibirá:
1 { 2 "enabled" : false 3 }
Como isso afeta o emparelhamento da AWS VPC quando uso DNS personalizado?
Antes de 31 de março de 2020, os aplicativos implantados na AWS usando serviços de DNS personalizados e com VPC com o Atlas não podiam se conectar por endereços IP privados:
DNS personalizado resolvido para endereços IP públicos.
DNS interno AWS resolvido para endereços IP privados.
Os aplicativos implementados com serviços DNS personalizados na AWS devem usar IP privado para strings de conexão de emparelhamento.
Para mostrar essas strings:
No Atlas, vá para a página Project Settings.
Se ainda não tiver sido exibido, selecione a organização que contém seu projeto no menu Organizations na barra de navegação.
Se ainda não estiver exibido, selecione o projeto desejado no menu Projects na barra de navegação.
Na barra lateral, clique no ícone ao lado de Project Overview.
A página Configurações do projeto é exibida.
Cadeias de conexão padrão
As cadeias de conexão padrão seguem este formato:
mongodb://xyz456-shard-00-00.ab123.mongodb.net:27017 mongodb+srv://xyz456.ab123.mongodb.net
O ponto antes de ab123 é importante. Os URIs que usam esse formato são resolvidos para endereços IP públicos , exceto quando a conexão é feita de dentro da AWS com o pareamento de VPC configurado.
Importante
Esse formato altera um caractere das strings de conexão herdadas: um hífen (-) após o nome do cluster se torna um ponto final (.).
Por exemplo, essa string de conexão legada:
mongodb+srv://xyx456-ab123.mongodb.net
é escrito como esta cadeia de conexão padrão:
mongodb+srv://xyx456.ab123.mongodb.net
Para novos clusters, conjuntos de réplicas e shards não derivam seu nome do nome do cluster. Os novos nomes usam um ID de seis caracteres alfanuméricos.
Cadeias de conexão privadas
As cadeias de conexão privadas seguem este formato:
mongodb://xyx456-shard-00-00-pri.ab123.mongodb.net:27017 mongodb+srv://xyx456-pri.ab123.mongodb.net
O -pri antes de ab123 é importante. Os URIs que usam esse formato resultam em endereços IP privados acessíveis dentro da rede emparelhada. Se você configurar o emparelhamento de rede para o seu cluster, você deverá usar o novo nome do host ao se conectar ao seu cluster para utilizar o emparelhamento.
Importante
Em novos clusters, conjuntos de réplica e shards não derivam seu nome do nome do cluster. Os novos nomes usam um ID de seis caracteres alfanuméricos.
Observação
Em ambientes AWS, a string de conexão do -pri é opcional, mesmo quando o emparelhamento de rede está habilitado. A AWS resolve os endereços IP privados do cluster, independentemente de você usar a string de conexão privada ou padrão.
Strings de conexão do AWS Privatelink
As cadeias de conexão do AWS PrivateLink seguem este formato:
mongodb://pl-0-us-east-1a.ab123.mongodb.net:1024 mongodb+srv://pl-0-us-east-1a.ab123.mongodb.net
Se você habilitar a configuração de pontos de extremidade privados regionalizados, as cadeias de conexão do AWS PrivateLink seguirão este formato:
mongodb://pl-0-us-west-1.ab123.mongodb.net:1024 mongodb+srv://cluster0-pl-0-us-west-1.ab123.mongodb.net
Os URIs que usam esse formato podem ser acessados por meio da VPC da AWS onde alguém tenha configurado o PrivateLink, embora o acesso possa ser transitivo a partir de outras VPCs emparelhadas por vez.
Azure Private Link Connection Strings
As cadeias de conexão do Azure Private Link seguem este formato:
mongodb://pl-0-eastus2.ab123.mongodb.net:1024 mongodb+srv://pl-0-eastus2.ab123.mongodb.net
Se você habilitar a configuração de pontos de extremidade privados regionalizados, as cadeias de conexão do Azure Private Link seguirão este formato:
mongodb://pl-0-eastus2.ab123.mongodb.net:1024 mongodb+srv://cluster0-pl-0-eastus2.ab123.mongodb.net
Os URIsque usam esse formato podem ser acessados por meio da VNet do Azure, onde alguém configurou o Private Link, embora o acesso possa ser transitivo a partir de outras VNets emparelhadas alternadamente.
Cadeia de conexão legada
Antes de 31 de Março de 2020, você escrevia cadeias de conexão do Atlas desta forma:
AWS (Amazon Web Services) | | ||
Azure (Microsoft Azure) | | ||
Google cloud | |
Se você habilitou o modo Somente Privado, esses nomes de host serão resolvidos para endereços IP de rede emparelhados. Se você desabilitou esse modo, os nomes de host serão resolvidos para endereços IP públicos.
Se o seu aplicativo usar uma cadeia de conexão herdada no modo somente emparelhamento, alterne para IP privado para cadeias de conexão de emparelhamento.
Como posso otimizar o desempenho da conexão de clusters fragmentados usando pontos de extremidade privados?
O Atlas pode gerar uma connection string SRV otimizada para clusters fragmentados por meio dos balancers de carga do seu serviço de endpoints privados. Quando você utiliza uma connection string otimizada, o Atlas limita o número de conexões por mongos entre seu aplicativo e seu cluster fragmentado. As conexões limitadas por mongos melhoram o desempenho durante os picos de contagens de conexões.
Para usar uma cadeia de conexão otimizada, você deve atender a todos os seguintes critérios:
Certifique-se de que o cluster fragmentado seja executável na AWS.
Certifique-se de que o cluster fragmentado execute o MongoDB na versão 5.0 ou posterior. Se o seu cluster estiver executando uma versão anterior do MongoDB, atualize a versão do MongoDB do seu cluster para a versão 5.0 ou posterior para utilizar uma connection string SRV otimizada.
Configure um ponto de extremidade privado para seu cluster.
Use qualquer um dos dois:
Um cluster de região única ou
Um cluster multirregional com endpoints privados regionalizados habilitados. Somente as regiões da AWS em clusters multirregionais permitem connection strings SRV otimizadas.
O Atlas não oferece suporte a conexões otimizadas para clusters multirregionais usando um único registro SRV.
Conecte-se usando um dos seguintes métodos:
Conecte-se usando um driver que atenda ou exceda a versão mínima do driver para conexões otimizadas.
Observação
Se o seu cluster atender aos critérios para strings SRV otimizadas, o Atlas gerará uma string Optimized SRV Connection para você. Se o seu cluster já teve connection strings legadas, o Atlas mantém essas strings indefinidamente e inclui uma string do Legacy SRV Connection quando você seleciona o tipo de conexão do Private Endpoint. Considere mudar para o Optimized SRV Connection para obter um desempenho ideal e atualizar sua connection string onde quer que você a use.
Se você criar o cluster e habilitar os pontos de extremidade privados após o lançamento dessa funcionalidade, o Atlas exibirá a cadeia de conexão otimizada por padrão quando você selecionar o tipo de conexão Private Endpoint. Você pode identificar uma cadeia de conexão otimizada adicionando lb à cadeia de conexão, conforme mostrado no exemplo a seguir:
mongodb+SRV://User1:P@ssword@cluster0-pl-0-lb.oq123.mongodb-dev.net/
Para desativar cadeias de conexão otimizadas para clusters que não têm a opção Legacy SRV Connection, entre em contato com o suporte.
Aviso
Converter em um Cluster Multirregional
Se você converter seu cluster fragmentado de região única em um cluster multirregional sem habilitar pontos de extremidade privados regionalizados, não poderá continuar a usar a string de conexão otimizada. Antes de converter o cluster, atualize a string de conexão para a string Legacy SRV Connection descrita na nota anterior.
Use cadeia de conexão otimizadas com um driver
Para saber como se conectar usando um driver e uma string de conexão otimizada, selecione a aba Private Endpoint Connection no procedimento Conectar seu aplicativo.
Use cadeias de conexão otimizadas com o Compass
Para saber como se conectar usando o Compass e uma string connection otimizada, selecione a guia Private Endpoint Connection em Conectar-se ao procedimento do seu cluster.
Use cadeias de conexão otimizadas com mongosh
Para saber como se conectar usando mongosh e uma connection string otimizada, selecione a aba Private Endpoint Connection no procedimento Conectar ao cluster.
Devo atualizar a string de conexão se eu mudar de provedor de nuvem em um cluster Free ou Flex?
Se você tiver uma string de conexão legado e quiser alterar os provedores de nuvem, a string de conexão deverá incluir .gcp ou .azure e você deseja fazer o seguinte:
Mudar para o Google Cloud ou Azure
Saia do Google Cloud ou do Azure
Observação
Qualquer operação pode alterar sua cadeia de conexão. Na IU do Atlas, clique em Connect no seu cluster após a conclusão da atualização de uma cadeia de conexão atualizada.
Devo atualizar a string de conexão se eu mudar de provedor de nuvem em um cluster dedicado?
Depende do seguinte:
qual provedor de nuvem seu cluster atual usa
quando você criou o cluster
GCP ou Azure Clusters criados antes de 3 de novembro de 2020
Se você criou seu cluster antes da introdução dos clusters multinuvem em 3 de novembro de 2020, e seu cluster é executado no Google Cloud ou Azure:
No Atlas, acesse a página Clusters do seu projeto.
Se ainda não tiver sido exibido, selecione a organização que contém seu projeto no menu Organizations na barra de navegação.
Se ainda não estiver exibido, selecione o projeto desejado no menu Projects na barra de navegação.
Na barra lateral, clique em Clusters sob o título Database.
A página Clusters é exibida.
Abra o construtor de cluster.
Edite o cluster.
Adicione nós read-only do seu provedor de nuvem de destino.
Observação
Se você estiver usando backups legados, mantenha um nó no seu provedor de nuvem atual e mova o restante para o provedor de nuvem de destino.
Revise e envie as alterações.
Copie a connection string do URI delimitada por vírgula resultante.
Substitua a cadeia de conexão em seu aplicativo por essa nova cadeia de conexão padrão.
Isso permite que seu aplicativo se conecte a nós a partir de vários provedores de nuvem.
Reinicie seu aplicativo.
Certifique-se de que seu aplicativo possa se conectar ao Atlas.
Após a conclusão da primeira alteração, reconfigure seu cluster:
Remova todos os nós elegíveis usando o provedor de cloud original.
Remova os nós read-only do provedor de nuvem de destino.
Adicione o mesmo número de nós elegíveis usando o provedor de nuvem de destino.
Observação
Se você estiver usando backups legados, aguarde até que novos backups sejam feitos e, em seguida, mova o nó restante para o provedor de nuvem de destino.
Revise e envie as alterações.
Copie a connection string do URI delimitada por vírgula resultante.
Substitua a connection string do URI em seu aplicativo por esta nova connection string do URI.
Reinicie seu aplicativo.
Certifique-se de que seu aplicativo possa se conectar ao Atlas.
AWS e Clusters criados após 2 de novembro de 2020
Sua string de conexão não será alterada, e você não terá tempo de inatividade do cluster se alguma das seguintes situações for verdadeira:
Seu cluster é executado no Amazon Web Services.
Seu cluster é executado em qualquer provedor de nuvem , mas foi criado depois de 2 de novembro de 2020.
Para alterar o provedor de nuvem do seu cluster:
No Atlas, acesse a página Clusters do seu projeto.
Se ainda não tiver sido exibido, selecione a organização que contém seu projeto no menu Organizations na barra de navegação.
Se ainda não estiver exibido, selecione o projeto desejado no menu Projects na barra de navegação.
Na barra lateral, clique em Clusters sob o título Database.
A página Clusters é exibida.
Abra o construtor de cluster.
Edite o cluster.
Altere o provedor de nuvem.
Revise e envie as alterações.