[SERVER-5357] Map/Reduce operation writes output data in primary node of replica set but not in secondary nodes Created: 22/Mar/12 Updated: 11/Jul/16 Resolved: 06/Apr/12 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | MapReduce, Replication |
| Affects Version/s: | 2.0.3 |
| Fix Version/s: | 2.0.5, 2.1.1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Corentin Guy | Assignee: | Antoine Girbal |
| Resolution: | Done | Votes: | 0 |
| Labels: | mapreduce, replicaset | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
GNU Debian |
||
| Issue Links: |
|
||||
| Operating System: | Linux | ||||
| Participants: | |||||
| Description |
|
In a sharded / replica set environment, map/reduce output data are not written in secondary nodes : I have 9 nodes (6 nodes + 3 arbiters) shared between 3 replica sets (rs1, rs2, rs3). My map/reduce operation process a sharded collection, and write output result in a normal collection (non-sharded). As result, I have my output collection created in primay and secondary node, but only primary node contains data. I didn't found any information in logs.. I can show you replication status : PRIMARY> db.count_dm_4f6aef18d4ee7771b1a591e6.find(); // Returns my element { "_id" : "4f6aef18d4ee7771b1a591e6", "value" : 453 }PRIMARY> db.printReplicationInfo() SECONDARY> db.count_dm_4f6aef18d4ee7771b1a591e6.find(); // Returns nothing ... |
| Comments |
| Comment by auto [ 24/Apr/12 ] |
|
Author: {u'login': u'erh', u'name': u'Eliot Horowitz', u'email': u'eliot@10gen.com'}Message: backport of |
| Comment by auto [ 06/Apr/12 ] |
|
Author: {u'login': u'agirbal', u'name': u'agirbal', u'email': u'antoine@10gen.com'}Message: |
| Comment by auto [ 06/Apr/12 ] |
|
Author: {u'login': u'agirbal', u'name': u'agirbal', u'email': u'antoine@10gen.com'}Message: |
| Comment by Corentin Guy [ 04/Apr/12 ] |
|
Ok, tell me when the fix will be released (in 2.1 and 2.0.x branches). Thank you ! |
| Comment by Antoine Girbal [ 04/Apr/12 ] |
|
@Corentin the bug is identify and fix is easy. |
| Comment by Corentin Guy [ 03/Apr/12 ] |
|
There the full line for MR : db.Hit.mapReduce(m, r, {"out":"Tagdm"}); with The previous example is quite different than the one exposed in the ticket description, but it is simpler. There the sharding status : shards: { "_id" : "rs1", "host" : "rs1/192.168.0.5:10001,192.168.0.6:10001" } { "_id" : "rs2", "host" : "rs2/192.168.0.7:10001,192.168.0.8:10001" } { "_id" : "rs3", "host" : "rs3/192.168.0.10:10001,192.168.0.9:10001" }databases: { "_id" : "admin", "partitioned" : false, "primary" : "config" } { "_id" : "integration_stats", "partitioned" : true, "primary" : "rs3" } integration_stats.Hit chunks: And finally stats of sharded source collection : mongos> db.Hit.stats(); , , , , I understand in your last answer that bug seems to really exist. I don't really understand the origin of the bug, but it doesn't matter. So, how can I help for the correction ? Is the bug trully identified ? |
| Comment by Antoine Girbal [ 02/Apr/12 ] |
|
it looks like there is a bug there indeed, which I think as always been in mongo. |
| Comment by Antoine Girbal [ 02/Apr/12 ] |
|
can you provide:
|
| Comment by Corentin Guy [ 02/Apr/12 ] |
|
I've upgraded MongoDB version from 2.0.3 to 2.0.4, the "bug" is still there. |
| Comment by Corentin Guy [ 27/Mar/12 ] |
|
Please see following discussion on Google Group (some details in answers) : https://groups.google.com/forum/?fromgroups&pli=1#!topic/mongodb-user/NmnHOxT04A4 |