[SERVER-3456] Running fsync+lock on config server during backup results in blocked inserts Created: 21/Jul/11  Updated: 20/Jul/15  Resolved: 20/Jul/15

Status: Closed
Project: Core Server
Component/s: Concurrency, Sharding
Affects Version/s: 1.8.2
Fix Version/s: None

Type: Question Priority: Major - P3
Reporter: Jeff lee Assignee: Unassigned
Resolution: Won't Fix Votes: 1
Labels: revisit
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 10.10


Issue Links:
Related
related to SERVER-8579 Consolidate Mongod Lock/Resource Sche... Closed
is related to DOCS-545 Documentation on backing up a sharded... Closed
Participants:

 Description   

The documentation recommends doing an fsync+lock of a config server when taking a backup of a sharded cluster, but all of my tests using this method seem to result in blocked inserts after a few seconds ( I think when it needs to split the chunk ).

http://www.mongodb.org/display/DOCS/Backing+Up+Sharded+Cluster

Environment
Ubuntu 10.10
MongoDB 1.8.2
3 shards
3 replica set members per shard
3 config servers
1 mongos
chunksize=1 to force splits earlier

Steps to reproduce
1. Stop balancer
2. Verify balancer stopped
3. Run test script to generate inserts
4. fsync+lock config server
5. Wait a few seconds for block

I think I can work around the issue by shutting down the config database instead of doing an fsync and lock, but wanted to check to see whether or not this was a bug or just something missing in the documentation.

Thanks



 Comments   
Comment by Andy Schwerin [ 20/Jul/15 ]

This problem will go away with SERVER-1448, scheduled for 3.2. With that ticket resolved, the backup procedure will be to fsync+lock a config replica set secondary, I believe.

Comment by Greg Studer [ 02/May/14 ]

This is really a documentation issue - the fsync lock is behaving as-designed. We need to audit the backup docs and make sure we have a solution which doesn't cause further problems.

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