[SERVER-4718] Replica Set re-sync fails if --notablescan is active Created: 19/Jan/12  Updated: 06/Dec/22  Resolved: 26/Feb/18

Status: Closed
Project: Core Server
Component/s: Index Maintenance, Replication
Affects Version/s: 1.8.4, 2.0.2
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Ansgar Hofmann Assignee: Backlog - Replication Team
Resolution: Done Votes: 0
Labels: PM248, fuzzer-blacklist, sync
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Not relevant


Issue Links:
Depends
depends on SERVER-8237 autoIndexId:false should be disabled Closed
Related
Assigned Teams:
Replication
Operating System: ALL
Participants:

 Description   

This only fails for collections with no _id index. Such collections are not created by default in version 2.4+.

Discussion here: https://groups.google.com/d/topic/mongodb-user/uC4bYdbmabM/discussion

In a replicaset it's not possible to set the notablescans flag on the master because the slaves are unable to read capped collections.

Here is the corresponding part of the log:

> Tue Jan 17 20:00:23 [rsSync] replSet initial sync cloning db: admin
> Tue Jan 17 20:00:24 [rsSync] replSet initial sync cloning db: config
> Tue Jan 17 20:00:24 [rsSync] replSet initial sync query minValid
> Tue Jan 17 20:00:32 [rsSync] replSet initial oplog application from a2.serv:27017 starting at Jan 17 07:03:38:6 to Jan 17 20:00:24:8
> Tue Jan 17 20:00:33 [rsSync] replSet initial sync failing, error applying oplog 10111 table scans not allowed:myDatabase.myCappedCollection
> Tue Jan 17 20:00:33 [rsSync] replSet initial sync failed during applyoplog



 Comments   
Comment by Gregory McKeon (Inactive) [ 26/Feb/18 ]

Due to significant changes to the system since this ticket was filed, it's unclear if this problem still exists. Please open a new ticket if you're still encountering this problem.

Comment by Matt Dannenberg [ 07/Jan/14 ]

Turns out I could repro this. I failed to realize that cappedCollections now default to having an _id index; the existence of which prevents the error. Here is the output from the crashed secondary as of 2.5.4:

2014-01-07T15:17:28.278-0500 [rsBackgroundSync] replSet syncing to: localhost:27017
2014-01-07T15:17:28.281-0500 [rsBackgroundSync] replSet remoteOldestOp: Jan 7 15:08:05 52cc5ea5:1
2014-01-07T15:17:28.281-0500 [rsBackgroundSync] replSet lastOpTimeFetched: Jan 7 15:15:09 52cc604d:1
2014-01-07T15:17:28.286-0500 [repl writer worker 1] ERROR: writer worker caught exception: :: caused by :: 17243 could not get runner

{ _id: ObjectId('52cc6055069cc31a1e651823') }

on:

{ ts: Timestamp 1389125717000|1, h: 5050787995708330996, v: 2, op: "i", ns: "test.foo", o: { _id: ObjectId('52cc6055069cc31a1e651823'), asdf: 1243.0 }

}
2014-01-07T15:17:28.286-0500 [repl writer worker 1] Fatal Assertion 16360
2014-01-07T15:17:28.286-0500 [repl writer worker 1]

***aborting after fassert() failure

It should also be noted that a secondary will crash when a collection like this is created. I do not know if that was the case in 1.8 and 2.0.

Comment by Matt Dannenberg [ 17/Oct/13 ]

Couldn't reproduce in 2.5.3

Comment by Ansgar Hofmann [ 23/Jan/12 ]

I made a mistake in the description: the flag notablescan on the secondary prevents it from resyncing. I don't know if the flag on the master is relevant.

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