[SERVER-29812] RangeDeleter unnecessarily waits for 'majority' write concern Created: 23/Jun/17  Updated: 30/Oct/23  Resolved: 28/Feb/18

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 3.2.14, 3.4.4
Fix Version/s: 3.4.14

Type: Bug Priority: Major - P3
Reporter: Kaloian Manassiev Assignee: Kevin Pulo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
related to SERVER-29807 RangeDeleter should log when its abou... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Sharding 2018-02-26, Sharding 2018-03-12
Participants:

 Description   

The range deleter waits for replication on two occasions:

  1. First using the moveChunk operation's write concern in Helpers::removeRange which does log the time spent for replication.
  2. Second time using a 'majority' write concern, which does not log at all.

This second majority wait is completely unnecessary. The migration recipient side can keep going without attempting a majority write until the very end, after all documents have been transferred.

As part of fixing this bug, we should consider the following:

  • Before even accepting a migration request, the recipient shard should do a best-effort attempt to check how behind it is from the rest of the replica set (perhaps by doing a majority write with some timeout then) and if that fails, don't even attempt a migration. This is the counterpart of SERVER-22876.
  • If the migration was for an empty chunk and we didn't patch up any indexes, do not do any replication waits at all and enter the READY state immediately.


 Comments   
Comment by Githook User [ 28/Feb/18 ]

Author:

{'email': 'kevin.pulo@mongodb.com', 'name': 'Kevin Pulo', 'username': 'devkev'}

Message: SERVER-29812 RangeDeleter no longer unnecessarily waits for 'majority' write concern
Branch: v3.4
https://github.com/mongodb/mongo/commit/ab8a14b2b3d034745f22133a964245b027b2d1e5

Comment by Kaloian Manassiev [ 21/Feb/18 ]

kevin.pulo, I agree with your comments. With the changes we are currently doing to optimize the speed of migrations, I don't think we need to look into the second part yet. I opened SERVER-33417 just to track this idea.

Comment by Kevin Pulo [ 21/Feb/18 ]

Before even accepting a migration request, the recipient shard should do a best-effort attempt to check how behind it is from the rest of the replica set (perhaps by doing a majority write with some timeout then) and if that fails, don't even attempt a migration.

This feels like SERVER-16805, and I think would be better off left for that ticket. Also because that would be a change in master, whereas the main changes here are only in 3.4.

If the migration was for an empty chunk and we didn't patch up any indexes, do not do any replication waits at all and enter the READY state immediately.

Since this would be a migration-related change, rather than range deleter related — and also possibly relevant to master, not just v3.4 — I think this would be better considered on its own SERVER ticket. Let me know if you'd still like me to look into this aspect on this ticket.

Comment by Kaloian Manassiev [ 15/Nov/17 ]

Yes, this is no longer a problem in 3.6, but I would like to have it fixed in 3.4 because it will improve the speed of migrations.

Comment by Dianna Hohensee (Inactive) [ 15/Nov/17 ]

This ticket relates to the old RangeDeleter, which has since been replaced by a new CollectionRangeDeleter. kaloian.manassiev, can we close this, or are you thinking of a v3.4 backport?

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