[SERVER-24156] Support for Delayed Secondaries in CSRS Created: 16/May/16 Updated: 20/May/16 Resolved: 20/May/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Ronan Bohan | Assignee: | Kaloian Manassiev |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Sprint: | Sharding 15 (06/03/16) | ||||
| Participants: | |||||
| Description |
|
MongoDB supports delayed secondaries for general purpose replica sets. In MongoDB 3.2 it is possible to deploy multiple config servers in a replica set configuration, however it is not possible to define a delayed secondary in this configuration. It would be useful to allow a delayed member in the config server replica set (slaveDelay) to facilitate a sharded cluster being rolled back in time and/or to avoid 'human error' when modifying the data in a config server. |
| Comments |
| Comment by Kaloian Manassiev [ 20/May/16 ] |
|
The config server only manages the locations of the chunks, but not the actual documents. Even it there are perfectly synchronized clocks between CSRS members and shard members, supporting delayed secondaries will likely do more harm than good with "oops recovery". The reason is that such operation is asynchronous and possibly lengthy and because currently there is no way to definitively confirm that the contents of a shard replica set member's secondary exactly match a given metadata state from the config server. Since relying on such a solution for human error recovery will tend to create possibility for partial data loss, I am going to close this ticket as "Won't fix" and replace it with a task for implementing a proper point-in-time recovery feature. |