[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: replicated cn=config
I think that instead of thinking of this as 'replicating' configuration
information to slaves, it might be better viewed as referring
(with local caching) slaves to some other server (possibly not
their master, possibly to some area of the DIT) for configuration
information.
Just a thought...
Kurt
At 01:31 PM 4/29/2005, Howard Chu wrote:
>Quanah posed this question about how to set up a bunch of replica servers that all use configurations replicated from the master as well. It wasn't perfectly obvious at first, so I'm posting this note to suggest an approach and get some reactions. I haven't tested this yet.
>
>First of all, you cannot just replicate cn=config straight from a master to a slave server, because the slave will wind up with an identical copy of the master's configuration (and will then cease to be a slave). This means you must use some alternate tree, and map it into the slave's cn=config.
>
>So here's a possible approach - on the master
>
> database ldif
> directory /some/path
> suffix cn=replica-config
>
>On each slave
> database relay
> suffix cn=replica-config
> relay cn=config massage
>
>Then either slurpd or syncrepl can be used to keep the slaves' configurations up to date.
>
>--
> -- Howard Chu
> Chief Architect, Symas Corp. Director, Highland Sun
> http://www.symas.com http://highlandsun.com/hyc
> Symas: Premier OpenSource Development and Support