[SERVER-3568] MongoException "norepl" is thrown when data is inserted in a sharded environment using WriteConcern "ReplicasSafe". Created: 10/Aug/11 Updated: 15/Aug/12 Resolved: 08/May/12 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication, Sharding |
| Affects Version/s: | 1.8.2, 1.9.1 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Michael Wagner | Assignee: | Scott Hernandez (Inactive) |
| Resolution: | Duplicate | Votes: | 4 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Ubuntu 10.10 x86_64 |
||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Operating System: | ALL | ||||||||
| Participants: | |||||||||
| Description |
|
To test the mongoDb sharding capabilities we have continuously inserted data into a single shard consisting of one replica set (1 Master, 1 Secondary and 1 Arbiter). Almost every time a chunk is splitted (as indicated by the mongod log file of the master) a MongeException "norepl" occurs. We are using the mongo java driver 2.6.2 but could also reproduce the problem with the php driver. This only happens when we use the WriteConcern "ReplicasSafe". To reproduce the problem a java maven project is attached to this issue. Here are the necessary steps to run the application:
|
| Comments |
| Comment by Scott Hernandez (Inactive) [ 08/May/12 ] |
|
It means no replication (is enabled). This caused by |
| Comment by A Mare [ 08/May/12 ] |
|
We too encounter this error when continuously inserting binary files into a MongoDB database setup with shards and replicas. And we too use the REPLICAS_SAFE WriteConcern. I had to put some sleep time between the each resource insertion into the database (where a resource is made up of several binary files). This pause alleviates the problem in the sense that fewer resources fail upon insertion, but some of them still fail. Attempting to insert again the failed resources succeeds... Also, could you include in the exception a far more expressive wording than an enigmatic abbreviation like "norepl"? Which, by the way, what does it stand for: "no reply" or "no replica"? 'cause we've made bets on that over here. Thanks. |
| Comment by Michael Wagner [ 22/Sep/11 ] |
|
We could reproduce this issue with mongoDb version 2.0.0. To create the test environment we have stopped all mongo processes, replaced the old binaries, performend a clean up upon all data and finally started all mongo processes again. |
| Comment by Michael Wagner [ 22/Sep/11 ] |
|
Additional hint: this issue only appears if we use one replica set defined as a shard |
| Comment by Michael Wagner [ 22/Sep/11 ] |
|
Here is our configuration #replica set: , , , #config.shards: ] |