[SERVER-1638] --slavedelay needs to work with replica sets Created: 18/Aug/10 Updated: 12/Jul/16 Resolved: 24/Aug/10 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | 1.6.0 |
| Fix Version/s: | 1.6.3, 1.7.0 |
| Type: | Improvement | Priority: | Minor - P4 |
| Reporter: | Kenny Gorman | Assignee: | Dwight Merriman |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Participants: |
| Description |
|
On Aug 17, 2010, at 6:23 PM, Dwight Merriman wrote: what i am planning is use of slavedelay in set configs but the member must be passive e.g. { ..., , On Tue, Aug 17, 2010 at 9:13 PM, Kenny Gorman <kgorman@shutterfly.com> wrote: I am curious as to your advice. We want the following configuration:
What are my options here? It appears I can setup a slave against the (NOW) master, but if it fails over it doesn't understand the new master. It's 'set unaware'. An approach would be to create a new settings option for slavedelay and allow this to be passive or perhaps mandate it's passive (could be confusing to fail over to really old data if someone wasn't on top of it). Thanks |
| Comments |
| Comment by Kenny Gorman [ 15/Sep/10 ] |
|
Yes, initial sync is fine (and expected) to be up to date. Thanks! |
| Comment by Dwight Merriman [ 24/Aug/10 ] |
|
great. one note: on initial sync it may be more current than the slavedelay...i think that is ok though. (would be a giant code complexity increase to honor that and not worth it IMO) |
| Comment by Kenny Gorman [ 24/Aug/10 ] |
|
Confirmed it's working |
| Comment by Dwight Merriman [ 18/Aug/10 ] |
|
dde78c8e6621d062b2218c269cfef9a0e2d97233 |