[DOCS-1030] Need to complete the thought re. failed secondaries Created: 22/Jan/13 Updated: 28/Jan/13 Resolved: 23/Jan/13 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Kelly Stirman | Assignee: | Sam Kleinman (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Participants: | |
| Days since reply: | 11 years, 4 weeks, 1 day ago |
| Description |
|
http://docs.mongodb.org/manual/administration/sharding-architectures/#sharding-high-availability Here's the sentence in question: "If the unavailable mongod is a secondary, and it connects within its recovery window." My understanding is as follows: Within a given shard, if the unavailable mongod is a secondary then reads/writes directed to that shard’s primary will continue without interruption. When that secondary’s operations resume, it must reconnect within it’s recovery window in order to catch up on any writes it may have missed. The recovery window is determined by the size of the oplog. Many users configure an oplog sufficient to maintain a recovery window of multiple days. Also, there's mention of "recovery window" that links to oplog sizing. It isn't obvious that the two are related, and the term "recovery window" doesn't appear on the oplog sizing page. |
| Comments |
| Comment by auto [ 23/Jan/13 ] |
|
Author: {u'date': u'2013-01-23T00:14:06Z', u'email': u'samk@10gen.com', u'name': u'Sam Kleinman'}Message: |