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 M0
gratuitos e clusters M2
e M5
. Para saber mais sobre quais funcionalidades não estão disponíveis, consulte } Limites do Atlas M0 (cluster gratuito), 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.
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 |
|
Tipo de nó | Tipo de nó. Os valores possíveis são:
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:
| {"provider" : "AWS"} |
Região | {"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:
| {"workloadType" : "OPERATIONAL"} |
Estado 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://<db_username>:<db_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://<db_username>:<db_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://<db_username>:<db_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 fique imediatamente ativo e visível, você pode optar por desativar o pré-aquecimento rápido do disco e evitar operações de leitura em um nó de aquecimento usando uma string de conexão, como no exemplo a seguir:
mongodb+srv://<db_username>:<db_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. Estas marcações incluem o da zona de disponibilidade do Amazon Web Services ID, oGCP nome totalmente qualificado do para uma zona ou Azure o número da zona . 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" } } )