Rein Tollevik rein@OpenLDAP.org writes:
Dieter Kluenter wrote:
"Carl Johnstone" carl.johnstone@gmgrd.co.uk writes:
Trying to get 2 slapd servers setup for multi-master replication - they will eventually be in different physical locations. Once I've got the 2 servers running OK, I'll be adding in a 3rd location. I've followed the admin guide, using cn=config and have attached a LDIF dump of the config (with schemas removed).
When I bring up the second server, with a minimal config. It correctly replicates across cn=config and sets up the main DB. It then correctly copies across all the data in the main DB to bring itself up-to-date with the server that's already setup. However from the point I bring it online it doesn't replicate any further changes to the first server. If I restart the second server the contextCSN is updated, however no other changes are replicated across.
Is there anything obviously wrong with my config? Or have I hit a known problem?
remove the URI part from serverID.
No! This is required when using a common config, which again is implied by a replicated cn=config. Each server in a multi-master configuration *must* have separate serverIDs, and using the URI version of the serverID is the only way multiple servers with the same config can achieve that.
The URI part of the serverID must match (one of the) listeners slapd uses (its -h arguments). Start the servers with "-d config" and verify that they report different and non-zero SID= values.
This will lead to a contextCSN with a serverID 000 reference and will disable any synchronization.
-Dieter
Dieter Kluenter wrote:
Rein Tollevik rein@OpenLDAP.org writes:
No! This is required when using a common config, which again is implied by a replicated cn=config. Each server in a multi-master configuration *must* have separate serverIDs, and using the URI version of the serverID is the only way multiple servers with the same config can achieve that.
The URI part of the serverID must match (one of the) listeners slapd uses (its -h arguments). Start the servers with "-d config" and verify that they report different and non-zero SID= values.
This will lead to a contextCSN with a serverID 000 reference and will disable any synchronization.
I've done some experimenting:
Yes the server was starting up with a SID of 0 which is why replication is failing. After some testing I've discovered that if I use a hostname rather than an IP address then the servers do get the correct SID at startup, and do replicate correctly. Is this a bug or a missing note in the docs?
Additionally in my first attempt, the 2nd server has started up from a minimal config, correctly replicated all the config, then the main DB from the 1st server. It then continued to replicate across all changes to server 1. However any changes on server2 weren't applied to server1 until I restarted server 1. Server 1 then caught up with the changes from server 2.
Since then every seems to be fine and everything is replicating in both directions. Can I presume this is an oddity that I'll encounter the first time I bring a new server online, or is something I should be more worried about? My next step is to add a 3rd server into the mix.
Carl
openldap-software@openldap.org
-
Carl Johnstone -
Dieter Kluenter