[DOCS-10265] Back up documentation should specify a majority of CSRS nodes need to be fsyncLock'd Created: 16/May/17  Updated: 30/Oct/23

Status: Closed
Project: Documentation
Component/s: manual, Server
Affects Version/s: None
Fix Version/s: Server_Docs_20231030

Type: Bug Priority: Major - P3
Reporter: Esha Maharishi (Inactive) Assignee: Kay Kim (Inactive)
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Participants:
Days since reply: 1 year, 14 weeks, 2 days ago
Epic Link: DOCSP-1769

 Description   

The backup procedure described on this page: https://docs.mongodb.com/manual/tutorial/backup-sharded-cluster-with-database-dumps/#lock-config-server-replica-set-secondary should specify that a majority of CSRS secondary nodes should be fsyncLock'd for the duration of taking the backups.

The point of the fsyncLock is to prevent writes to the config server during the backup. Locking only one CSRS node will not prevent majority writes in a typical 3-node CSRS deployment.

(The documentation currently says that only one secondary needs to be fsyncLock'd; maybe this is a relic from SCCC config servers, where it was enough to fsyncLock one config node to prevent writes?)

This part:

Lock config server replica set secondary.

should be updated to say:

Prevent writes to the config servers by locking config server secondaries.

If the config servers are CSRS, the following steps should be applied on a majority of CSRS secondaries.

If the config servers are SCCC, the following steps need only be applied to a single SCCC node.



 Comments   
Comment by Education Bot [ 31/Oct/22 ]

Hello! This ticket has been closed due to inactivity. If you believe this ticket is still important, please reopen it and leave a comment to explain why. Thank you!

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