[SERVER-1606] Oplog entries contain repeated fields ($set) Created: 10/Aug/10 Updated: 12/Jul/16 Resolved: 28/Jan/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 2.2.4, 2.4.0-rc0 |
| Type: | Bug | Priority: | Critical - P2 |
| Reporter: | Dwight Merriman | Assignee: | Eliot Horowitz (Inactive) |
| Resolution: | Done | Votes: | 2 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||
| Description |
|
if a change occurs we need to be careful about backward compatibility / mixing of versions with replication, which is common. Jason Toffaletti to mongodb-user > db.test2.update( {thing:'stuff'}, {$set: {stuff:14}, $inc:{version:1}}) While doing this I have a pymongo 1.5.1 script running a tailable update {u'o2': {u'_id': ObjectId('4c610b301a632ffb5161c3e8')}, u'ns': , u'ns': , u'ns': This is strange, the "o" field only shows the update to version. What > db['oplog.$main'].find( {op:"u"}) , "op" : "u", "ns" : , , "$set" : { "stuff" : 1 } } } , "op" : "u", "ns" : , , "$set" : { "stuff" : 1346 } } } , "op" : "u", "ns" : , , "$set" : { "stuff" : 14 }} } Wait, what? This doesn't have the version update, but shows the $set |
| Comments |
| Comment by RalphSu [ 21/Mar/13 ] |
|
Thanks for quick response , Eliot. Re-check the v2.4.0 release, confirm fixed. My bad to have v2.2 mongo in path, then try typing mongod instead of ./mongod Many thanks. |
| Comment by Eliot Horowitz (Inactive) [ 21/Mar/13 ] |
|
Its fixed in 2.4.0, but its fixed in the replication code. |
| Comment by RalphSu [ 21/Mar/13 ] |
|
I'm encounting the same issue on v2.2. As this bug is closed with fix version 2.2.4(don't find the release on download page through) and v2.4.0. I did try the offcial v2.4.0 on my unbuntu, still see the same thing }, }, }, }, }, }, }, }, }, } , , , , Above two items seems to be exactly the same as https://groups.google.com/forum/?fromgroups=#!topic/mongodb-user/eDPGj9nS6_A mentioned. My question is: |
| Comment by auto [ 21/Mar/13 ] |
|
Author: {u'date': u'2013-01-28T15:55:04Z', u'name': u'Eliot Horowitz', u'email': u'eliot@10gen.com'}Message: Conflicts: src/mongo/dbtests/updatetests.cpp |
| Comment by auto [ 28/Jan/13 ] |
|
Author: {u'date': u'2013-01-28T15:55:04Z', u'email': u'eliot@10gen.com', u'name': u'Eliot Horowitz'}Message: |
| Comment by Scott Hernandez (Inactive) [ 27/Dec/12 ] |
|
This is becoming more of a critical issues since 2.2.1 where there were other replication changes which seems to have increased the likelihood of this occurring. |
| Comment by Vasily [ 05/Sep/12 ] |
|
The better way to resolve this problem is combine all $set operations to one. For example: {$set: {stuff:14}, $inc:{version:1}} Will be looks like {$set: {version:1}, $set:{version:1}} in oplog. But it should looks like {$set:{stuff:14, version:1}} Will you fix this bug in closest time? |
| Comment by Andy Schwerin [ 08/May/12 ] |
|
Scott requests backport to 2.0.6. |
| Comment by Chip Salzenberg [ 03/Aug/11 ] |
|
So ... any thoughts/progress on this? |
| Comment by Jason Toffaletti [ 10/Aug/10 ] |
|
Ahh, I think I understand what is going on now. The client libraries are using map data-types that don't properly support different elements having the same key ($set). Two solutions come to mind: 1) All clients are modified to support STL multimap-like semantics for BSON/JSON Object type. This seems like it would break a lot of client code that is expecting: o["this"] = 1 to result in {"this":2}not {"this":1, "this":2}. An alternative would be to introduce a new multimap type. That is returned if the BSON contains two matching keys, and can be used to create this type of BSON. 2) The format of the oplog can change, for example something like this might work: {"o":[{_id: ObjectId("4c610b301a632ffb5161c3e8")}, {$set: { "stuff" : 1346 }}, {$set: {"version":3.0}}], ....} This could potentially break backwards compatibility for newer mongod versions being replicated to older slave versions. |