[SERVER-25119] Do not re-create the _id_ index during cloning Created: 17/Jul/16  Updated: 15/Nov/21  Resolved: 19/Jul/16

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: 3.0.0, 3.2.3
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Zhang Youdong Assignee: Scott Hernandez (Inactive)
Resolution: Done Votes: 0
Labels: cloner, copydb, initialSync
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Sprint: Repl 18 (08/05/16)
Participants:

 Description   

In src/mongo/db/cloner.cpp:Cloner::copyDb

  • first time, copy data, create _id index to remove the dup _id items during initial sync.
  • second time, build index, remove all index, and then create

When sync source have _id index, the secondary can just keep the _id index created when copy data, no need to do it twice.



 Comments   
Comment by Zhang Youdong [ 20/Jul/16 ]

Thank you, Scott Hernandez, I tested again, and found I misunderstand the source code and runtime log last time, sorry for inconvenience.

Comment by Scott Hernandez (Inactive) [ 19/Jul/16 ]

It turns out this was not an issue. I noticed my mistake after we started testing and it was more clear what was happening.

This line :

indexer.removeExistingIndexes(&indexesToBuild);

This code doesn't remove the _id_ index from the collection, but instead remove it from the list of indexes which will be created – so it will not drop/create existing indexes.

It is even a bit more confusing since when the collection is created we don't create the _id index in this call (last arg is false meaning don't create the _id_ index):

Status status = userCreateNS(txn, db, ns, options, false);

Comment by Scott Hernandez (Inactive) [ 17/Jul/16 ]

Thanks for finding this performance issue. It does affect 3.2 and before, but since we re-wrote initial sync for 3.4 it is not longer an issue going forward. A back port will need to be worked on for pre-3.4 initial sync behavior.

Generated at Thu Feb 08 04:08:19 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.