Hello, I'm facing some issues with syncrepl...

Thanks for your answer, I'm using openldap 2.4.21 (the version packaged in Ubuntu Server LTS).

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.