Nicolás Kovac Neumann wrote:

Hi,

We're currently using N-way multimaster replication on two servers for our LDAP directory, both for the config and the hdb databases. It's working fine mostly, but we've run into a possible issue with the syncrepl engine which we would like to cast light on. We're using CentOS 7 with openldap-servers version 2.4.39-6.

We made an update on one of the entries (server1, in this case), so server2 replicated that change (as shown below in the log):

The log snippet you included here doesn't show what you describe. It shows server 1 receiving a modification from server 2 via syncrepl; it does not show server 1 processing a modification from a client. It further shows server 1 sending the modification back to server 2 again (even though according to the SID, it originated on server 2). This usually indicates misconfigured SIDs.

  ==> server1/ldap.log <==
  Apr 21 13:38:55 server1 slapd[1835]: do_syncrep2: rid=002

cookie=rid=002,sid=002,csn=20150421123855.643239Z#000000#002#000000 Apr 21 13:38:55 server1 slapd[1835]: syncrepl_message_to_entry: rid=002 DN: uid=user1,cn=subtree,dc=example,dc=org, UUID: 18a2436c-73ce-1030-95dd-b52dc05ced13 Apr 21 13:38:55 server1 slapd[1835]: syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) Apr 21 13:38:55 server1 slapd[1835]: syncrepl_entry: rid=002 be_search (0) Apr 21 13:38:55 server1 slapd[1835]: syncrepl_entry: rid=002 uid=user1,cn=subtree,dc=example,dc=org Apr 21 13:38:55 server1 slapd[1835]: slap_queue_csn: queing 0x7ff8f42789f0 20150421123855.643239Z#000000#002#000000 Apr 21 13:38:55 server1 slapd[1835]: slap_graduate_commit_csn: removing 0x7ff8f435e770 20150421123855.643239Z#000000#002#000000 Apr 21 13:38:55 server1 slapd[1835]: syncrepl_entry: rid=002 be_modify uid=user1,cn=subtree,dc=example,dc=org (0) Apr 21 13:38:55 server1 slapd[1835]: syncprov_sendresp: cookie=rid=001,sid=001,csn=20150421123855.643239Z#000000#002#000000 Apr 21 13:38:55 server1 slapd[1835]: slap_queue_csn: queing 0x7ff8f42789f0 20150421123855.643239Z#000000#002#000000 Apr 21 13:38:55 server1 slapd[1835]: slap_graduate_commit_csn: removing 0x7ff8f41b7b90 20150421123855.643239Z#000000#002#000000

  ==> server2/ldap.log <==
  Apr 21 13:38:55 server2 slapd[1948]: slap_queue_csn: queing

0x7f897affb220 20150421123855.643239Z#000000#002#000000 Apr 21 13:38:55 server2 slapd[1948]: syncprov_sendresp: to=001, cookie=rid=002,sid=002,csn=20150421123855.643239Z#000000#002#000000 Apr 21 13:38:55 server2 slapd[1948]: slap_graduate_commit_csn: removing 0x7f89307f42a0 20150421123855.643239Z#000000#002#000000

Nothing strange up to now, however, if we query the contextCSN, it differs on both servers.

For server1, we have:

  contextCSN: 20150421123523.281736Z#000000#001#000000
  contextCSN: 20150421123417.889477Z#000000#002#000000

For server2, the value for server ID 001 differs:

  contextCSN: 20150421115324.003502Z#000000#001#000000
  contextCSN: 20150421123417.889477Z#000000#002#000000

However, the entry seems to replicate the entryCSN correctly on both servers:

  entryCSN: 20150421123417.889477Z#000000#002#000000

Is this the expected behavior? Shouldn't both contextCSN values match on both servers?

Thanks!

Regards,

Nicolás