[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:
Related
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.

Generated at Thu Feb 08 04:05:32 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.