Dica
Em clusters Atlas Core, você pode criar implantações multinuvem do MongoDB no Atlas usando qualquer combinação de provedores de nuvem: AWS, Azure e Google Cloud. Os clusters Atlas Infinite não são compatíveis com clusters multinuvem em pré-visualização pública.
Nos clusters do Atlas Core, você pode definir os nós do seu cluster para usar diferentes:
Provedores de nuvem: Implante nós no AWS, Azure ou Google Cloud. Você pode implantar todos os nós em um provedor de nuvem ou implantar um cluster multinuvem com nós em diferentes provedores de nuvem.
Regiões geográficas: implante nós em uma ou mais regiões de provedor de nuvem e defina qual região o Atlas prioriza para elegibilidade primária. As regiões podem estar no mesmo provedor de nuvem ou em diferentes provedores de nuvem.
Finalidades da carga de trabalho: implantar nós elegíveis, somente leitura, de análise e de pesquisa.
On Atlas Infinite clusters in public preview, Atlas deploys all nodes in one region on AWS. You can deploy read-only and analytics nodes to isolate workloads from your primary node. To learn more, see Workload Isolation on Atlas Infinite clusters.
Para configurar as opções de provedor de nuvem, região e isolamento de carga de trabalho para seu cluster Atlas Core, consulte o seguinte procedimento:
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.
Para o cluster relevante, clique em Edit configuration.
Clique em Edit additional configuration no canto inferior direito.
Expanda Cloud Provider & Region e alterne Multi-Cloud, Multi-Region & Workload Isolation (M10+ clusters) para On.
Considerações
The considerations that reference multiple regions, multiple cloud providers, or sharded clusters apply to Atlas Core clusters only. Atlas Infinite clusters don't support these configurations in public preview. To learn which workload isolation options apply to Atlas Infinite clusters, see Workload Isolation on Atlas Infinite clusters.
O Atlas não garante que os nomes de host permaneçam consistentes com os tipos de nó durante as alterações de topologia.
Exemplo
Se você tiver um cluster chamado
foo123contendo um nó de análisefoo123-shard-00-03-a1b2c.mongodb.net:27017, o Atlas não garantirá que esse nome de host específico continuará a se referir a um nó de análise depois de uma alteração de topologia, como o dimensionamento de um cluster para modificar seu número de nós ou regiões.Em clusters fragmentados que usam um servidor de configuração dedicado, o Atlas distribui os três nós do servidor de configuração com base no número de regiões elegíveis no cluster. Se o cluster tiver:
Somente em uma região elegível, o Atlas distribui todos os três nós de configuração nessa região.
Duas regiões selecionáveis, o Atlas distribui dois nós de configuração na região de maior prioridade e um nó de configuração na segunda região maior prioridade.
Três ou mais regiões elegíveis, o Atlas distribui um nó de configuração em cada uma das três regiões de maior prioridade.
Ter um grande número de regiões ou ter nós distribuídos por longas distâncias pode resultar em tempos prolongados de eleição ou atrasos de replicação.
Uma mudança de cluster que adiciona, remove ou modifica membros com votos demora mais tempo, já que o Atlas adiciona, remove ou modifica os membros votantes um de cada vez de forma contínua.
Os clusters Gen1 podem abranger regiões e provedores de serviços em nuvem. Os clusters Gen2 não oferecem suporte entre nuvens, mas podem abranger várias regiões, desde que todas as regiões ofereçam suporte aos clusters Gen2 para um determinado provedor de nuvem. Para aprender mais, consulte:
O Atlas limita o número total de nós em outras regiões em um projeto a um total de 100, não incluindo: - Regiões do Google Cloud Platform que se comunicam entre si - Clusters gratuitos - Clusters Flex
Sharded clusters include additional nodes. The electable nodes on the dedicated Config Server Replica Set (CSRS) count towards the total number of allowable nodes. Each sharded cluster has an additional electable node per region as part of the dedicated CSRS. To learn more, see Replica Set Config Servers.
O número total de nós entre quaisquer duas regiões deve atender a essa restrição.
Exemplo
Se um projeto do Atlas tiver nós em clusters espalhados por três regiões:
75 nós na Região A
10 nós na Região B
5 nós na Região C
Você só pode adicionar mais 10 nós à Região C porque:
Se você excluir a Região C, Região A + Região B = 85, <= 100.
Se você excluir a região B, região A + região C = 80, <= 100.
Se você excluir a região A, região B + região C = 15, <= 100.
Cada combinação de regiões com os nós 10 adicionados ainda atende à restrição por projeto:
Região A + B = 85, <= 100
Região A + C = 90, <= 100
Região B + C = 25, <= 100
Você não pode criar um cluster multirregional em um projeto se ele tiver um ou mais clusters abrangendo 100 ou mais nós em outras regiões.
Entre em contato com o suporte Atlas para tirar dúvidas ou obter assistência para aumentar esse limite.
O Atlas limita o número de nós entre quaisquer duas regiões em um projeto. Para saber mais, consulte Quantas permissões de rede entre regiões são suportadas pelo Atlas?.
O Atlas fornece write concerns personalizados integrados para clusters multirregionais. Use esses write concern para garantir que suas operações de gravação se propaguem para um número desejado de regiões, garantindo assim a consistência dos dados entre suas regiões. Para saber mais, consulte Write concerns personalizados integrados.
O número de zonas de disponibilidade, zonas ou domínios de falha em uma região não afeta o número de nós do MongoDB que o Atlas pode distribuir. Os clusters MongoDB Atlas são sempre feitos de conjuntos de réplicas com um mínimo de três nós do MongoDB.
If you use the standard connection string format rather than the DNS seedlist format, removing an entire region from an existing cross-region cluster may result in a new connection string.
Para verificar a cadeia de conexão correta após distribuir as alterações:
1No 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.
Se você planeja criar uma ou mais conexões de emparelhamento da VPC em seu primeiro cluster
M10+pago dedicado para a região ou as regiões selecionadas, primeiro revise a documentação sobre Conexões de emparelhamento da VPC.O Atlas pode usar hardware de provedor de nuvem diferentes
M10paraM20clusters e em regiões específicas de GCP. Como resultado, determinadas combinações de regiões do GCP podem não ser compatíveis comM10e clusters deM20multirregionais.
Nós elegíveis para alta disponibilidade
Se regiões com nós elegíveis forem adicionadas, você poderá:
aumentar a disponibilidade de dados
reduzir o impacto das interrupções do data center
Nos clusters do Atlas Core, você pode implantar nós em várias regiões dentro do mesmo provedor de nuvem ou em vários provedores de nuvem. Os clusters do Atlas Infinite não oferecem suporte a clusters multirregional ou multinuvem na visualização pública.
Atlas sets the node in the first row of the Electable nodes table as the Highest Priority region. Atlas prioritizes nodes in this region for primary eligibility. Other nodes rank in the order that they appear. For more information, see Member Priority.
Observação
Este recurso não é aplicável ao Atlas Infinite. Para aprender mais sobre as funcionalidades e o comportamento do Atlas Infinite, consulte MongoDB Atlas Infinite: Visão geral.
Cada nó elegível pode:
Participar de eleições de conjuntos de réplicas
Become the primary while the majority of nodes in the replica set remain available
Importante
Quando as gravações globais estão habilitadas, os clusters globais não oferecem suporte a nós de pesquisa dedicados.
Adicionar nós elegíveis
Você pode adicionar nós elegíveis em um provedor de nuvem e uma região na seção Electable nodes for high availability.
Para adicionar um nó elegível:
Clique em Add a provider/region.
Selecione o provedor de nuvem no menu suspenso Provider.
Selecione a região no menu suspenso Region.
Quando você altera a opção Provider, o Region altera para uma opção em branco. Se você não selecionar uma região, o Atlas exibirá um erro ao clicar em Create Cluster.
Especifique o número desejado de Nodes para o provedor e região.
O número total de nós elegíveis em todos os provedores e regiões do cluster deve ser igual a 3, 5 ou 7.
O Atlas considera as regiões marcadas com um conforme recomendado. Essas regiões oferecem alta disponibilidade em comparação com outras regiões.
Para saber mais, consulte:
Remover nós elegíveis
Para remover um nó de uma região, clique no ícone no lado direito dessa região. Não é possível remover um nó na região Highest Priority.
Para saber mais, consulte Backups de cluster multirregional.
Aviso
Quando você migra nós elegíveis de uma região para outra, o Atlas provisiona imediatamente novos nós e desprovisiona os antigos. O Atlas não espera que os índices do MongoDB Search terminem de ser construídos na nova região antes de desprovisionar os nós antigos, portanto, você pode enfrentar o tempo de inatividade do MongoDB Search durante a criação de novos índices.
Para evitar o tempo de inatividade, conclua a migração em duas etapas:
Adicione a nova região e aguarde o provisionamento completo de todos os nós. Se você usar nós de pesquisa, certifique-se de que o MongoDB Search termine de criar todos os índices antes de continuar.
Remova a região antiga.
Para reduzir ainda mais o risco de tempo de inatividade, use tags de preferência de leitura para rotear leituras para regiões onde seus índices estão prontos.
Alterar nós elegíveis para nós read-only
You can change an electable node to a read-only node by adding a read-only node and removing an electable node at the same time. To learn more, see Change Workload Purpose of Nodes.
Melhorar a disponibilidade de um cluster
Para melhorar a redundância e a disponibilidade de um cluster, aumente o número de nós elegíveis nessa região. Cada Atlas cluster tem uma região do Highest Priority. Se o seu cluster abranger várias regiões, você poderá selecionar qual região do provedor de nuvem deve ser a Highest Priority.
Para evitar a perda de disponibilidade e desempenho, considere os seguintes cenários:
Ponto de falha | Como prevenir este ponto de falha |
|---|---|
Provedor de nuvem | Mínimo de um conjunto de nós em todos os três provedores de nuvem. Mais de um nó por região. |
Região | Mínimo de um nó definido em três ou mais regiões diferentes. Mais de um nó por região. |
Node |
|
Alterar o fornecedor ou região de maior priority
If you change the Highest Priority provider or region in an active multi-region cluster, Atlas selects a new primary node in the provider and region that you specify (assuming that the number of nodes in each provider and region remains the same and nothing else is modified).
Se o backup em nuvem estiver ativado em seu cluster quando você alterar a região primária, o Atlas fará um snapshot sob demanda e o armazenará na nova região primária sem aguardar o próximo snapshot agendado. Se a nova região primária era anteriormente uma região de backup secundária para distribuição de cópias de snapshot, o Atlas atualizará automaticamente sua política de backup para distribuir cópias de snapshot da nova região primária para a região primária original e outras regiões secundárias.
Exemplo
Se você tiver um cluster ativo de 5 nós com a seguinte configuração:
Nodes | Fornecedor | Região | Priority |
|---|---|---|---|
3 | AWS | us-east-1 | Mais alta |
2 | Google cloud | us-west3 |
Para transformar os nós us-west3 do Google Cloud em Highest Priority, arraste sua linha até o topo da lista Electable nodes do seu cluster. Após essa alteração, o Atlas escolhe um novo PRIMARY em us-west3. O Atlas não inicia uma sincronização inicial ou reprovisiona hosts ao alterar essa configuração.
Importante
Certain circumstances may delay an election of a new primary.
Por exemplo, um cluster fragmentado com cargas de trabalho pesadas em seu fragmento primário pode atrasar a eleição. Isso resulta em não ter todos os nós de tipo primário na mesma região temporariamente.
Para minimizar esses riscos, evite modificar sua região primária durante períodos de carga de trabalho pesada.
Nós read-only para leituras locais ideais
Use nós read-only para otimizar leituras locais nas respectivas áreas de serviço dos nós.
Adicionar nós read-only
Você pode adicionar nós read-only da seção Read-Only Nodes for Optimal Local Reads.
Para adicionar um nó read-only em um fornecedor de nuvem e região:
Clique em Add a provider/region.
Selecione o provedor de nuvem no menu suspenso Provider.
Selecione a região no menu suspenso Region.
Quando você altera a opção Provider, o Region altera para uma opção em branco. Se você não selecionar uma região, o Atlas exibirá um erro ao clicar em Create Cluster.
Especifique o número desejado de Nodes para o provedor e região.
O Atlas considera as regiões marcadas com um conforme recomendado. Essas regiões oferecem alta disponibilidade em comparação com outras regiões.
Read-only nodes don't provide high availability because they don't participate in elections. They can't become the primary for their cluster. To direct queries to read-only nodes, use pre-defined replica set tags.
Remover nós read-only
Para remover todos os nós read-only em um provedor de nuvem e região, clique no ícone à direita desse provedor de nuvem e região.
Alterar a finalidade do volume de trabalho dos nós
Você pode alterar a finalidade do volume de trabalho de um nó adicionando e removendo nós ao mesmo tempo.
Observação
Você deve adicionar e remover o nó dentro da mesma alteração de configuração para reutilizá-lo. Se você remover o nó, salve a alteração e então adicione o nó de provisionamento, o Atlas fornece um novo nó.
For example, to change a read-only node to an electable node:
Clique em Review Changes.
Clique em Apply Changes.
Nós de analítica para isolamento do volume de trabalho
Use os nós de analítica para isolar as queries que você não deseja que entrem em conflito com seu volume de trabalho operacional. Os nós de análise ajudam a lidar com as operações de análise de dados, como reportar queries do BI Connector for Atlas. Para direcionar queries aos nós de análise, use tags predefinidas do conjunto de réplicas.
Observação
Você pode implantar nós de análise somente para clusters dedicados (M10 ou superior). Você não pode adicionar nós de análise em clusters gratuitos ou clusters Flex.
Para clusters do Atlas Infinite em visualização pública, especifique o número de Nodes. O Atlas os implanta na mesma região que o cluster do Atlas Infinite. Para clusters do Atlas Core, clique em Add a region para selecionar uma região e, em seguida, especifique o número de Nodes para essa região.
Observação
The readPreference and readPreferenceTags connection string options are unavailable for the mongo shell. To learn more, see cursor.readPref() and Mongo.setReadPref() instead.
Adicionar nós de analítica
Você pode adicionar nós de analítica a partir da seção Analytics nodes for workload isolation.
Para adicionar nós de analítica em um fornecedor de nuvem e região:
Clique em Add a provider/region.
Selecione o provedor de nuvem no menu suspenso Provider.
Selecione a região no menu suspenso Region.
Quando você altera a opção Provider, o Region altera para uma opção em branco. Se você não selecionar uma região, o Atlas exibirá um erro ao clicar em Create Cluster.
Especifique o número desejado de Nodes para o provedor e região.
O Atlas considera as regiões marcadas com um conforme recomendado. Essas regiões oferecem alta disponibilidade em comparação com outras regiões.
Os nós de analítica não oferecem alta disponibilidade porque não participam de eleições. Eles não podem se tornar o primário do cluster.
Selecionar uma camada de cluster para seus nós de analítica
Seus volumes de trabalho podem variar muito entre os nós de analítica e operacionais. Para ajudar a gerenciar esse problema, para clusters M10+ , você pode selecionar uma camada do cluster dimensionada adequadamente para seu volume de trabalho analítico. Você pode selecionar uma camada do cluster para seus nós de analítica que seja maior ou menor do que a camada do cluster selecionada para seus nós elegíveis e read-only (nós operacionais). Essa funcionalidade ajuda a garantir que você obtenha o desempenho necessário para suas queries transacionais e analíticas sem provisionar mais ou menos todo o cluster para seu volume de trabalho analítico.
As seguintes considerações se aplicam à aba Analytics Tier e nós de analítica:
Importante
Se você selecionar um tier do cluster na aba Analytics Tier significativamente abaixo do tier do cluster selecionado na guia Base Tier , poderá ocorrer um atraso de replicação . O nó de análise pode cair completamente do oplog.
Em clusters Atlas Core, se você selecionar uma camada do cluster General na aba Analytics Tier e uma camada do cluster Low-CPU na aba Base Tier, o dimensionamento automático de disco não será suportado para o cluster. O dimensionamento automático de disco também não é suportado se você selecionar uma camada do cluster General na aba Base Tier e uma camada do cluster Low-CPU na aba Analytics Tier.
Nos clusters Atlas Core, o tamanho do disco e o IOPS devem permanecer iguais em todos os tipos de nó.
Em clusters Atlas Core, o tamanho do armazenamento deve corresponder entre a aba Base Tier e a aba Analytics Tier. Você pode definir o tamanho do armazenamento na aba Base Tier. O Atlas expande o armazenamento de um cluster Atlas Infinite à medida que seus dados crescem, para que você não precise definir um tamanho de armazenamento.
Em cluster Atlas Core, se você deseja selecionar a classe Local NVME SSD na aba Base Tier, a aba Analytics Tier deverá ter o mesmo tier selecionado. Atlas Infinite clusters não oferecem suporte a armazenamento NVMe SSD anexado localmente em visualização pública.
Nos clusters do Atlas Core, se uma camada do cluster estiver esmaecida, isso significa que a camada do cluster não é compatível com o tamanho do disco do cluster ou com a classe Local NVME SSD.
Uma camada do cluster selecionada na aba Analytics Tier tem o mesmo preço de uma camada do cluster selecionada na aba Base Tier . No entanto, quando um Analytics Tier é maior ou menor do que o Base Tier, o preço é ajustado de acordo em uma base proporcional por nó. O preço aparece na UI do Atlas quando você cria ou edita um cluster. Para saber mais, consulte Gerenciar faturamento.
After you add your analytics nodes, you can select a cluster tier appropriately sized for your analytics workload.
Na seção Cluster Tier, clique na aba Analytics Tier.
Selecione o Cluster Tier.
Remover nós de analítica
Para remover todos os nós de analítica de um fornecedor de nuvem e região, clique no ícone à direita desse fornecedor de nuvem e região.
Nós de pesquisa para isolamento do volume de trabalho
Você pode definir os nós em seu cluster para executar somente o processo mongot do MongoDB Search. Quando executa o processo mongot do MongoDB Search separadamente, você melhora a disponibilidade e o balanceamento da carga de trabalho do processo mongot. Para saber mais, consulte Arquitetura do nó.
Importante
Nós de Pesquisa Dedicados não são compatíveis em clusters Atlas Infinite clusters durante a pré-visualização pública. Para os recursos com suporte na pré-visualização pública, consulte Disponibilidade da pré-visualização pública.
Considerações
Em clusters Atlas M10 ou superiores executando o MongoDB v6.0 e superior, você pode configurar os nós de pesquisa separadamente dos nós do banco de dados . Revise o seguinte antes de distribuir os nós do MongoDB Search separadamente.
Camada do cluster
Você pode implantar nós de pesquisa somente para clusters dedicados (M10 ou posterior). Você não pode adicionar nós de pesquisa em clusters de tier grátis (M0) ou clusters Flex. Você pode usar a interface do usuário do Atlas e a Atlas Administration API para provisionar nós de pesquisa para clusters novos e existentes na AWS, Google Cloud ou Azure.
Provedor de nuvem
Você pode hospedar os nós de pesquisa em qualquer provedor de nuvem. Você não pode distribuir nós de pesquisa separadamente para clusters globais.
Regiões do fornecedor de nuvem
O Atlas implanta os nós de pesquisa nas mesmas regiões AWS, Google Cloud, ou Azure que seus nós eleitorais, somente leitura e de análise.
O Atlas oferece suporte à implantação de nós de pesquisa separadamente para isolamento de carga de trabalho somente em regiões específicas da AWS, do Google Cloud e do Azure. O seguinte comportamento da IU do Atlas se aplica:
Se você selecionar qualquer uma das seguintes regiões AWS ou Azure para os nós do seu cluster primeiro, o Atlas desativará a alternância Search nodes for workload isolation.
Se você habilitar o Search nodes for workload isolation primeiro, o Atlas desativará o seguinte no menu suspenso para regiões abaixo de Electable nodes for high availability.
O Atlas não é compatível com as seguintes regiões do AWS, do Google Cloud e do Azure para nós de pesquisa.
Nome da região | Região AWS |
|---|---|
Bahrein |
|
Melbourne |
|
Nome da região | Região do Google Cloud |
|---|---|
Queretaro, México |
|
Berlim, Alemanha |
|
Dammam, Arábia Saudita |
|
Joanesburgo, África do Sul |
|
Nome da região | Região do Azure |
|---|---|
AUSTRALIA_CENTRAL_2 |
|
AUSTRALIA_SOUTH_EAST |
|
BRAZIL_SOUTHEAST |
|
CANADA_EAST |
|
GERMANY_NORTH |
|
INDIA_WEST |
|
INDIA_SOUTH |
|
ITALY_NORTH (disponível somente para nós de pesquisa com baixa CPU) |
|
JAPAN_WEST |
|
KOREA_SOUTH |
|
NORWAY_WEST |
|
SOUTH_AFRICA_WEST |
|
SPAIN_CENTRAL |
|
SWEDEN_SOUTH |
|
SWITZERLAND_WEST |
|
UAE_CENTRAL |
|
UK_WEST |
|
US_WEST_CENTRAL |
|
US_WEST |
|
Para implantar nós de pesquisa separadamente, você deve selecionar uma região compatível da AWS, Google Cloud ou Azure no menu suspenso Electable nodes for high availability. Para saber mais sobre as regiões compatíveis, consulte Regiões para nós de pesquisa dedicados. O Atlas usa automaticamente a mesma região para nós de análise e somente leitura em seu cluster. Após a implantação, você não pode alterar o provedor de nuvem nem a região dele para seu cluster do Atlas.
Clusters multirregionais e multinuvem
O Atlas oferece suporte à implantação de nós de pesquisa em várias regiões e provedores de nuvem. Ao implantar nós de pesquisa para clusters multirregionais ou multinuvem, considere o seguinte:
All nodes across regions have the same search tier.
Você pode implantar um mínimo de 2 e um máximo de 32 nós de pesquisa por região por shard.
Se você usar a Administration API do Atlas para adicionar uma nova região aos nós de pesquisa existentes, o Atlas implanta o mesmo número de nós de pesquisa na nova região. No entanto, se a nova região não for compatível com o nível de pesquisa atual, a solicitação falhará.
clusters fragmentados com nós de pesquisa
O Atlas requer um mínimo de dois nós de pesquisa para cada região em um cluster Atlas. Esse requisito se aplica a todos os tipos de cluster, incluindo clusters fragmentados.
Ao implantar clusters fragmentados que dependem muito do MongoDB pesquisa ou do MongoDB pesquisa vetorial, é crucial que entenda os requisitos de topologia do nó de pesquisa para garantir alta disponibilidade e desempenho ideal. Os seguintes requisitos de topologia se aplicam especificamente a clusters fragmentados com nós de pesquisa:
Implantações multirregionais: se o seu cluster abrange várias regiões, o Atlas implanta automaticamente o número especificado de nós de pesquisa em cada região que contém nós de banco de dados.
Número Mínimo de Nós: Cada região com nós de banco de dados deve ter pelo menos dois Nós de Pesquisa para manter a disponibilidade durante operações de manutenção ou falhas de nós.
Nível de pesquisa
Você pode selecionar um tier para os nós de pesquisa na aba Search Tier.
Por padrão, o Atlas implanta nós de pesquisa no S20. Você pode selecionar um nível superior para queries mais rápidas e agregações mais complexas, ou um nível inferior para cargas de trabalho menores. Se você quiser reduzir o tamanho para um nível inferior, o nível de pesquisa deverá acomodar quaisquer índices de pesquisa existentes, além de espaço em disco adicional para arquivos e logs.
S10 é o tier de pesquisa mais baixo e tem o tamanho certo para cargas de trabalho pequenas com pegadas de índice abaixo de 10 GB, como aquelas em cluster de M10 a M30. Como o S10 fornece menos armazenamento e menos vCPUs do que os tier mais altos, ele não é adequado para índices grandes ou cargas de trabalho intensivas em query. Para essas cargas de trabalho, selecione S20 ou superior.
For Search Nodes deployed on AWS, Atlas provides different search tiers in different regions. If the search tier that you selected is not available for your region, Atlas automatically deploys the search nodes in the next higher tier that is available in that region. To learn more, see AWS Search Tiers.
Para saber mais sobre os tiers de pesquisa dos nós de pesquisa implantados no Google Cloud ou no Azure, consulte:
Habilitar Encryption at rest
By default, MongoDB and search processes run on the same nodes. With this architecture, customer-managed encryption applies to your database data, but it does not apply to search indexes.
Quando você habilita nós de pesquisa dedicados, os processos de pesquisa são executados em nós separados. Isso permite que você ative a criptografia de dados do nó de pesquisa, para que possa criptografar os dados do banco de dados e os índices de pesquisa com as mesmas chaves gerenciadas pelo cliente para uma cobertura abrangente de criptografia.
Os nós de pesquisa dedicados não são suportados em clusters do Atlas Infinite clusters durante a visualização pública.
Observação
Database nodes and Search Nodes use different encryption methods with the same customer-managed keys. Database nodes use the WiredTiger Encrypted Storage Engine, while Search Nodes use encryption at the disk level.
Para aprender mais, consulte Habilitar o gerenciamento de chaves do cliente para nós de pesquisa.
Importante
Este recurso está disponível em todos os provedores de KMS.
Feed de atividade
O Atlas registra as operações de criação, atualização e exclusão de nós de pesquisa no Project Activity Feed. Cada entrada identifica o usuário que executou a ação. Para visualizar esses eventos, consulte Visualizar feed de atividades.
Adicionar nós de pesquisa
Para implantar nós de pesquisa, você deve ter acesso de Project Owner ao projeto.
Quando você adiciona nós de pesquisa a um cluster que não tem nenhum nó de pesquisa, os processos mongot existentes em execução junto com mongod gravações com cauda no banco de dados , o que acontece depois que o MongoDB Search conclui a sincronização inicial e os processos mongot no novos nós de pesquisa dedicados executam uma sincronização inicial nas coleções necessárias. Isso resulta em leituras duplas durante o processo de migração.
Remover nós de pesquisa
Se você excluir todos os nós de pesquisa existentes no cluster, haverá uma interrupção no processamento dos resultados da query de pesquisa enquanto o Atlas migra de mongot processos executados separadamente em nós de pesquisa dedicados para processos mongot executados junto com mongod. Você puder executar consultas enquanto os índices estão sendo criados no nó que hospeda os processos mongot e mongod , e você observará tempo de inatividade da query.
Isolamento de carga de trabalho em cluster Atlas Infinite
Durante a visualização pública, os cluster Atlas Infinite oferecem suporte às seguintes opções de isolamento de carga de trabalho:
Para adicionar esses nós a um cluster do Atlas Infinite, especifique o número de Nodes para cada tipo de nó. O Atlas implanta os nós na mesma região que o cluster do Atlas Infinite, portanto, você não seleciona um provedor de nuvem ou região para eles. Para aprender quais regiões os clusters do Atlas Infinite suportam, consulte a coluna Atlas Infinite Support na tabela de regiões da Amazon Web Services (AWS).
Limitações
Para obter a lista completa de recursos que o Atlas Infinite suporta na visualização pública, consulte Disponibilidade da Visualização Pública. As seguintes limitações se aplicam ao isolamento da carga de trabalho:
Os cluster Atlas Infinite não oferecem suporte a cluster multirregional.
Os clusters Atlas Infinite não são compatíveis com clusters multinuvem.
Os clusters do Atlas Infinite não oferecem suporte à adição de nós elegíveis adicionais.
Os clusters Atlas Infinite não oferecem suporte a Search Nodes.
Conexões com sistemas multinuvem
Observação
Este recurso não é aplicável ao Atlas Infinite. Para aprender mais sobre as funcionalidades e o comportamento do Atlas Infinite, consulte MongoDB Atlas Infinite: Visão geral.
Se estiver se conectando a conjuntos de réplicas hospedados em uma implantação multinuvem por meio de uma conexão privada, poderá acessar somente os nós no mesmo provedor de nuvem e na mesma região da qual você está se conectando. Esse provedor de nuvem pode não ter o nó primário em sua região. Quando isso acontece, você deve especificar o modo preferência de leitura secundária na string de conexão para acessar a implantação. Se precisar acessar todos os nós do sistema multinuvem do provedor atual por meio de uma conexão privada, você deve:
Configurar uma VPN para cada fornecedor restante.
Configure um endpoint privado para o Atlas para cada um dos provedores restantes.
Como alternativa, sugerimos a criação de clusters fragmentados para implantações em várias nuvens acessadas por meio de um endpoint privado. Quando você implanta um cluster de fragmentos, seja um único fragmento ou vários fragmentos, pode se conectar ao cluster por meio de pontos de extremidade privados locais e realizar operações de leitura e gravação. Você não precisa especificar o modo secundário de preferência de leitura, mesmo que os nós primários do cluster estejam localizados em uma região diferente. O mongos na região do provedor de nuvem à qual você se conecta encaminhará a solicitação para o nó primário em uma região diferente, se necessário. Para saber mais, consulte Implantação de um cluster fragmentado.