[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: |
|
||||||||||||
| 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 Steps to reproduce 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 |
| 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. |