Re: Error: CSN too old and replication fails

[Howard Chu <hyc@symas.com>]

Jérémy Wagner wrote:
> Hello,
>
> I'm facing some issues with syncrepl...
>
> The simplest situation in which I was able to reproduce the problem
> consists of 1 provider and 1 consumer.
>
> I have configured syncrepl to do a partial replication :
>
> olcSyncrepl:
>       {0}rid=105
>       provider=ldaps://****:636
>       bindmethod=simple
>       timeout=0
>       network-timeout=0
>       starttls=no
>       filter="(mail=*)"
>       searchbase="ou=groups,o=mydir"
>       scope=sub
>       schemachecking=off
>       attrs="cn description mail member +"
>       type=refreshAndPersist
>       retry="60 +"
>       tls_cert=**** tls_cacert=**** tls_key=****
>
> olcSyncrepl:
>       {1}rid=107
>       provider=ldaps://****:636
>       bindmethod=simple
>       timeout=0
>       network-timeout=0
>       starttls=no
>       filter="(objectclass=*)"
>       searchbase="ou=operators,o=mydir"
>       scope=sub
>       schemachecking=off
>       type=refreshAndPersist
>       retry="60 +"
>       tls_cert=**** tls_cacert=**** tls_key=****
>
> olcSyncrepl:
>       {2}rid=104
>       provider=ldaps://****:636
>       bindmethod=simple
>       timeout=0
>       network-timeout=0
>       starttls=no
>       filter="(uid=mytestuser)"
>       searchbase="ou=people,o=mydir"
>       scope=sub
>       schemachecking=off
>       type=refreshAndPersist
>       retry="60 +"
>       tls_cert=**** tls_cacert=**** tls_key=****
>
> The initial sync (i.e. from an empty base) is fine, but then when I
> modify an entry (uid=mytestuser), it is not updated on the consumer, and
> I get the
> following messages:
>
> Feb 16 15:42:32 do_syncrep2: rid=107 NEW_COOKIE:
> rid=107,csn=20110216144232.222152Z#000000#000#000000
> Feb 16 15:42:32 do_syncrep2: rid=104
> cookie=rid=104,csn=20110216144232.222152Z#000000#000#000000
> Feb 16 15:42:32 slap_graduate_commit_csn: removing 0x7fb58c0227d0
> 20110216144232.222152Z#000000#000#000000
> Feb 16 15:42:32 do_syncrep2: rid=104 CSN too old, ignoring
> 20110216144232.222152Z#000000#000#000000
> Feb 16 15:43:05 do_syncrep2: rid=105 LDAP_RES_INTERMEDIATE - NEW_COOKIE
> Feb 16 15:43:05 do_syncrep2: rid=105 NEW_COOKIE:
> rid=105,csn=20110216144305.545784Z#000000#000#000000
> Feb 16 15:43:05 slap_queue_csn: queing 0x7fb58c020b50
> 20110216144305.545784Z#000000#000#000000
> Feb 16 15:43:05 do_syncrep2: rid=107 LDAP_RES_INTERMEDIATE - NEW_COOKIE
> Feb 16 15:43:05 do_syncrep2: rid=107 NEW_COOKIE:
> rid=107,csn=20110216144305.545784Z#000000#000#000000
> Feb 16 15:43:05 do_syncrep2: rid=104
> cookie=rid=104,csn=20110216144305.545784Z#000000#000#000000
> Feb 16 15:43:05 slap_graduate_commit_csn: removing 0x7fb58c0227d0
> 20110216144305.545784Z#000000#000#000000
> Feb 16 15:43:05 do_syncrep2: rid=104 CSN too old, ignoring
> 20110216144305.545784Z#000000#000#000000
>
> (both servers are perfectly in sync with an NTP daemon)
>
> It looks like ITS #6619 is quite similar, and unresolved.
>
> What do these messages mean ? Is there a way to force the update ?

Your current configuration is unsupported. Ordinarily when you configure 
multiple consumers in a DB it is assumed they are all pointing at different 
providers, and each provider will have a different serverID. In your case, 
since it is all a single provider with a single serverID, all 3 consumers will 
share a single contextCSN. Any update in any branch will update the contextCSN 
to that newest state. Any updates in other branches that hadn't been received 
yet (due to random timing between threads) will be received as "too old" 
because the contextCSN already has a newer state.

A workaround for this would be to split each consumer into its own subordinate 
database, then each will have a private copy of its own contextCSN to work with.
--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/