[DOCS-7179] Clarify the 'Lock config server replica set secondary' section Created: 16/Feb/16  Updated: 23/Mar/16  Resolved: 23/Mar/16

Status: Closed
Project: Documentation
Component/s: manual
Affects Version/s: mongodb-3.2
Fix Version/s: mongodb-3.2

Type: Task Priority: Major - P3
Reporter: Kaloian Manassiev Assignee: Unassigned
Resolution: Done Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
Related
Participants:
Days since reply: 7 years, 47 weeks ago

 Description   

The documentation page for backing up a sharded cluster contains a section on how to lock config server replicaset's secondary in order to get a consistent metadata snapshot.

The section requests to search for a 'moveChunk.commit' message, which will work most of the time, but in the case of failed migrations it might not.

A more appropriate instructions would be to run the same query:

use config;
db.changelog.find({what:/^moveChunk/}).sort({time:-1}).next()

And make sure that the last moveChunk.start entry has a corresponding moveChunk.commit or moveChunk.from entry, which would indicate that the latest migration has completed (whether successfully or not).



 Comments   
Comment by Kaloian Manassiev [ 23/Mar/16 ]

The CSRS cluster backup documentation has been updated as part of a different ticket and now includes instructions, which do not rely on the moveChunk messages showing the in the changelog. I am closing this ticket, since it is no longer relevant.

Comment by Kevin Pulo [ 28/Feb/16 ]

Surely this can be checked in a purely programmatic fashion? This level of manual interpretation seems pretty error-prone...

There is also a subtle point which is that the moveChunk.to can actually enter the changelog after the moveChunk.commit and moveChunk.from (eg. if the to-side mongod is under heavy load, and gets delayed while sending the moveChunk.to entry). This doesn't change the overall goal of "find the last moveChunk.start, and check that it has a corresponding moveChunk.from and/or moveChunk.commit", but it does mean that a little extra care might be needed.

I think something like this would work:

var laststart = db.changelog.find({what:"moveChunk.start"}).sort({time:-1}).next()
db.changelog.find({what:/^moveChunk\.(from|commit)/, time: { $gte: laststart.time }, ns: laststart.ns, server: laststart.server, "details.min": laststart.details.min, "details.max": laststart.details.max, "details.from": laststart.details.from , "details.to": laststart.details.to}).sort({time:-1}).limit(1).pretty()

If there is any output, then the most recent chunk migration has completed. If there is no output, then the most recently started migration may still be in progress (but might not, eg. if the from mongod aborted mid-way through the migration).

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