Menu Docs
Página inicial do Docs
/
MongoDB Atlas
/
Gerenciar clusters
/
Gerenciar clusters

Query usando marcações de conjunto de réplicas predefinidas

Nesta página

  • Descrições de marcações de conjunto de réplicas predefinidas
  • Estados do disco
  • Tipos de nó
  • Casos de uso e exemplos
  • Usar nós de analítica para isolar volumes de trabalho
  • Segmentar leituras locais para aplicativos distribuídos geograficamente
  • Reduza o impacto do aquecimento do disco secundário
  • Recuperar zonas de disponibilidade
  • Write concerns internas e personalizadas

Observação

Esta funcionalidade não está disponível para clusters gratuitos M0 e clusters M2 e M5. Para saber mais sobre quais recursos estão indisponíveis, consulte os limites do Atlas M0 (Free Cluster), M2 e M5.

Os clusters do Atlas são configurados com tags de conjunto de réplicas predefinidas para diferentes tipos de nós no cluster. Você pode usar essas tags de conjunto de réplicas predefinidas para direcionar queries de aplicativos específicos para tipos de nós, regiões e zonas de disponibilidade específicos. Estas tags de conjunto de réplicas predefinidas permitem personalizar a preferência de leitura de um conjunto de réplicas para melhorar o desempenho e a confiabilidade do cluster.

Observação

Estas marcações de conjunto de réplicas predefinidas são diferentes das marcações de recursos que você fornece e gerencia. Você não pode alterar as marcações de conjunto de réplicas que o Atlas fornece.

Para usar tags de conjunto de réplicas predefinidas em sua cadeia de conexão e direcionar as consultas para nós específicos, use as seguintes opções de cadeia de conexão:

  • readPreference

  • readPreferenceTags

  • readConcernLevel

Por exemplo, consulte Casos de uso e exemplos. Estas opções de connection string não estão disponíveis para o mongosh. Use cursor.readPref() e Mongo.setReadPref() .

Descrições de marcações de conjunto de réplicas predefinidas

A tabela abaixo descreve as marcações predefinidas do conjunto de réplicas que o Atlas fornece.

Nome da marcação predefinida
Descrição
Exemplo
Zona de disponibilidade

ID da zona de disponibilidade do AWS, nome totalmente qualificado do Google Cloud para uma zona ou número da zona do Azure.

O Azure aceita zonas de disponibilidade somente em um subconjunto de regiões. O Atlas fornece marcações de zona de disponibilidade predefinidas para o Azure somente para regiões que aceitam zonas de disponibilidade. Para saber mais, consulte Microsoft Azure.

Para obter mais informações sobre os possíveis valores do availabilityZone para cada fornecedor de nuvem, consulte a documentação do fornecedor de nuvem:

  • AWS: {"availabilityZone" : "use1-az1"}

  • Google Cloud: {"availabilityZone" : "us-east1-b"}

  • Azure: {"availabilityZone" : "1"}

Tipo de nó

Tipo de nó.

Os valores possíveis são:

  • ELECTABLE

  • READ_ONLY

  • ANALYTICS

Para obter mais informações, consulte Tipos de nós.

{"nodeType" : "ANALYTICS"}
Fornecedor

Fornecedor de nuvem no qual o nó é provisionado.

Os valores possíveis são:

  • AWS

  • GCP

  • AZURE

{"provider" : "AWS"}
Região

Região de nuvem na qual o nó reside.

Para obter uma lista completa dos possíveis valores do region, consulte a página de referência do seu fornecedor de nuvem:

{"region" : "US_EAST_2"}
Tipo de volume de trabalho

Marcação de conjunto de réplicas predefinida para distribuir o volume de trabalho uniformemente entre seus nós não analíticos (elegíveis ou read-only).

Os valores possíveis são:

  • OPERATIONAL

{"workloadType" : "OPERATIONAL"}
Estado do disco

Estado do seu disco.

Valor possível: READY

Para obter mais informações, consulte Estados do disco.

{"diskState" : "READY"}

Estados do disco

A tabela a seguir descreve os possíveis valores de diskState em suas tags de conjunto de réplica predefinidas.

Estado do disco
Descrição
READY

Somente nós quentes de destino.

Você pode executar queries sem ter uma latência aumentada ou imprevisível.

Para obter um exemplo dessa tag de conjunto de réplicas, consulte Reduzir o impacto do aquecimento do disco secundário.

Tipos de nó

A tabela a seguir descreve os possíveis valores de nodeType em suas tags de conjunto de réplica predefinidas.

Tipo de nó
Descrição
ELECTABLE
Leia a partir de nós elegíveis para serem eleitos primários. ELECTABLE nós correspondem a Electable nodes for high availability na interface de usuário de criação de cluster.
READ_ONLY
Leia a partir de nós somente leitura. Os nós READ_ONLY correspondem a Read-only nodes for optimal local reads na interface de criação do cluster.
ANALYTICS
Leia a partir de nós de análise somente para leitura. Os nós ANALYTICS correspondem a Analytics nodes for workload isolation na interface de criação do cluster.

Para saber como configurar nós de análise, somente leitura e eletrônica para seu cluster, consulte Configurar isolamento de alta disponibilidade e carga de trabalho.

Dica

Veja também:

Para obter detalhes sobre como essas tags de conjunto de réplicas predefinidas correspondem às preferências de leitura do BI Connector for Atlas, consulte a seção Opções de cluster do BI Connector na página Criar um cluster.

Casos de uso e exemplos

Considere os seguintes cenários em que a utilização de tags de conjunto de réplicas predefinidas seria benéfica e veja as cadeias de conexão de exemplo correspondentes.

Observação

Cada um dos seguintes exemplos de cadeias de conexão emprega a opção de cadeia de conexão do readConcernLevel=local. A especificação de uma preocupação de leitura local garante que as leituras secundárias em clusters fragmentados não retornem documentos órfãos. Você não precisa especificar esta opção ao conectar a conjuntos de réplicas não compartilhadas.

Usar nós de analítica para isolar volumes de trabalho

Se um aplicativo executar operações complexas ou de longa execução, como ETL ou relatórios, convém isolar as queries do aplicativo do restante da carga de trabalho operacional conectando-se exclusivamente aos nós de análise.

Considere a seguinte cadeia de conexão:

mongodb+srv://<USERNAME>:<PASSWORD>@foo-q8x1v.mycluster.com/test?readPreference=secondary&readPreferenceTags=nodeType:ANALYTICS&readConcernLevel=local

As opções de cadeia de conexão aparecem na seguinte ordem:

  • readPreference=secondary

  • readPreferenceTags=nodeType:ANALYTICS

  • readConcernLevel=local

A opção readPreference do secondary e readPreferenceTag do { nodeType : ANALYTICS } limitam as conexões do aplicativo para nós analíticos.

Isolar leituras secundárias normais de aplicativos dos nós do Analytics

Talvez você queira isolar leituras regulares de aplicativos da carga de trabalho em nós de análise.

Considere a seguinte cadeia de conexão:

mongodb+srv://<USERNAME>:<PASSWORD>@foo-q8x1v.mycluster.com/test?readPreference=secondary&readPreferenceTags=workloadType:OPERATIONAL&readConcernLevel=local

As opções de cadeia de conexão aparecem na seguinte ordem:

  • readPreference=secondary

  • readPreferenceTags=workloadType:OPERATIONAL

  • readConcernLevel=local

As opções especificadas impedem que seu aplicativo leia a partir de nós de análise. O aplicativo deve ler a partir de nós do operational ou não analíticos.

Segmentar leituras locais para aplicativos distribuídos geograficamente

Use tags de conjunto de réplicas predefinidas para direcionar leituras locais para regiões específicas para aplicativos distribuídos globalmente. Antes da introdução dessas tags de conjunto de réplicas predefinidas, as leituras locais para aplicativos distribuídos globalmente dependiam do cálculo correto da preferência de leitura mais próxima . Com marcas de conjunto de réplicas predefinidas, especificar marcas geográficas apropriadas em combinação com um modo de preferência de leitura de nearest fornece um comportamento mais consistente.

A cadeia de conexão a seguir prioriza as conexões com a região US_EAST_1 da AWS, seguida pela região US_EAST_2:

mongodb+srv://<USERNAME>:<PASSWORD>@foo-q8x1v.mycluster.com/test?readPreference=nearest&readPreferenceTags=provider:AWS,region:US_EAST_1&readPreferenceTags=provider:AWS,region:US_EAST_2&readPreferenceTags=&readConcernLevel=local

As opções de cadeia de conexão aparecem na seguinte ordem:

  • readPreference=nearest

  • readPreferenceTags=provider:AWS,region:US_EAST_1

  • readPreferenceTags=provider:AWS,region:US_EAST_2

  • readPreferenceTags=

  • readConcernLevel=local

O Atlas considera cada tag de preferência de leitura na ordem em que você as especifica. Depois que o Atlas associa um nó a uma tag, ele encontra todos os nós elegíveis que correspondem a essa tag. Atlas então ignora qualquer readPreferenceTags seguinte.

Neste exemplo, o aplicativo tenta primeiro se conectar a um nó na região US_EAST_1 da AWS. Se não houver nós disponíveis nessa região, o aplicativo tentará se conectar a um nó na região US_EAST_2 da AWS.

O readPreferenceTags= final (vazio) fornece uma opção de fallback. Com uma opção readPreferenceTags= vazia, o aplicativo pode se conectar a qualquer nó disponível, independentemente do provedor ou região.

Essas opções ajudam a garantir que o aplicativo se conecte à região geográfica mais próxima para reduzir a latência e melhorar o desempenho.

Observação

Você pode direcionar ainda mais leituras com base em zonas de disponibilidade.

Dica

Veja também:

Para obter informações adicionais e casos de uso para várias preferências de leitura, consulte a página Preferência de leitura no Manual do MongoDB.

Reduza o impacto do aquecimento do disco secundário

Quando o Atlas adiciona ou substitui um nó em seu cluster, ele executa o pré-aquecimento de disco por padrão. Durante o processo de pré-aquecimento do disco, o volume de armazenamento recém-criado passa por um período de uso pesado de IOPS . Isso reduz a velocidade das operações de leitura feitas nesse nó. Portanto, durante o processo de pré-aquecimento do disco, o Atlas mantém o nó de pré-aquecimento oculto por padrão, impedindo-o de participar de qualquer operação de leitura.

Se você preferir que um nó recém-adicionado ou substituído se torne imediatamente ativo e visível, poderá optar por desabilitar o pré-aquecimento de disco rápido e impedir operações de leitura em um nó de aquecimento usando uma string de conexão, como no exemplo a seguir:

mongodb+srv://<USERNAME>:<PASSWORD>@foo-q8x1v.mycluster.com/test?readPreference=secondary&readPreferenceTags=diskState:READY&readConcernLevel=local

As opções de cadeia de conexão aparecem na seguinte ordem:

  • readPreference=secondary

  • readPreferenceTags=diskState:READY

  • readConcernLevel=local

A opção readPreference de secondary e a opção readPreferenceTag de { diskState : READY } informam ao Atlas para direcionar apenas os nós quentes.

Recuperar zonas de disponibilidade

Por padrão, o Atlas fornece etiquetas de conjunto de réplica predefinidas para zonas de disponibilidade. Essas tags incluem o ID da zona de disponibilidade da AWS , o nome totalmente qualificado do Google Cloud para uma zona ou o número da zona do Azure . Você pode verificar a zona de disponibilidade de um nó utilizando o método de shell rs.conf() ou visualizando o último ping do nó de cluster.

Exemplo

...
"tags": {
          "availabilityZone": "use2-az2",
...

Write concerns internas e personalizadas

O Atlas fornece write concerns personalizados integrados para clusters multirregionais. A write concern descreve o nível de confirmação solicitado ao MongoDB para operações de gravação em um cluster.

As write concerns personalizada incorporadas do Atlas podem ajudar a melhorar a consistência dos dados, garantindo que suas operações sejam propagadas para um número definido de regiões para serem bem-sucedidas.

Para usar uma write concern personalizada, especifique a write concern no documento de write concern de sua operação.

O Atlas fornece as seguintes write concerns personalizadas para clusters multirregionais:

Escreva preocupação
Etiquetas
Descrição
twoRegions
{ region: 2 }
As operações de gravação devem ser reconhecidas por pelo menos duas regiões em seu cluster.
threeRegions
{ region: 3 }
As operações de gravação devem ser reconhecidas por pelo menos três regiões em seu cluster.
twoProviders
{ provider: 2 }
As operações de gravação devem ser reconhecidas por pelo menos duas regiões em seu cluster com provedores de nuvem distintos.

Exemplo

Considere um cluster de várias regiões em três regiões: us-east-1, us-east-2 e us-west-1. Você deseja que as operações de gravação se propaguem para todas as três regiões do cluster antes que o Atlas as aceite.

A operação a seguir insere um documento e exige que a operação seja propagada para todas as três regiões devido ao objeto { w: "threeRegions" } write concern:

db.employees.insertOne(
  { name: "Bob Smith", company: "MongoDB" },
  { writeConcern: { w: "threeRegions" } }
)
← Configurar alta disponibilidade e isolamento do volume de trabalho
Gerenciar instâncias sem servidor →

Nesta página