Considerações de produção ( cluster fragmentado)
Nesta página
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.
Desempenho
Shard Único
As transações destinadas a um único shard devem ter o mesmo desempenho que as transações do conjunto de réplicas.
Vários shards
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.
Limite de tempo
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.
Read concerns
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.
Write concerns
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}.
Árbitros
Você não pode alterar uma chave de shard usando uma transação se o conjunto de réplicas tiver um arbiter. 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.
Backups e restaurações
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:
Migrações de chunks
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 ...
Leituras Externas Durante a Confirmação
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.
Informações adicionais
Consulte também Considerações sobre a produção.