Menu Docs
Página inicial do Docs
/
Manual do MongoDB
/

Considerações de produção ( cluster fragmentado)

Nesta página

  • Desempenho
  • Read concerns
  • Write concerns
  • Árbitros
  • Backups e restaurações
  • Migrações de chunks
  • Leituras Externas Durante a Confirmação
  • Informações adicionais

Você pode executar transações multidocumento em clusters fragmentados.

A página a seguir lista as preocupações específicas da execução de transações em um cluster fragmentado. Essas preocupações são adicionais àquelas listadas em Considerações sobre a produção.

As transações destinadas a um único shard devem ter o mesmo desempenho que as transações do conjunto de réplicas.

As transações que afetam vários shards têm um custo de desempenho mais alto.

Observação

Em um cluster fragmentado, as transações que abrangem vários shards apresentarão erros e serão abortadas se algum shard envolvido contiver um arbiter.

Para especificar um limite de tempo, especifique um limite de maxTimeMS em commitTransaction.

Se maxTimeMS não for especificado, MongoDB utilizará o transactionLifetimeLimitSeconds.

Se maxTimeMS for especificado, mas resultar em uma transação que exceda transactionLifetimeLimitSeconds, o MongoDB usará o transactionLifetimeLimitSeconds.

Para modificar o transactionLifetimeLimitSeconds para um cluster fragmentado, o parâmetro deve ser modificado para todos os membros do conjunto de réplicas de shard.

As transações multidocumento aceitam níveis de read concern "local", "majority" e "snapshot".

Para transações em um cluster fragmentado, somente a read concern "snapshot" fornece um snapshot consistente em vários shards.

Para obter mais informações sobre read concern e transações, consulte Transações e read concern.

Não é possível executar transações em um cluster fragmentado que tenha um shard com writeConcernMajorityJournalDefault definido como false (como um shard com um membro votante que usa o mecanismo de armazenamento na memória).

Observação

Independentemente do write concern especificado para a transação, a operação de confirmação para uma cluster fragmentado inclui algumas partes que usam write concern {w: "majority", j: true}.

Você não pode alterar uma chave de shard usando uma transação se o conjunto de réplicas tiver um árbitro. Os árbitros não podem participar das operações de dados necessárias para transações com vários shards.

As transações cujas operações de gravação abrangem vários fragmentos gerarão o erro e serão abortadas se qualquer operação de transação ler ou gravar em um fragmento que contenha um árbitro.

Aviso

Para usar mongodump e mongorestore como estratégia de backup para clusters fragmentados, consulte Fazer backup de um cluster fragmentado autogerenciado com um descarte de banco de dados.

Os clusters fragmentados também podem usar um dos seguintes processos coordenados de backup e restauração, que mantêm as garantias de atomicidade das transações entre shards:

A migração de chunk adquire travas de collection exclusivas em alguns estágios.

Se uma transação em andamento tiver um bloqueio em uma collection e uma migração de partes que envolva o início dessa collection, esses estágios de migração deverão aguardar que a transação libere os bloqueios na collection, impactando assim o desempenho das migrações de chunks.

Se uma migração de chunk se intercalar com uma transação (por exemplo, se uma transação for iniciada enquanto uma migração de chunk já estiver em andamento e a migração for concluída antes que a transação trave a collection), a transação será interrompida durante a confirmação e será cancelada.

Dependendo de como as duas operações se intercalam, alguns exemplos de erros incluem (as mensagens de erro foram abreviadas):

  • an error from cluster data placement change ... migration commit in progress for <namespace>

  • Cannot find shardId the chunk belonged to at cluster time ...

Dica

Veja também:

Durante a confirmação de uma transação, operações de leitura externa podem tentar ler os mesmos documentos que serão modificados pela transação. Se a transação for gravada em vários shards, durante a tentativa de confirmação nos shards:

  • As leituras externas que usam a read concern "snapshot" ou "linearizable" aguardam até que todas as gravações de uma transação estejam visíveis.

  • As leituras externas que fazem parte de sessões causalmente consistentes (aquelas que incluem afterClusterTime) aguardam até que todas as gravações de uma transação estejam visíveis.

  • As leituras externas que usam outras read concerns não esperam até que todas as gravações de uma transação estejam visíveis, mas leem a versão anterior à transação dos documentos.

Dica

Veja também:

Consulte também Considerações sobre a produção.

Voltar

Considerações de produção