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

{ ...,
members: [

{ host: 'abc', priority:0, slavedelay: 7200 }

,
...
]
}

On Tue, Aug 17, 2010 at 9:13 PM, Kenny Gorman <kgorman@shutterfly.com> wrote:
Guys,

I am curious as to your advice. We want the following configuration:

  • (2) hosts in replica set to fail over to each other
  • (1) host with --slavedelay and will never be failed to, but I want it to read the logs from whomever is master.

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
Kenny



 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
dac2ff3ce71ecbacedd2c4c3b623c32a7baee502
bc9997faef19bdcb145365ce34bdf7aeaa4b37d8

Generated at Thu Feb 08 02:57:36 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.