Re: overlay order important and not documented?

[Francis Swasey <Frank.Swasey@uvm.edu>]

On 3/17/07 5:52 AM, Howard Chu wrote:
> Francis Swasey wrote:
<snip>
> > I disagree!  Since the only modifications that arrive at the replicas 
> > (or shadows) came from the master.  I should be able to set up the 
> > overlays for unique and refint on the master and be done with it.  I 
> > should not have to waste the cpu cycles on each of the replicas to 
> > perform the same operations that were already figured out and done on 
> > the master ldap server.
> There are valid reasons to do it either way - for one thing, 
> instantiating the refint overlay on the replicas reduces network 
> traffic. Also if you have a hot standby setup you want the replicas to 
> be configured as nearly identically to the master as possible. (In 
> mirrormode the replica and the master should be identical, or mirror 
> image, anyway.)

Sadly, while there are valid reasons for doing it either way, the 
existing code forces me to run refint in the way I don't want to -- 
namely on every replica.

I do not have, nor do I want, a hot standby configuration.  If the 
master server goes down, no updates are possible until I get it fixed. 
(and since I'm running the master as a Guest under VMWare ESX 3 with HA 
configured -- hardware problems on the master are not a big concern to me).

So, how can the interaction between accesslog (required for syncrepl to 
work) and refint be resolved so the refint overlay can be configured 
after accesslog (so it gets executed before accesslog logs the 
transactions for syncrepl)?

Frank

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature