Hi,

First, kudos to OpenLDAP team for the progress they have made with 2.4. I am returning to use OpenLDAP after nearly a decade and it is heartening to see all the new features even when going from 2.3 to 2.4 (As a side rant, it is painful to see Redhat/CentOS still ship 2.3.x. RedHat might do it to push their own DS over OpenLDAP but why CentOS)?

1. From the OpenLDAP guide, I see that replication is setup to replicate both – config and information trees.

a. With each master having a unique “ServerID”, does it mean that config replication won’t overwrite certain attributes like ServerID?

b. How are multiple “ServerID” values handled when the replication config is introduced?

c. What about credentials used for rootDN of various databases? Do they get sync-ed too?

2. What is the best way to setup a new master with empty databases? Slapcat from an existing one and Slapdadd to the new one? Or, let replication take care of it? Network traffic issues aside, my point is how does timestamp matching work for non-existant objects (in the new master vs existing). Or, put differently, how is deletion vs new/empty database differentiated? Why wouldn’t replication consider the non-existence of databases in the new master as all databases having been deleted?

3. From 18.2.2.3 of the Guide “Arguments against Multi-Master replication”.

4. " If connectivity with a provider is lost because of a network partition, then "automatic failover" can just compound the problem"

Care to expand on this, please?

5. " If a network is partitioned and multiple clients start writing to each of the "masters" then reconciliation will be a pain; it may be best to simply deny writes to the clients that are partitioned from the single provider"

How so? If all masters are sync-ed with NTP tighly, then shouldn't this issue take care of itself when a partitioned master(s) comes back online and reconnect.

Thanks,

- Siddhartha