Hi there again,
I'm running OpenLDAP 2.4.11. I followed the 18.3.3. N-Way Multi-Master on the http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master documentation. I setup only two servers. When I run the new configuration on the first change in one server is replicated to the other server. After that all changes that I made are not replicated. What can be causing this problem?
Here is the configuration that I used for cn=config:
dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: syncprov
dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 ldap://192.168.139.10 olcServerID: 2 ldap://192.168.139.11
dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov
dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=ldap://192.168.139.10 binddn="cn=admin,cn=config" bindmethod=simple credentials="ii" searchbase="cn=config" type=refreshAndPersist retry="5 10 10 +" timeout=1 olcSyncRepl: rid=002 provider=ldap://192.168.139.11 binddn="cn=admin,cn=config" bindmethod=simple credentials="ii" searchbase="cn=config" type=refreshAndPersist retry="5 10 10 +" timeout=1 - add: olcMirrorMode olcMirrorMode: TRUE
And the configuration for bdb database
dn: olcDatabase={1}bdb,cn=config changetype: modify add: olcRootDN olcRootDN: cn=admin,dc=arquis,dc=local - add: olcSyncRepl olcSyncRepl: rid=003 provider=ldap://192.168.139.10 binddn="cn=admin,dc=arquis,dc=local" bindmethod=simple credentials="ii" searchbase="dc=arquis,dc=local" type=refreshOnly interval=00:00:00:10 retry="5 10 10 +" timeout=1 olcSyncRepl: rid=004 provider=ldap://192.168.139.11 binddn="cn=admin,dc=arquis,dc=local" bindmethod=simple credentials="ii" searchbase="dc=arquis,dc=local" type=refreshOnly interval=00:00:00:10 retry="5 10 10 +" timeout=1 - add: olcMirrorMode olcMirrorMode: TRUE
dn: olcOverlay=syncprov,olcDatabase={1}bdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov
Here is some output debug:
root@ubuntu:~# /usr/sbin/slapd -d 16384 @(#) $OpenLDAP: slapd 2.4.11 (Nov 8 2008 09:42:18) $ buildd@palmer:/build/buildd/openldap-2.4.11/debian/build/servers/slapd slapd starting do_syncrep2: rid=004 LDAP_RES_SEARCH_RESULT do_syncrep2: rid=002 LDAP_RES_INTERMEDIATE - REFRESH_DELETE do_syncrep2: rid=003 LDAP_RES_SEARCH_RESULT do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - REFRESH_DELETE
That's equal to the output of the 2nd server:
root@ubuntu:~# /usr/sbin/slapd -d 16384 @(#) $OpenLDAP: slapd 2.4.11 (Nov 8 2008 09:42:18) $ buildd@palmer:/build/buildd/openldap-2.4.11/debian/build/servers/slapd slapd starting do_syncrep2: rid=003 LDAP_RES_SEARCH_RESULT do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - REFRESH_DELETE do_syncrep2: rid=004 LDAP_RES_SEARCH_RESULT do_syncrep2: rid=002 LDAP_RES_INTERMEDIATE - REFRESH_DELETE do_syncrep2: rid=004 LDAP_RES_SEARCH_RESULT do_syncrep2: rid=003 LDAP_RES_SEARCH_RESULT
Thanks in advances
Calos Lopez wrote:
I'm running OpenLDAP 2.4.11. I followed the 18.3.3. N-Way Multi-Master on the http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master documentation. I setup only two servers. When I run the new configuration on the first change in one server is replicated to the other server. After that all changes that I made are not replicated. What can be causing this problem?
Especially for such a configuration you should run a recent release of OpenLDAP (2.4.16 at the moment). There have been numerous fixes to syncrepl since 2.4.11.
Ciao, Michael.
Just upgraded to version 2.4.15 and the issue is exactly the same: only the first change is replicated to the other server. I don't think upgrading to version 2.4.16 will resolve this. Any clues? Just one more thing in the tutorial is said the the the setup of syncrepl is only necessary for the first server because all the config that will be replicated "*(...)We still have to replicate the actual data, not just the config, so add to the master (all active and configured consumers/masters will pull down this config, as they are all syncing)(..)*". Actually that didn't happen, I had to replicate to all servers the backend database syncrpl configuration. May this is a clue....
Thanks
2009/6/22 Michael Ströder michael@stroeder.com
Calos Lopez wrote:
I'm running OpenLDAP 2.4.11. I followed the 18.3.3. N-Way Multi-Master on the
http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master
documentation. I setup only two servers. When I run the new configuration on the first change in one server is replicated to the other server. After that all changes that I made are not replicated. What can be causing this problem?
Especially for such a configuration you should run a recent release of OpenLDAP (2.4.16 at the moment). There have been numerous fixes to syncrepl since 2.4.11.
Ciao, Michael.
Calos Lopez wrote:
2009/6/22 Michael Ströder <michael@stroeder.com mailto:michael@stroeder.com>
Calos Lopez wrote: > > I'm running OpenLDAP 2.4.11. > I followed the 18.3.3. N-Way Multi-Master on the > http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master > documentation. > I setup only two servers. When I run the new configuration on the > first change in one server is replicated to the other server. After > that all changes that I made are not replicated. What can be causing > this problem? Especially for such a configuration you should run a recent release of OpenLDAP (2.4.16 at the moment). There have been numerous fixes to syncrepl since 2.4.11.Just upgraded to version 2.4.15 and the issue is exactly the same: only the first change is replicated to the other server. I don't think upgrading to version 2.4.16 will resolve this.
Why don't you take my advice serious? If you continue to ignore specific hints nobody will bother to answer your questions in the future.
It's my strong belief that when using Open Source software one should take care of economical aspects of the developer's and other volunteers' spare time. So in general it's bad practice to report bugs of older release again when these might have already been fixed in a newer release. It's the user's obligation to prove that a bug still persists in a recent release (or even preferrably in a recent CVS checkout).
Before making any assumptions one should look into file CHANGES of a recent source release. For your particular issue have a look at these lines:
OpenLDAP 2.4.16 Release (2009/04/05) [..] Fixed slapd syncrepl newCookie sync messages (ITS#5972) Fixed slapd syncrepl hang during shutdown (ITS#6011) Fixed slapd syncrepl too many MMR messages (ITS#6020) Fixed slapd syncrepl skipped entries with MMR (ITS#5988)
Ciao, Michael.
On 22/06/2009 23:28, Calos Lopez wrote:
Just upgraded to version 2.4.15 and the issue is exactly the same: only the first change is replicated to the other server. I don't think upgrading to version 2.4.16 will resolve this.
It may not resolve this issue, but since several replication related fixes were introduced, you'd probably be better off using it anyway, to avoid future issues, once you get your config working.
Any clues? Just one more thing in the tutorial is said the the the setup of syncrepl is only necessary for the first server because all the config that will be replicated "/(...)We still have to replicate the actual data, not just the config, so add to the master (all active and configured consumers/masters will pull down this config, as they are all syncing)(..)/". Actually that didn't happen, I had to replicate to all servers the backend database syncrpl configuration. May this is a clue....
You may be running into the issue described in a note just below that quote:
Note: As stated in slapd-config(5), URLs specified in olcSyncRepl directives are the URLs of the servers from which to replicate. These must exactly match the URLs slapd listens on (-h in Command-Line Options). Otherwise slapd may attempt to replicate from itself, causing a loop.
In your original message, you state that you launch slapd using: root@ubuntu:~# /usr/sbin/slapd -d 16384
I suggest adding "-h ldap://192.168.139.10" (and .11 respectively) to that. This way, slapd can know which server is 'self', and which are others.
Jonathan
openldap-software@openldap.org
-
Calos Lopez -
Jonathan Clarke -
Michael Ströder