[SERVER-43846] Add way to track the number of failovers that would have caused orphaned documents Created: 04/Oct/19  Updated: 29/Oct/23  Resolved: 03/Mar/20

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: 4.3.5

Type: Task Priority: Major - P3
Reporter: Matthew Saltz (Inactive) Assignee: Randolph Tan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
is documented by DOCS-13511 Investigate changes in SERVER-43846: ... Closed
Backwards Compatibility: Fully Compatible
Sprint: Sharding 2020-03-09
Participants:

 Description   

In order to validate the efficacy/helpfulness of the resumable range deleter project, it would be good to have a way to track statistics on when the resumability aspect of the range deleter is helpful. One way to do this would be to track on step up whether or not there were outstanding range deleter tasks - since these are tasks that would have led to orphaned documents had there not been a resumable range deleter.



 Comments   
Comment by Githook User [ 03/Mar/20 ]

Author:

{'username': 'renctan', 'name': 'Randolph Tan', 'email': 'randolph@10gen.com'}

Message: SERVER-43846 Add information about how many migration task were leftover from last primary
Branch: master
https://github.com/mongodb/mongo/commit/a68774045ce42d55e82236408bd9cf004c54d12a

Comment by Garaudy Etienne [ 21/Feb/20 ]

renctan I agree with displaying 0 over blank. Understood for the rest!! 

Comment by Randolph Tan [ 21/Feb/20 ]

If there are no orphans, is the number 0 or blank?

garaudy.etienne, I'm thinking displaying zero over blank. Note that if the number is non-zero, it doesn't mean that there are orphans. It means that there were potentially orphans during the time this mongod transitioned to primary. Before the project, this would mean that the mongod could have orphans, after the project, if there were orphans, they will eventually (strong emphasis on "eventually") be cleaned up.

Comment by Garaudy Etienne [ 21/Feb/20 ]

renctan Looks good to me? If there are no orphans, is the number 0 or blank?

Comment by Randolph Tan [ 21/Feb/20 ]

Proposed format:

shardingStatistics: { // this is an existing field
  unfinishedMigrationfromPreviousPrimary: <number>
}

sheeri.cabral, garaudy.etienne Does the format look good to you? Any non-zero number would be an indication that it would have left orphans before the project.

matthew.saltz, I chose to use the number of migrationCoordinators documents instead since we are already iterating over them during transition to primary. This will make the accounting easier to reason about as well, as you won't need to think whether the range delete is destination or source and whether you are double counting the total across the entire cluster. What do you think?

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