[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Different contextCSN on multi-master replication servers

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




--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/