i have a 3-server replset, and today i found some strange messages in mongodb.log which never appeared before:
Fri Feb 20 10:17:12 [rsSync] Assertion: 10334:Invalid BSONObj size:
-286331154 (0xEEEEEEEE) first element: _id: ObjectId('54d96ab42d46d5c91edf6651') 0x588cb2 0x5077a1 0x8ba7f8
0x94572e 0x949e45 0x94c395 0x830411 0x82100b 0x821d85 0x8231d8
0x82439a 0x824820 0xaa4560 0x3ecf40683d 0x3ececd4f8d
/opt/mongo/bin/mongod(_ZN5mongo11msgassertedEiPKc+0x112) [0x588cb2]
/opt/mongo/bin/mongod(_ZNK5mongo7BSONObj14_assertInvalidEv+0x471)
[0x5077a1] /opt/mongo/bin/mongod(_ZNK5mongo7DiskLoc3objEv+0xa8)
[0x8ba7f8] /opt/mongo/bin/mongod [0x94572e]
/opt/mongo/bin/mongod(_ZN5mongo14_updateObjectsEbPKcRKNS_7BSONObjES2_bbbRNS_7OpDebugEPNS_11RemoveSaverE+0x2b85)
[0x949e45]
/opt/mongo/bin/mongod(_ZN5mongo13updateObjectsEPKcRKNS_7BSONObjES2_bbbRNS_7OpDebugE+0x125)
[0x94c395]
/opt/mongo/bin/mongod(_ZN5mongo21applyOperation_inlockERKNS_7BSONObjEb+0xb81)
[0x830411]
/opt/mongo/bin/mongod(_ZN5mongo11ReplSetImpl9syncApplyERKNS_7BSONObjE+0x1fb)
[0x82100b]
/opt/mongo/bin/mongod(_ZN5mongo11ReplSetImpl8syncTailEv+0xce5)
[0x821d85]
/opt/mongo/bin/mongod(_ZN5mongo11ReplSetImpl11_syncThreadEv+0xc8)
[0x8231d8]
/opt/mongo/bin/mongod(_ZN5mongo11ReplSetImpl10syncThreadEv+0x4a)
[0x82439a] /opt/mongo/bin/mongod(_ZN5mongo15startSyncThreadEv+0xa0)
[0x824820] /opt/mongo/bin/mongod(thread_proxy+0x80) [0xaa4560]
/lib64/libpthread.so.0 [0x3ecf40683d] /lib64/libc.so.6(clone+0x6d)
[0x3ececd4f8d] Fri Feb 20 10:17:12 [rsSync] replSet syncTail: 10334
Invalid BSONObj size: -286331154 (0xEEEEEEEE) first element: _id:
ObjectId('54d96ab42d46d5c91edf6651'), syncing: { ts: Timestamp
1424343003000|76, h: -3506864587493877515, v: 2, op: "u", ns:
"gingko.docindex", o2: { _id: ObjectId('54c220444a9d689b8ca0bb59') },
o: { $set: { l: 0 } } }
when i found these, mongo version is 1.4.9, then i update to 2.6.7, and restart the replset. after that, the error keep happening, and mongod process exit.
2015-02-20T11:05:11.962+0800 [repl writer worker 1] Assertion:
10334:BSONObj size: -286331154 (0xEEEEEEEE) is invalid. Size must be
between 0 and 16793600(16MB) First element: _id:
ObjectId('54d96ab42d46d5c91edf6651') 2015-02-20T11:05:11.972+0800
[repl writer worker 1] gingko.docindex 0x11fd1b1 0x119efa9 0x1183b56
0x11840ac 0x77402b 0xf02038 0xd34f4d 0xc4d1e9 0xc58f46 0xc47be7
0xe5684b 0xeba03e 0xeba950 0x119284e 0x1241b49 0x3ecf40683d
0x3ececd4f8d mongod(_ZN5mongo15printStackTraceERSo+0x21) [0x11fd1b1]
mongod(_ZN5mongo10logContextEPKc+0x159) [0x119efa9]
mongod(_ZN5mongo11msgassertedEiPKc+0xe6) [0x1183b56] mongod
[0x11840ac] mongod(_ZNK5mongo7BSONObj14_assertInvalidEv+0x41b)
[0x77402b] mongod(_ZNK5mongo7DiskLoc3objEv+0x68) [0xf02038]
mongod(_ZN5mongo12IDHackRunner7getNextEPNS_7BSONObjEPNS_7DiskLocE+0x33d)
[0xd34f4d]
mongod(_ZN5mongo6updateERKNS_13UpdateRequestEPNS_7OpDebugEPNS_12UpdateDriverEPNS_14CanonicalQueryE+0x9a9)
[0xc4d1e9] mongod(_ZN5mongo14UpdateExecutor7executeEv+0x66)
[0xc58f46]
mongod(_ZN5mongo6updateERKNS_13UpdateRequestEPNS_7OpDebugE+0x27)
[0xc47be7]
mongod(_ZN5mongo21applyOperation_inlockERKNS_7BSONObjEbb+0x199b)
[0xe5684b]
mongod(_ZN5mongo7replset8SyncTail9syncApplyERKNS_7BSONObjEb+0x4fe)
[0xeba03e]
mongod(_ZN5mongo7replset14multiSyncApplyERKSt6vectorINS_7BSONObjESaIS2_EEPNS0_8SyncTailE+0x50)
[0xeba950] mongod(_ZN5mongo10threadpool6Worker4loopEv+0x19e)
[0x119284e] mongod [0x1241b49] /lib64/libpthread.so.0 [0x3ecf40683d]
/lib64/libc.so.6(clone+0x6d) [0x3ececd4f8d]
2015-02-20T11:05:11.972+0800 [repl writer worker 1] ERROR: writer
worker caught exception: :: caused by :: 10334 BSONObj size:
-286331154 (0xEEEEEEEE) is invalid. Size must be between 0 and 16793600(16MB) First element: _id:
ObjectId('54d96ab42d46d5c91edf6651') on: { ts: Timestamp
1424343003000|76, h: -3506864587493877515, v: 2, op: "u", ns:
"gingko.docindex", o2: { _id: ObjectId('54c220444a9d689b8ca0bb59') },
o: { $set: { l: 0 } } } 2015-02-20T11:05:11.972+0800 [repl writer
worker 1] Fatal Assertion 16360 2015-02-20T11:05:11.972+0800 [repl
writer worker 1]
***aborting after fassert() failure
the table "gingko.docindex" have 120 million records, read heavy, write not so heavy. by the way, another slave is all right when syncing, and the whole replset was built up 3 years ago.
i search a lot for this, but didn't get any similar problem, any one can give any advise? thanks a lot!
lvzheng
Related
I am trying to solve a Replication issue here in MongoDB 4.2, but I can no longer get my Primary server back to primary, it always stays in SECONDARY mode. I've tried several types of solutions, like this Or here
But without success.
In the logs, I came across these messages:
Scheduling remote command request for vote request: RemoteCommand 729 -- target:mongo2:27021 db:admin cmd:{ replSetRequestVotes: 1, setName: "MyReplicaSet", dryRun: true, term: 2, candidateIndex: 0, configVersion: 125668, lastCommittedOp: { ts: Timestamp(1570799675, 1), t: 2 } }
2019-10-11T11:17:25.041-0300 I ELECTION [replexec-2] VoteRequester(term 2 dry run) received an invalid response from mongo2:27021: NotYetInitialized: no replset config has been received; response message: { operationTime: Timestamp(0, 0), ok: 0.0, errmsg: "no replset config has been received", code: 94, codeName: "NotYetInitialized", $clusterTime: { clusterTime: Timestamp(1570799675, 1), signature: { hash: BinData(0, 0000000000000000000000000000000000000000), keyId: 0 } } }
2019-10-11T11:17:25.041-0300 I ELECTION [replexec-2] not running for primary, we received insufficient votes
2019-10-11T11:17:25.041-0300 I ELECTION [replexec-2] Lost dry run election due to internal error
How to fix this?
It looks like this problem was fixed in mongodb 4.2.10: https://jira.mongodb.org/browse/SERVER-47263
mongodb:v3.4.9
error logs from mongodb c++ source code: https://github.com/mongodb/mongo/blob/367d31e1da549c460ae710a8cc280f4c235ab24f/src/mongo/s/client/shard_registry.cpp#L384
Mongos throw error when i add new node to a shard cluster and all the enableShardCollection can't query (ExceededTimeLimit).
It's can be repaired?
Marking host config.app.com as failed :: caused by :: ExceededTimeLimit: Operation timed out, request was RemoteCommand 871 -- target:config.app.com db:config expDate:2017-10-21T13:16:38.250+0000 cmd:{ find: "shards", readConcern: { level: "majority", afterOpTime: { ts: Timestamp 1508586527000|1, t: 24 } }, maxTimeMS: 30000 }
2017-10-21T13:16:38.250+0000 I SHARDING [shard registry reload] Operation timed out :: caused by :: ExceededTimeLimit: Operation timed out, request was RemoteCommand 871 -- target:config.app.com db:config expDate:2017-10-21T13:16:38.250+0000 cmd:{ find: "shards", readConcern: { level: "majority", afterOpTime: { ts: Timestamp 1508586527000|1, t: 24 } }, maxTimeMS: 30000 }
2017-10-21T13:16:38.250+0000 I SHARDING [shard registry reload] Periodic reload of shard registry failed :: caused by :: 50 could not get updated shard list from config server due to Operation timed out, request was RemoteCommand 871 -- target:config.app.com db:config expDate:2017-10-21T13:16:38.250+0000 cmd:{ find: "shards", readConcern: { level: "majority", afterOpTime: { ts: Timestamp 1508586527000|1, t: 24 } }, maxTimeMS: 30000 }; will retry after 30s
This happened to me and after hours of debugging I found that my config server was started without the configsvr: true option in rs.initiate. So mongos was requesting data from my config server but the config server didn't know how to respond. fwiw, I had
sharding:
clusterRole: configsvr
in my conf file but looks like that wasn't picked up.
we are trying to move from mongo 2.4.9 to 3.4, we have a lot of data so we tried to set replication and wait while data will be synced and then swap primary.
Configurations done but when replication is initiated new server cant stabilize replication:
017-07-07T12:07:22.492+0000 I REPL [replication-1] Starting initial sync (attempt 10 of 10)
2017-07-07T12:07:22.501+0000 I REPL [replication-1] sync source candidate: mongo-2.blabla.com:27017
2017-07-07T12:07:22.501+0000 I STORAGE [replication-1] dropAllDatabasesExceptLocal 1
2017-07-07T12:07:22.501+0000 I REPL [replication-1] ******
2017-07-07T12:07:22.501+0000 I REPL [replication-1] creating replication oplog of size: 6548MB...
2017-07-07T12:07:22.504+0000 I STORAGE [replication-1] WiredTigerRecordStoreThread local.oplog.rs already started
2017-07-07T12:07:22.505+0000 I STORAGE [replication-1] The size storer reports that the oplog contains 0 records totaling to 0 bytes
2017-07-07T12:07:22.505+0000 I STORAGE [replication-1] Scanning the oplog to determine where to place markers for truncation
2017-07-07T12:07:22.519+0000 I REPL [replication-1] ******
2017-07-07T12:07:22.521+0000 I REPL [replication-1] Initial sync attempt finishing up.
2017-07-07T12:07:22.521+0000 I REPL [replication-1] Initial Sync Attempt Statistics: { failedInitialSyncAttempts: 9, maxFailedInitialSyncAttempts: 10, initialSyncStart: new Date(1499429233163), initialSyncAttempts: [ { durationMillis: 0, status: "CommandNotFound: error while getting last oplog entry for begin timestamp: no such cmd: find", syncSource: "mongo-2.blabla.com:27017" }, { durationMillis: 0, status: "CommandNotFound: error while getting last oplog entry for begin timestamp: no such cmd: find", syncSource: "mongo-2.blabla.com:27017" }, { durationMillis: 0, status: "CommandNotFound: error while getting last oplog entry for begin timestamp: no such cmd: find", syncSource: "mongo-2.blabla.com:27017" }, { durationMillis: 0, status: "CommandNotFound: error while getting last oplog entry for begin timestamp: no such cmd: find", syncSource: "mongo-2.blabla.com:27017" }, { durationMillis: 0, status: "CommandNotFound: error while getting last oplog entry for begin timestamp: no such cmd: find", syncSource: "mongo-2.blabla.com:27017" }, { durationMillis: 0, status: "CommandNotFound: error while getting last oplog entry for begin timestamp: no such cmd: find", syncSource: "mongo-2.blabla.com:27017" }, { durationMillis: 0, status: "CommandNotFound: error while getting last oplog entry for begin timestamp: no such cmd: find", syncSource: "mongo-2.blabla.com:27017" }, { durationMillis: 0, status: "CommandNotFound: error while getting last oplog entry for begin timestamp: no such cmd: find", syncSource: "mongo-2.blabla.com:27017" }, { durationMillis: 0, status: "CommandNotFound: error while getting last oplog entry for begin timestamp: no such cmd: find", syncSource: "mongo-2.blabla.com:27017" } ] }
2017-07-07T12:07:22.521+0000 E REPL [replication-1] Initial sync attempt
failed -- attempts left: 0 cause: CommandNotFound: error while getting last
oplog entry for begin timestamp: no such cmd: find
2017-07-07T12:07:22.521+0000 F REPL [replication-1] The maximum number
of retries have been exhausted for initial sync.
2017-07-07T12:07:22.522+0000 E REPL [replication-0] Initial sync failed,
shutting down now. Restart the server to attempt a new initial sync.
2017-07-07T12:07:22.522+0000 I - [replication-0] Fatal assertion 40088 CommandNotFound: error while getting last oplog entry for begin timestamp: no such cmd: find at src/mongo/db/repl/replication_coordinator_impl.cpp 632
please assits guys, since we have more than 100G of data, so dump and restore will take a lot of downtime
Configurations:
3.4.5 new machine:
storage:
dbPath: /mnt/dbpath
journal:
enabled: true
engine: wiredTiger
systemLog:
destination: file
logAppend: true
path: /var/log/mongodb/mongod.log
net:
port: 27017
replication:
replSetName: prodTest
2.4.9 old machine with data:
dbpath=/var/lib/mongodb
logpath=/var/log/mongodb/mongodb.log
logappend=true port = 27017
the task have been solved in such way:
-create replica master-v2.4, 3 slaves-v2.6
-stop app, step down master
-stop new master and upgrade mongo version to v3.0,
start master and upgrade slaves sequentually to 3.2(slave db files
removed new version started on wiredTiger engine)
-step down master, upgrade all slaves to 3.4
This process become very fast because replica slave recovery of 40G db takes around 30m.
I was practicing some MapReduce inside of my Primary's mongo shell when it suddenly became a Secondary. I SSHed into the two other VM's with the other secondaries, and discovered that the mongod's had been rendered inoperaple. I killed them and I issued the mongod --config /etc/mongod.conf to kick them off and I entered the mongo shell. After a few seconds they were interrupted with:
2014-09-14T22:29:54.142-0500 DBClientCursor::init call() failed
2014-09-14T22:29:54.143-0500 trying reconnect to 127.0.0.1:27017 (127.0.0.1) failed
2014-09-14T22:29:54.143-0500 warning: Failed to connect to 127.0.0.1:27017, reason: errno:111 Connection refused
2014-09-14T22:29:54.143-0500 reconnect 127.0.0.1:27017 (127.0.0.1) failed failed couldn't connect to server 127.0.0.1:27017 (127.0.0.1), connection attempt failed
>
This is from their (the two original secondaries in the replicaset) logs:
2014-09-14T22:09:21.879-0500 [rsBackgroundSync] replSet syncing to: vm-billing-001:27017
2014-09-14T22:09:21.880-0500 [rsSync] replSet still syncing, not yet to minValid optime 54165090:1
2014-09-14T22:09:21.882-0500 [rsBackgroundSync] replset setting syncSourceFeedback to vm-billing-001:27017
2014-09-14T22:09:21.886-0500 [rsSync] replSet SECONDARY
2014-09-14T22:09:21.886-0500 [repl writer worker 1] build index on: test.tmp.mr.CCS.nonconforming_1_inc properties: { v: 1, key: { 0: 1 }, name: "_temp_0", ns: "test.tmp.mr.CCS.nonconforming_1_inc" }
2014-09-14T22:09:21.887-0500 [repl writer worker 1] added index to empty collection
2014-09-14T22:09:21.887-0500 [repl writer worker 1] build index on: test.tmp.mr.CCS.nonconforming_1 properties: { v: 1, key: { _id: 1 }, name: "_id_", ns: "test.tmp.mr.CCS.nonconforming_1" }
2014-09-14T22:09:21.887-0500 [repl writer worker 1] added index to empty collection
2014-09-14T22:09:21.888-0500 [repl writer worker 1] build index on: test.tmp.mr.CCS.nonconforming_1 properties: { v: 1, unique: true, key: { id: 1.0 }, name: "id_1", ns: "test.tmp.mr.CCS.nonconforming_1" }
2014-09-14T22:09:21.888-0500 [repl writer worker 1] added index to empty collection
2014-09-14T22:09:21.891-0500 [repl writer worker 2] ERROR: writer worker caught exception: :: caused by :: 11000 insertDocument :: caused by :: 11000 E11000 duplicate key error index: cisco.tmp.mr.CCS.nonconforming_1.$id_1 dup key: { : null } on: { ts: Timestamp 1410748561000|46, h: 9014687153249982311, v: 2, op: "i", ns: "cisco.tmp.mr.CCS.nonconforming_1", o: { _id: 14, value: 1.0 } }
2014-09-14T22:09:21.891-0500 [repl writer worker 2] Fatal Assertion 16360
2014-09-14T22:09:21.891-0500 [repl writer worker 2]
I can issue mongo --host ... --port ... from both of the two VMs that can't start the mongo to the original primary mongo, but I do see some connection refused notes above in the error log.
My original primary mongod can still be connected to in the mongo shell, but it is a primary. I can kill it and restart it and it will start up in secondary.
How can I roll back to the last known state and restart my replica set?
We have mongoDB master slave configuration. I updated spring mongoDB template driver to be replica aware with property com.mongodb.WriteConcern.REPLICAS_SAFE. I am getting following error in the log file.
[conn2788271] runQuery called xxx.$cmd { getlasterror: 1, w: "com.mongodb.WriteConcern.REPLICAS_SAFE", wtimeout: 0 }
[conn2786380] User Assertion: 14830:unrecognized getLastError mode: com.mongodb.WriteConcern.REPLICAS_SAFE
[conn2786380] command xxx.$cmd command: { getlasterror: 1, w: "com.mongodb.WriteConcern.REPLICAS_SAFE", wtimeout: 0 } ntoreturn:1 keyUpdates:0 reslen:182 0ms
Seems that error is coming from this file
https://bitbucket.org/wesc/debian-mongodb/src/97846fbc9d31/mongodb-2.0.2/db/repl_block.cpp
Any clues if I am missing something?
Make sure you're using the integer 1 and not the String "1".
Please check this: https://jira.mongodb.org/browse/JAVA-464