[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: Zip Archive mongo-sharding-test.zip    
Issue Links:
Duplicate
duplicates SERVER-5243 mongos will route getLastError comman... Closed
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:

  • Read the README.txt to see the necessary test setup.
  • Adapt the "config.properties" to use the correct mongos uri and writeconcern.
  • Start the Inserter (located in src\main\java\com\seitenbau\testing\mongo\runner) main method and watch the console output.


 Comments   
Comment by Scott Hernandez (Inactive) [ 08/May/12 ]

It means no replication (is enabled). This caused by SERVER-5243, in which the safe check (getlasterror) is incorrectly sent to the config servers and not the shards.

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:
PRIMARY> rs.status()
{
"set" : "shard1",
"date" : ISODate("2011-09-22T12:56:08Z"),
"myState" : 1,
"members" : [
{
"_id" : 0,
"name" : "mongo-master1:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"optime" :

{ "t" : 1316696168000, "i" : 210 }

,
"optimeDate" : ISODate("2011-09-22T12:56:08Z"),
"self" : true
},
{
"_id" : 1,
"name" : "mongo-secondary1:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 768,
"optime" :

{ "t" : 1316696168000, "i" : 111 }

,
"optimeDate" : ISODate("2011-09-22T12:56:08Z"),
"lastHeartbeat" : ISODate("2011-09-22T12:56:08Z"),
"pingMs" : 0
},
{
"_id" : 2,
"name" : "mongo-secondary1:4444",
"health" : 1,
"state" : 7,
"stateStr" : "ARBITER",
"uptime" : 778,
"optime" :

{ "t" : 0, "i" : 0 }

,
"optimeDate" : ISODate("1970-01-01T00:00:00Z"),
"lastHeartbeat" : ISODate("2011-09-22T12:56:08Z"),
"pingMs" : 0
}
],
"ok" : 1
}

#config.shards:
mongos> db.shards.find().toArray()
[

{ "_id" : "shard1", "host" : "shard1/mongo-master1:27017,mongo-secondary1:27017" }

]

Generated at Thu Feb 08 03:03:25 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.