[SERVER-17129] logOp fassert when creating namespace on stepped-down primary via legacy update Created: 30/Jan/15  Updated: 18/Sep/15  Resolved: 30/Jan/15

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: 3.0.0-rc7
Fix Version/s: 3.0.0-rc8

Type: Bug Priority: Critical - P2
Reporter: Kamran K. Assignee: Eric Milkie
Resolution: Done Votes: 0
Labels: 28qa
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-16599 copydb/clone commands can crash the s... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Participants:

 Description   

This bug only seems to apply to non-write command mode. It does not seem to affect 2.6.7.

replSet error : logOp() but can't accept write to collection test.$cmd
Fatal Assertion 17405
 
#0  0x00007fcaa230b20b in raise (sig=5) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
#1  0x00000000018c2fd2 in mongo::breakpoint () at src/mongo/util/debugger.cpp:63
#2  0x00000000018b808a in mongo::fassertFailed (msgid=17405) at src/mongo/util/assert_util.cpp:165
#3  0x00000000015e8fa6 in mongo::repl::(anonymous namespace)::_logOpRS (txn=0x7fcaa270c7d0, opstr=0x1f7cd48 "c", ns=0x50b9588 "test.$cmd", logNS=0x0, obj=..., o2=0x0, bb=0x0, fromMigrate=false) at src/mongo/db/repl/oplog.cpp:238
#4  0x00000000015e9eaa in mongo::repl::logOp (txn=0x7fcaa270c7d0, opstr=0x1f7cd48 "c", ns=0x50b9588 "test.$cmd", obj=..., patt=0x0, b=0x0, fromMigrate=false) at src/mongo/db/repl/oplog.cpp:380
#5  0x000000000126fd6f in mongo::userCreateNS (txn=0x7fcaa270c7d0, db=0x4f88500, ns=..., options=..., logForReplication=true, createDefaultIndexes=true) at src/mongo/db/catalog/database.cpp:634
#6  0x0000000001440e93 in mongo::receivedUpdate (txn=0x7fcaa270c7d0, m=..., op=...) at src/mongo/db/instance.cpp:647
#7  0x000000000143f629 in mongo::assembleResponse (txn=0x7fcaa270c7d0, m=..., dbresponse=..., remote=..., fromDBDirectClient=false) at src/mongo/db/instance.cpp:463
#8  0x000000000113f4f8 in mongo::MyMessageHandler::process (this=0x4c48138, m=..., port=0x4c6f9d0, le=0x4c6f8e0) at src/mongo/db/db.cpp:206
#9  0x00000000018e11c6 in mongo::PortMessageServer::handleIncomingMsg (arg=0x4c6f9d0) at src/mongo/util/net/message_server_port.cpp:229
#10 0x00007fcaa2303182 in start_thread (arg=0x7fcaa270d700) at pthread_create.c:312
#11 0x00007fcaa140400d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111


Version: 94cb08d1d1a147



 Comments   
Comment by Githook User [ 02/Feb/15 ]

Author:

{u'username': u'milkie', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}

Message: SERVER-17129 check canAcceptWrites before implicitly creating ns for legacy upsert

(cherry picked from commit 8e11987b6f7f393bbf1c468f7626d2a4993ae0cb)
Branch: v3.0
https://github.com/mongodb/mongo/commit/f72cfa108021d1916edbeb554559c73f8766283d

Comment by Githook User [ 30/Jan/15 ]

Author:

{u'username': u'milkie', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}

Message: SERVER-17129 check canAcceptWrites before implicitly creating ns for legacy upsert
Branch: master
https://github.com/mongodb/mongo/commit/8e11987b6f7f393bbf1c468f7626d2a4993ae0cb

Comment by Eric Milkie [ 30/Jan/15 ]

I've proposed a code fix. In testing with a 2.4 shell, I get the expected result:

foo:SECONDARY> db.foo9.update({a:1},{a:2}, {upsert:true})
Not primary while performing update on test.foo9

In a 2.8 shell in legacy-write mode, it seems to swallow the exception and just shows that it didn't do any upserts:

foo:SECONDARY> db.foo7.update({a:1},{a:2}, {upsert:true})
WriteResult({ "nMatched" : 0, "nUpserted" : 0 })

I'm not sure if this behavior is intentional, but at least it's the same as 2.6.

Comment by Eric Milkie [ 30/Jan/15 ]

I suspect the bug is as simple as attempting to send a legacy upsert to a secondary for a namespace that doesn't yet exist.

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