2015-03-27 22 views
14

Moje zrozumienie polega na tym, że aktualizacja z upsert: true na pojedynczym dokumencie jest operacją atomową, więc to nigdy nie powinno skutkować duplikatem błędu klucza, szczególnie nie w podstawowej _id klucz, gdy zbiór nie ma unikalne-ly indeksowane pola:mongodb impossible (?) E11000 duplikat key error dup key podczas wstawiania

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

Ale to pojawia się w 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 

Oto wyjściowy db.orders.getIndexes():

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

Używamy wersji MongoDB 3.0.0 z WiredTiger.

+0

Jaka jest wartość 'order.id 'i' query' - czy obie mają tę samą wartość '_id'? – DaveCoast

+0

Tak. Wiersze w dzienniku dotyczą konkretnego wywołania mangusty z parametrem order.id ustawionym na "6353f880-c6a7-4260-809f-98e0af27b9a2". – Jason

+0

Połączenia przychodzą z tego samego połączenia z '{w: 1}', więc prawdopodobnie są one szeregowe i nie współbieżne - w jaki sposób generujesz wartość 'order._id'? Czy jesteś pewien, że nie wywołałeś aktualizacji dwa razy tym samym 'order._id' w tym samym wątku/procesie? – wdberkeley

Odpowiedz

11

Obawiam się, że jest to ciągły problem. Miałem ten sam problem i znalazłem bilet Jira o tym:

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

Jest możliwe, że dwie aktualizacje przyjść z upsert: true, powodując ani ze znalezieniem dokumentu i oba wstawianie nowych dokumentów, które konflikt na unikalne naruszenie indeksów predykatu zapytania.

"Rozwiązaniem" jest tutaj dodanie do klienta kodu ponownej próby.

+6

Nadal mam ten problem z Mongo 3.4 ..... – db80

+2

Tak, to jest bardzo denerwujący błąd, nie mogę uwierzyć, że jest tam jeszcze w 3.4. Wykonanie ponownej próby nieskończonej reklamy po stronie klienta jest brzydkim obejściem problemu. – user2667976

+0

Powtórzmy tylko raz najwyżej. A jeśli w ogóle będzie potrzebna ponowna próba (z powodu zduplikowanego konfliktu), to spowoduje to aktualizację. – Shashank