[SERVER-17205] logOp fassert when creating namespace on stepped-down primary via update Created: 06/Feb/15  Updated: 25/Jan/17  Resolved: 11/Feb/15

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

Type: Bug Priority: Major - P3
Reporter: Kamran K. Assignee: Benety Goh
Resolution: Done Votes: 0
Labels: 28qa
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-17150 logOp fassert when dropping collectio... Closed
is related to SERVER-15308 Stepdown does not cancel active (back... Closed
is related to SERVER-17208 logOp fassert when creating namespace... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Completed:
Participants:

 Description   

This bug only seems to affect 3.0 and not 2.6.7. I think it was previously masked by other logOp issues (e.g., SERVER-17150) rather than being a recent regression.

replSet error : logOp() but can't accept write to collection test.$cmd
Fatal Assertion 17405
 
#0  0x00007ff546b9f20b in raise (sig=5) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
#1  0x00000000018caaf4 in mongo::breakpoint () at src/mongo/util/debugger.cpp:63
#2  0x00000000018bfbac in mongo::fassertFailed (msgid=17405) at src/mongo/util/assert_util.cpp:165
#3  0x00000000015ef58a in mongo::repl::(anonymous namespace)::_logOpRS (txn=0x7ff51bd8b7d0, opstr=0x1f85608 "c", ns=0x4458b58 "test.$cmd", logNS=0x0, obj=..., o2=0x0, bb=0x0, 
    fromMigrate=false) at src/mongo/db/repl/oplog.cpp:238
#4  0x00000000015f048e in mongo::repl::logOp (txn=0x7ff51bd8b7d0, opstr=0x1f85608 "c", ns=0x4458b58 "test.$cmd", obj=..., patt=0x0, b=0x0, fromMigrate=false)
    at src/mongo/db/repl/oplog.cpp:380
#5  0x00000000012730db in mongo::userCreateNS (txn=0x7ff51bd8b7d0, db=0x4346690, ns=..., options=..., logForReplication=true, createDefaultIndexes=true)
    at src/mongo/db/catalog/database.cpp:634
#6  0x0000000001316289 in mongo::multiUpdate (txn=0x7ff51bd8b7d0, updateItem=..., result=0x7ff51bd88ae0) at src/mongo/db/commands/write_commands/batch_executor.cpp:1232
#7  0x0000000001313fc2 in mongo::WriteBatchExecutor::execUpdate (this=0x7ff51bd8a2b0, updateItem=..., upsertedId=0x7ff51bd89f70, error=0x7ff51bd89f48)
    at src/mongo/db/commands/write_commands/batch_executor.cpp:903
#8  0x0000000001313892 in mongo::WriteBatchExecutor::bulkExecute (this=0x7ff51bd8a2b0, request=..., upsertedIds=0x7ff51bd8a150, errors=0x7ff51bd8a130)
    at src/mongo/db/commands/write_commands/batch_executor.cpp:771
#9  0x000000000131181d in mongo::WriteBatchExecutor::executeBatch (this=0x7ff51bd8a2b0, request=..., response=0x7ff51bd8a2f0)
    at src/mongo/db/commands/write_commands/batch_executor.cpp:272
#10 0x000000000131b738 in mongo::WriteCmd::run (this=0x4035bf0, txn=0x7ff51bd8b7d0, dbName=..., cmdObj=..., options=0, errMsg=..., result=..., fromRepl=false)
    at src/mongo/db/commands/write_commands/write_commands.cpp:147
#11 0x00000000013376d7 in mongo::_execCommand (txn=0x7ff51bd8b7d0, c=0x4035bf0, dbname=..., cmdObj=..., queryOptions=0, errmsg=..., result=..., fromRepl=false)
    at src/mongo/db/dbcommands.cpp:1290
#12 0x0000000001338654 in mongo::Command::execCommand (txn=0x7ff51bd8b7d0, c=0x4035bf0, queryOptions=0, cmdns=0x4340014 "test.$cmd", cmdObj=..., result=..., fromRepl=false)
    at src/mongo/db/dbcommands.cpp:1506
#13 0x0000000001338f33 in mongo::_runCommands (txn=0x7ff51bd8b7d0, ns=0x4340014 "test.$cmd", _cmdobj=..., b=..., anObjBuilder=..., fromRepl=false, queryOptions=0)
    at src/mongo/db/dbcommands.cpp:1578
#14 0x000000000153c012 in mongo::runCommands (txn=0x7ff51bd8b7d0, ns=0x4340014 "test.$cmd", jsobj=..., curop=..., b=..., anObjBuilder=..., fromRepl=false, queryOptions=0)
    at src/mongo/db/query/find.cpp:137
#15 0x000000000153e03a in mongo::runQuery (txn=0x7ff51bd8b7d0, m=..., q=..., nss=..., curop=..., result=..., fromDBDirectClient=false) at src/mongo/db/query/find.cpp:606
#16 0x0000000001443f36 in mongo::receivedQuery (txn=0x7ff51bd8b7d0, c=..., dbresponse=..., m=..., fromDBDirectClient=false) at src/mongo/db/instance.cpp:220
#17 0x00000000014450e0 in mongo::assembleResponse (txn=0x7ff51bd8b7d0, m=..., dbresponse=..., remote=..., fromDBDirectClient=false) at src/mongo/db/instance.cpp:403
#18 0x0000000001142708 in mongo::MyMessageHandler::process (this=0x4002130, m=..., port=0x43471d0, le=0x43479f0) at src/mongo/db/db.cpp:206
#19 0x00000000018e8ce8 in mongo::PortMessageServer::handleIncomingMsg (arg=0x43471d0) at src/mongo/util/net/message_server_port.cpp:229
#20 0x00007ff546b97182 in start_thread (arg=0x7ff51bd8c700) at pthread_create.c:312
#21 0x00007ff545c9800d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111



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

Author:

{u'username': u'benety', u'name': u'Benety Goh', u'email': u'benety@mongodb.com'}

Message: SERVER-17205 check for primary step down after obtaining write lock

(cherry picked from commit d6ad41d4b7ef7bee4a28bc4c7e1013f1319d63c1)
Branch: v3.0
https://github.com/mongodb/mongo/commit/f411d9d96ce7ff0c7802e99f0b28129ac16b1f70

Comment by Githook User [ 11/Feb/15 ]

Author:

{u'username': u'benety', u'name': u'Benety Goh', u'email': u'benety@mongodb.com'}

Message: SERVER-17205 check for primary step down after obtaining write lock
Branch: master
https://github.com/mongodb/mongo/commit/d6ad41d4b7ef7bee4a28bc4c7e1013f1319d63c1

Comment by Githook User [ 07/Feb/15 ]

Author:

{u'username': u'benety', u'name': u'Benety Goh', u'email': u'benety@mongodb.com'}

Message: SERVER-17205 do not proceed with bulk update on the primary when it is stepped down

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

Comment by Githook User [ 07/Feb/15 ]

Author:

{u'username': u'benety', u'name': u'Benety Goh', u'email': u'benety@mongodb.com'}

Message: SERVER-17205 do not proceed with bulk update on the primary when it is stepped down
Branch: master
https://github.com/mongodb/mongo/commit/8cf51d1d88c8301253ba42c44db0f2fcb0e9a62e

Comment by Eric Milkie [ 06/Feb/15 ]

We can use checkIsMasterForDatabase() that Andy wrote, in that file.

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