Writes block with custom getLastErrorModes

[Sebastian Friedel]

Hi, i'm trying to get a custom getLastErrorMode working, but currently whenever I try to write using it, the getLastError Command blocks forever.

I'm using the following ReplicaSet configuration.

{

"_id" : "test",

"version" : 220224,

"members" : [

{

"_id" : 2,

"host" : "10.1.0.3:27017",

"tags" : {

"important" : "mongo-02"

}

},

{

"_id" : 4,

"host" : "10.1.2.1:27017",

"priority" : 0,

"slaveDelay" : 14400,

"hidden" : true

},

{

"_id" : 0,

"host" : "10.1.0.1:27017",

"tags" : {

"important" : "mongo-00"

}

}

],

"settings" : {

"getLastErrorModes" : {

"twoimportant" : {

"important" : 2

}

}

}

}

I tried running the following test in the mongo cli:

PRIMARY> db.test.insert({foo: 'bar'})

PRIMARY> db.runCommand({getLastError: 1, w: 'twoimportant'})

the last command blocks until i kill it.

What I'm trying to accomplish is using the custom getLastErrorMode to ensure my writes got written to a majority of the nodes that can become PRIMARY while being flexible on the number of slaves I attach to the ReplicaSet.

Has anyone experienced this behaviour? Am I doing anything wrong here? I've read over all avaliable documentation for tagging and getLastErrorModes and as far as I could see this should work. Any help would be appreciated.

This was tested in ubuntu 12.04 with mongodb version 2.0.7.

Regards

Sebastian

[Gianfranco]

The tagging seems correct.

What's the output of rs.status() ? is possible that there's a replication lag between members _id 2 and 0, and that's why the getLastError command timesout.

[Sebastian Friedel]

My rs.status() output:

PRIMARY> rs.status()

{

"set" : "test",

"date" : ISODate("2012-09-25T11:20:42Z"),

"myState" : 1,

"syncingTo" : "10.1.0.1:27017",

"members" : [

{

"_id" : 0,

"name" : "10.1.0.1:27017",

"health" : 1,

"state" : 2,

"stateStr" : "SECONDARY",

"uptime" : 64575,

"optime" : {

"t" : 1348572042000,

"i" : 8

},

"optimeDate" : ISODate("2012-09-25T11:20:42Z"),

"lastHeartbeat" : ISODate("2012-09-25T11:20:42Z"),

"pingMs" : 0

},

{

"_id" : 2,

"name" : "10.1.0.3:27017",

"health" : 1,

"state" : 1,

"stateStr" : "PRIMARY",

"optime" : {

"t" : 1348572042000,

"i" : 8

},

"optimeDate" : ISODate("2012-09-25T11:20:42Z"),

"self" : true

},

{

"_id" : 4,

"name" : "10.1.2.1:27017",

"health" : 1,

"state" : 2,

"stateStr" : "SECONDARY",

"uptime" : 64575,

"optime" : {

"t" : 1348557640000,

"i" : 7

},

"optimeDate" : ISODate("2012-09-25T07:20:40Z"),

"lastHeartbeat" : ISODate("2012-09-25T11:20:40Z"),

"pingMs" : 0

}

],

"ok" : 1

}

What I forgot to mention in my initial post is that the write does succeed immediately if I use

PRIMART> db.runCommand({getLastError: 1, w: 2})

It also completes if i change my getLastErrorMode to {"twoimportant": {"important": 1}} and use getLastError with w: "twoimportant".

Regards

Sebastian

[Gianfranco]

Having

getLastErrorModes: {

  "twoimportant" : { "important" : 2 }

}

it means that number 2 is the different tagged values of the key that must be satisfied for the getLastError command to complete successfully.

So in those terms it should be ok.

Looking at the rs.status() _id 2 and _id 0 seem not to have any replication lag.

To test this I decided to run a replicaSet and check my self as well.

In deed the getLastError doesn't seem to work return.

Even with 1 primary and 2 secondaries with the "important" tag, non of them hidden and twoimportant: { important:2 }

I'm going to dig a little bit more tomorrow and see why this is happening, or if there's a mistake in the configuration we are both doing

---

Gianfranco

[Sebastian Friedel]

Hi Gianfranco,

thank you for looking into this problem. I got it working now by upgrading mongodb to version 2.2. This is not an issue for me because I wanted to upgrade anyway. I did not make any changes to my initial config besides I replaced the node with _id 4 with an actively writing member to make a smooth update transition.

Regards

Sebastian

[Gianfranco]

That's strange. I did try yesterday with 2.2.0

Can you post again your current config and the getLastError command you tried?

[Sebastian Friedel]

Of course, my current config:

{

"_id" : "test",

"version" : 220230,

"members" : [

{

"_id" : 2,

"host" : "10.1.0.3:27017",

"tags" : {

"important" : "mongo-02"

}

},

{

"_id" : 0,

"host" : "10.1.0.1:27017",

"tags" : {

"important" : "mongo-00"

}

},

{

"_id" : 1,

"host" : "10.1.0.2:27017",

"tags" : {

"important" : "mongo-01"

}

},

{

"_id" : 3,

"host" : "10.1.1.1:27017",

"priority" : 0,

"hidden" : true

},

{

"_id" : 4,

"host" : "10.1.2.1:27017",

"priority" : 0,

"slaveDelay" : 14400,

"hidden" : true

}

],

"settings" : {

"getLastErrorModes" : {

"twoimportant" : {

"important" : 2

}

}

}

}

and my insert / getLastError:

test:PRIMARY> db.test.insert({foo: 1})

test:PRIMARY> db.runCommand({getLastError: 1, w: 'twoimportant'})

{

"n" : 0,

"lastOp" : Timestamp(1348651919000, 10),

"connectionId" : 20878,

"wtime" : 0,

"err" : null,

"ok" : 1

}

Members with _id 4 and 5 were added after my tests yesterday, it worked with 2 or 3 members tagged "important".

Regards

Sebastain

[Gianfranco]

Hi Sebastain,

It didn't work for a bit, but now it works as well :)

If you happen to see this error again please let me know.

Best of luck,

Gianfranco