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):
==> 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