[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
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 :
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):
| ||
| 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. |