sparse primary indexes index drop createindexes constraint mongodb mongodb-query wiredtiger

primary - mongodb imposible(?) E11000 duplicar la clave dup key al sobresaltar



set unique field mongodb (1)

Según tengo entendido, la actualización con upsert: true en un solo documento es una operación atómica, por lo que nunca debería generar un error de clave duplicada, especialmente no en la clave _id principal, cuando la colección no tiene campos indexados de forma exclusiva:

Order.update({ _id: order._id }, query, { upsert: true }, cb) // with mongoose

Pero esto aparece en el mongod.log:

2015-03-27T09:39:10.349-0400 I WRITE [conn258236] update xyz.orders query: { _id: "6353f880-c6a7-4260-809f-98e0af27b9a2" } update: { $set: { ... } keyUpdates:0 writeConflicts:0 **exception: E11000 duplicate key error dup key: { : "6353f880-c6a7-4260-809f-98e0af27b9a2" } code:11000** numYields:1 locks:{} 138ms 2015-03-27T09:39:10.349-0400 I COMMAND [conn258236] command xyz.$cmd command: update { update: "orders", writeConcern: { w: 1 }, ordered: true, updates: [ { q: { _id: "6353f880-c6a7-4260-809f-98e0af27b9a2" }, u: { $set: { ... } }, multi: false, upsert: true } ] } keyUpdates:0 writeConflicts:0 numYields:0 reslen:235 locks:{} 139ms

Aquí está la salida de db.orders.getIndexes() :

{ "v" : 1, "key" : { "_id" : 1 }, "name" : "_id_", "ns" : "xyz.orders" },

Estamos utilizando la versión 3.0.0 de MongoDB con WiredTiger.


Me temo que este es un problema continuo. Tuve el mismo problema y encontré un ticket de jira sobre esto:

https://jira.mongodb.org/browse/SERVER-14322

Es posible que dos actualizaciones lleguen con upsert: true, lo que resulta en que no se encuentre un documento y que se inserten nuevos documentos que entran en conflicto en violaciones de índice únicas del predicado de la consulta.

La "solución" aquí es agregar un código de reintento al cliente.