[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: |
|
||||||||||||
| 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 |
| 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 on: { ts: Timestamp 1389125717000|1, h: 5050787995708330996, v: 2, op: "i", ns: "test.foo", o: { _id: ObjectId('52cc6055069cc31a1e651823'), asdf: 1243.0 }} ***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. |