ApsaraDB for MongoDB:Transactions et Read/Write Concern

// Create collections.
db.getSiblingDB("mydb1").foo.insertOne(
    {abc: 0},
    { writeConcern: { w: "majority", wtimeout: 2000 } }
)
db.getSiblingDB("mydb2").bar.insertOne(
   {xyz: 0},
   { writeConcern: { w: "majority", wtimeout: 2000 } }
)
// Start a session.
session = db.getMongo().startSession( { readPreference: { mode: "primary" } } );
coll1 = session.getDatabase("mydb1").foo;
coll2 = session.getDatabase("mydb2").bar;
// Start a transaction.
session.startTransaction( { readConcern: { level: "local" }, writeConcern: { w: "majority" } } );
// Perform operations in the transaction.
try {
   coll1.insertOne( { abc: 1 } );
   coll2.insertOne( { xyz: 999 } );
} catch (error) {
   // Abort the transaction if an error occurs.
   session.abortTransaction();
   throw error;
}
// Commit the transaction.
session.commitTransaction();
session.endSession();

Privilégiez les transactions autonomes aux transactions distribuées

Les transactions distribuées offrent des performances inférieures à celles des transactions autonomes en raison de leur logique plus complexe. Dans MongoDB, les modèles de données dénormalisés (documents intégrés et tableaux) restent le meilleur choix. Avec une modélisation des données appropriée, les transactions autonomes répondent à la plupart des besoins transactionnels.

Évitez les transactions de longue durée

MongoDB abandonne automatiquement les transactions distribuées qui s'exécutent pendant plus de 60 secondes. Divisez les grandes transactions en parties plus petites et assurez-vous que les requêtes utilisent des index appropriés pour une exécution rapide.

Évitez de modifier trop de documents dans une seule transaction

Bien qu'il n'y ait pas de limite stricte au nombre de documents pouvant être lus dans une transaction, la modification de nombreux documents augmente la charge de synchronisation entre le primaire et les secondaires, ce qui peut entraîner un retard de réplication. Limitez les modifications à 1 000 documents par transaction. Pour des lots plus importants, divisez-les en plusieurs transactions.

Évitez les transactions volumineuses dépassant 16 Mo

Dans MongoDB 4.0, une transaction utilise une seule entrée oplog limitée à 16 Mo. Les opérations de mise à jour stockent les changements incrémentiels ; les insertions stockent les documents complets. Si l'oplog combiné dépasse 16 Mo, la transaction est abandonnée et annulée.

MongoDB 4.2 et versions ultérieures peuvent diviser les écritures de transaction sur plusieurs entrées oplog, supprimant ainsi la limite d'une seule entrée de 16 Mo. Cependant, maintenez la taille des transactions inférieure à 16 Mo pour éviter d'autres problèmes.

Gérez les annulations de transaction côté client

Lorsqu'une transaction est abandonnée, elle renvoie une exception et est annulée. Votre application doit intercepter ces exceptions et réessayer en cas d'erreurs transitoires (basculement primaire/secondaire, panne de nœud). Bien que les pilotes MongoDB retent automatiquement les validations via Retryable Writes, l'application doit toujours gérer les erreurs non retenantables telles que TransactionTooLarge, TransactionTooOld et TransactionExceededLifetimeLimitSeconds.

Évitez d'effectuer des opérations DDL dans les transactions

Les opérations DDL telles que createIndex ou dropDatabase sont bloquées par les transactions actives sur la même base de données ou collection. Les opérations DDL bloquées empêchent les nouvelles transactions d'acquérir des verrous, ce qui entraîne leur abandon.

MongoDB 4.4 a assoupli ces restrictions via le paramètre shouldMultiDocTxnCreateCollectionAndIndexes. Vous pouvez exécuter createCollection ou createIndex dans une transaction distribuée, avec les limites suivantes :

• Les collections ne peuvent être créées qu'implicitement.

• La collection cible ne doit pas déjà exister.

• La collection cible doit être vide.

Par conséquent, évitez d'effectuer des opérations DDL dans les transactions.

Annulez rapidement les transactions non validées ou erronées

Les modifications de transaction non validées résident dans le cache WiredTiger. Plusieurs transactions concurrentes non validées ou erronées peuvent exercer une pression sur le cache et causer d'autres problèmes. Annulez les transactions inutiles dès que possible pour libérer les ressources.

Augmentez le délai d'attente du verrou si les transactions sont fréquemment annulées

Par défaut, une opération de transaction est annulée si elle ne peut pas acquérir un verrou dans un délai de 5 millisecondes. Les verrous sont libérés lors de la validation ou de l'annulation. Si les délais d'attente de verrouillage entraînent des annulations fréquentes, augmentez le paramètre maxTransactionLockRequestTimeoutMillis.

Si l'augmentation du délai d'attente n'aide pas, vérifiez s'il existe des opérations qui conservent les verrous pendant de longues périodes, telles que des opérations DDL ou des requêtes non optimisées, et optimisez-les.

Évitez les modifications concurrentes du même document à l'intérieur et à l'extérieur d'une transaction

Si une écriture externe modifie un document qu'une transaction en cours modifie également, la transaction est annulée en raison d'un conflit d'écriture. À l'inverse, si une transaction détient déjà un verrou sur un document, les écritures externes sur ce document attendent la fin de la transaction.

En cas de conflit d'écriture, l'écriture externe n'échoue pas. MongoDB la tente en interne, en incrémentant le compteur writeConflicts jusqu'à ce qu'elle réussisse. Le client perçoit une opération réussie mais plus lente.

Un petit nombre de conflits d'écriture a un impact minimal. Des conflits d'écriture fréquents dégradent les performances. Utilisez les journaux d'audit ou les journaux de requêtes lentes pour détecter les conflits d'écriture excessifs.

Pour les transactions distribuées, définissez le Read Concern pour la transaction, et non pour les opérations individuelles

Spécifiez le Read Concern au niveau de la transaction. Le paramètre au niveau de la transaction remplace tous les autres paramètres ou valeurs par défaut de Read Concern.

Le Read Concern s'applique à toute requête de base de données, qu'il s'agisse d'une lecture sur un seul document, d'une lecture multi-documents ou d'une partie d'une transaction.

Utilisez le niveau de Read Concern "majority" pour les cas d'utilisation généraux

Définissez le Read Concern sur "majority" pour l'isolation et la cohérence. Cela garantit que l'application lit uniquement les données répliquées sur une majorité de nœuds, empêchant ainsi l'annulation lors de l'élection du primaire.

Pour les scénarios « Read Your Own Writes », lisez à partir du primaire et utilisez le niveau de Read Concern "local" ou "linearizable"

Lisez à partir du nœud primaire avec le Read Concern "local" ou "linearizable". Si le Write Concern est "majority", vous pouvez également utiliser le Read Concern "majority".

MongoDB 3.6+ prend également en charge les sessions causalement cohérentes pour ce scénario.

Pour les scénarios nécessitant la cohérence la plus forte, utilisez le Read Concern "linearizable" avec un délai d'attente maxTimeMS

Le niveau "linearizable" confirme que le nœud est toujours le primaire et que les données renvoyées ne seront pas annulées. Cependant, cela a un impact significatif sur la latence. Utilisez-le avec un délai d'attente maxTimeMS pour éviter un blocage indéfini si une majorité de nœuds devient indisponible.

{ w: <value>, j: <boolean>, wtimeout: <number> }

Pour les transactions distribuées, définissez le Write Concern pour la transaction, et non pour les opérations individuelles

La définition d'un Write Concern pour des opérations d'écriture individuelles au sein d'une transaction renvoie une erreur.

Utilisez le Write Concern "majority" pour les cas d'utilisation généraux

Le Write Concern "majority" garantit qu'une majorité des nœuds de l'ensemble de réplicas confirme l'écriture, empêchant ainsi la perte de données ou l'annulation même en cas de pannes de nœuds ou de basculements inattendus.

Pour les scénarios à forte intensité d'écriture, envisagez d'utiliser {w:1} et surveillez le retard de réplication des nœuds secondaires

{w:1} offre de meilleures performances d'écriture pour les scénarios à forte charge d'écriture. Cependant, surveillez le retard de réplication des nœuds secondaires. Un retard excessif peut amener le primaire à ROLLBACK. Si le retard dépasse la période de rétention de l'oplog, les secondaires entrent dans un état RECOVERING qui nécessite une intervention manuelle.

Lors du chargement par lot de données ou de la migration DTS sur une instance ApsaraDB for MongoDB exécutant une version antérieure à 5.0, utilisez le Write Concern "majority" si un retard excessif se produit.

Définissez le Write Concern le plus approprié pour différentes opérations

Le Write Concern peut être défini par opération. Par exemple, utilisez des transactions avec un Write Concern spécifique pour les données financières afin de garantir l'atomicité, "majority" pour les données principales des joueurs afin d'éviter l'annulation, et la valeur par défaut ou {w:1} pour les données de journalisation.

MongoDB offre cette flexibilité afin que les applications puissent choisir les paramètres appropriés en fonction de leurs exigences.