Considerações de produção

Disponibilidade

• O MongoDB oferece suporte a transações multidocumentos em conjuntos de réplicas.

• As transações distribuídas adicionam suporte para transações multidocumentos em clusters fragmentados e incorporam o suporte existente para transações multidocumentos em conjuntos de réplicas.

Compatibilidade de recursos

Para usar transações, a featureCompatibilityVersion para todos os membros da implantação deve ser pelo menos:

Para verificar o fCV de um membro, conecte-se ao membro e execute o comando:

db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

Para mais informações, consulte a página de referência do setFeatureCompatibilityVersion.

Limite de tempo de execução

Por padrão, uma transação deve ter um tempo de execução inferior a um minuto. Você pode modificar este limite utilizando transactionLifetimeLimitSeconds para as instâncias do mongod. Para agrupamentos fragmentados, o parâmetro deve ser modificado para todos os membros do conjunto de réplica de fragmento. As transações que excederem esse limite serão consideradas expiradas e serão abortadas por um processo de limpeza periódico.

Para agrupamentos fragmentados, você também pode especificar um limite do maxTimeMS no commitTransaction. Para mais informações, consulte Limite de Tempo de Transações de Clusters Compartilhados.

Limite de tamanho do Oplog

O MongoDB cria quantas entradas de oplog forem necessárias para encapsular todas as operações de gravação em uma transação, em vez de uma única entrada para todas as operações de gravação na transação. Isso remove o limite de tamanho total de 16 MB para uma transação imposta pela entrada única do oplog para todas as suas operações de gravação. Embora o limite de tamanho total tenha sido removido, cada entrada do oplog ainda deve estar dentro do limite de tamanho do documento BSON de 16 MB.

Cache do WiredTiger

Para evitar que a pressão do cache de armazenamento afete negativamente o desempenho:

• Ao abandonar uma transação, interrompa a transação.

• Quando você encontra um erro durante a operação individual na transação, cancele e tente novamente a transação.

O transactionLifetimeLimitSeconds também garante que as transações expiradas sejam abortadas periodicamente para aliviar a pressão do cache de armazenamento.

Transações e segurança

• Se estiver executando com controle de acesso, você deverá ter privilégios para as operações na transação.

• Se estiver sendo executado com auditoria, as operações em uma transação abortada ainda serão auditadas. No entanto, não há nenhum evento de auditoria que indique que a transação foi anulada.

Restrição de configuração de fragmento

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).

Clusters fragmentados e árbitros

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.

Adquirindo travas

Por padrão, as transações esperam até 5 milissegundos para adquirir as travas exigidas pelas operações na transação. Se a transação não puder adquirir suas travas necessárias dentro dos 5 milissegundos, a transação será cancelada.

As transações liberam todos os bloqueios ao serem abortadas ou confirmadas.

Operações e Transações DDL Pendentes

Se uma transação de vários documentos estiver em andamento, novas operações DDL que afetam o(s) mesmo(s) banco(s) de dados ou collection(ões) aguardam atrás da transação. Embora essas operações DDL pendentes existam, novas transações que acessam o(s) mesmo(s) banco(s) de dados ou coleção(ões) que as operações DDL pendentes não podem obter os travas necessárias e serão abortadas após a esperamaxTransactionLockRequestTimeoutMillis. Além disso, novas operações não transacionais que acessam o(s) mesmo(s) banco(s) de dados ou coleção(ões) serão bloqueadas até que atinjam seu limite maxTimeMS.

Considere os seguintes cenários:

Operação DDL que requer uma trava de collection

Enquanto uma transação em andamento executa várias operações CRUD na collection employees no banco de dados hr, um administrador emite a operação DDL db.collection.createIndex() na collection employees. createIndex() requer uma trava de collection exclusiva na collection.

Até que a transação em andamento seja concluída, a operação createIndex() deve aguardar para obter a trava. Qualquer nova transação que afete a collection employees e seja iniciada enquanto o createIndex() estiver pendente deve aguardar até que createIndex() seja concluída.

A operação DDL createIndex() pendente não afeta as transações em outras collections no database hr. Por exemplo, uma nova transação na contractors collection no hr banco de dados pode ser iniciada e concluída normalmente.

Operação DDL que requer um bloqueio de banco de dados

Enquanto uma transação em andamento executa várias operações CRUD na collection employees no banco de dados de dados hr , um administrador emite a operação DDL renameCollection para renomear a collection vendors.contractors para hr.contractors. renameCollection requer um bloqueio de banco de dados de dados no banco de banco de dados de destino (hr) quando difere do banco de banco de dados de origem (vendors).

Até que a transação em andamento seja concluída, a operação renameCollection deve aguardar para obter a bloqueio. Qualquer nova transação que afete o banco de dados hr ou qualquer uma de suas collections e seja iniciada enquanto renameCollection estiver pending deverá aguardar até a completes renameCollection .

Em qualquer um dos cenários, se a operação DDL permanecer pendente por mais de maxTransactionLockRequestTimeoutMillis, as transações pendentes que aguardam essa operação serão canceladas. Ou seja, o valor de maxTransactionLockRequestTimeoutMillis deve cobrir pelo menos o tempo necessário para que a transação em andamento e a operação DDL pendente sejam concluídas.

Transações em andamento e conflitos de gravação

Se uma transação estiver em andamento e uma gravação fora da transação modificar um documento que uma operação na transação tente modificar posteriormente, a transação será interrompida devido a um conflito de escrita.

Se uma transação estiver em andamento e tiver usado uma trava para modificar um documento, quando uma gravação fora da transação tentar modificar o mesmo documento, a gravação aguardará até que a transação termine.

Transações em andamento e leituras obsoletas

As operações de leitura dentro de uma transação podem retornar dados antigos, o que é conhecido como leitura obsoleta. Não é garantido que as operações de leitura dentro de uma transação vejam gravações executadas por outras transações confirmadas ou gravações não transacionais. Por exemplo, considere a seguinte sequência:

1. Uma transação está em andamento.

2. Uma gravação fora da transação exclui um documento.

3. Uma operação de leitura dentro da transação pode ler o documento agora excluído, pois a operação usa um snapshot de antes da operação de gravação.

Para evitar leituras obsoletas dentro das transações de um único documento, você pode usar o método db.collection.findOneAndUpdate(). O exemplo mongosh a seguir demonstra como você pode utilizar o db.collection.findOneAndUpdate() para fazer um bloqueio de gravação e garantir leituras atualizadas:

db.getSiblingDB("hr").employees.insertOne(
   { _id: 1, status: "Active" }
)

session = db.getMongo().startSession( { readPreference: { mode: "primary" } } )

session.startTransaction( { readConcern: { level: "snapshot" }, writeConcern: { w: "majority" } } )
employeesCollection = session.getDatabase("hr").employees

employeeDoc = employeesCollection.findOneAndUpdate(
   { _id: 1, status: "Active" },
   { $set: { lockId: ObjectId() } },
   { returnNewDocument: true }
)

session.commitTransaction()

Transações em andamento e migração de chunk

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