MMR - Add and delete entry on on server, CSN too old on the other and the entry is not deleted
Hello,
I'm with openldap-2.4.39. I've 2 openldap server on MMR, the config is down to the mail.
On the 1st server, il made - ADD an entry - Little after (1h) DELETE the same entry
On the second server, I have : - The entry is created by replication - BUT the entry is not delete by the replication with a CSN too old error.
How can i resolv this ?
Thanks by advance
Extract of the logs is : On 1st server (where entry is add and delete) : 2014-09-16T01:59:09.161478+02:00 ldapp01 slapd[19641]: conn=6131651 op=5367 ADD dn="cn=1952991,ou=groupe..." 2014-09-16T02:57:46.499274+02:00 ldapp01 slapd[19641]: conn=6153444 op=24 DEL dn="cn=1952991,ou=groupe_..." ... 2014-09-16T04:44:01.713257+02:00 ldapp01 slapd[19641]: syncprov_search_response: cookie=rid=000,sid=001,csn=20140916024243.636498Z#000000#001#000000;20140830211826.755872Z#000000#002#000000;20131010140905.564563Z#000000#065#000000;20130913220003.060576Z#000000#12b#000000;20131206221310.808393Z#000000#12d#000000 2014-09-16T04:44:01.713299+02:00 ldapp01 slapd[19641]: syncprov_sendresp: cookie=rid=000,sid=001,csn=20140916024342.267736Z#000000#001#000000 2014-09-16T04:44:01.906746+02:00 ldapp01 slapd[19641]: conn=6183327 op=1 UNBIND
On the Second server (where entry persist without delete) : 2014-09-16T04:29:28.462968+02:00 ldapp02 slapd[12536]: syncrepl_message_to_op: rid=102 be_add cn=1952991,ou=groupe... (0) 2014-09-16T04:29:28.462968+02:00 ldapp02 slapd[12536]: syncrepl_message_to_op: rid=102 be_add cn=1952991,ou=groupe... (0) 2014-09-16T04:29:28.462978+02:00 ldapp02 slapd[12536]: slap_queue_csn: queing 0x7f0f505698d0 20140915235909.161585Z#000000#001#000000 2014-09-16T04:29:28.463051+02:00 ldapp02 slapd[12536]: slap_graduate_commit_csn: removing 0x7f0f50568740 20140915235909.161585Z#000000#001#000000 2014-09-16T04:29:28.463076+02:00 ldapp02 slapd[12536]: do_syncrep2: rid=102 cookie=rid=000,sid=001,csn=20140915235909.166279Z#000000#001#000000 2014-09-16T04:29:28.463113+02:00 ldapp02 slapd[12536]: slap_queue_csn: queing 0x7f0f5056e6ee 20140915235909.166279Z#000000#001#000000 2014-09-16T04:29:28.464678+02:00 ldapp02 slapd[12536]: slap_queue_csn: queing 0x7f0f5055f710 20140915235909.166279Z#000000#001#000000 2014-09-16T04:29:28.464860+02:00 ldapp02 slapd[12536]: syncprov_matchops: skipping original sid 001 2014-09-16T04:29:28.464870+02:00 ldapp02 slapd[12536]: slap_graduate_commit_csn: removing 0x7f0f50556380 20140915235909.166279Z#000000#001#000000 2014-09-16T04:29:28.464880+02:00 ldapp02 slapd[12536]: slap_graduate_commit_csn: removing 0x7f0f50563df0 20140915235909.166279Z#000000#001#000000 ... 2014-09-16T04:44:01.653713+02:00 ldapp02 slapd[12536]: do_syncrep2: rid=102 cookie=rid=000,sid=001,csn=20140915235909.166279Z#000000#001#000000 2014-09-16T04:44:01.653740+02:00 ldapp02 slapd[12536]: do_syncrep2: rid=102 CSN too old, ignoring 20140915235909.166279Z#000000#001#000000 (reqStart=20140915235909.000007Z,cn=de lta-sync) .. 2014-09-16T04:44:01.653619+02:00 ldapp02 slapd[12536]: do_syncrep2: rid=102 cookie=rid=000,sid=001,csn=20140915235909.161585Z#000000#001#000000 2014-09-16T04:44:01.653646+02:00 ldapp02 slapd[12536]: do_syncrep2: rid=102 CSN too old, ignoring 20140915235909.161585Z#000000#001#000000 (reqStart=20140915235909.000005Z,cn=de lta-sync)
Configuration is : On the 1st server : . ServerID 001 . maxderefdepth 15 readonly FALSE sync_use_subentry FALSE . dbnosync TRUE # ecriture tous les 15 minutes checkpoint 0 15 . syncrepl rid=201 provider=ldap://ldapp02:389 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=ent,dc=fr" attrs="*,+" bindmethod=simple binddn="cn=admin,ou=system,dc=ent,dc=fr" credentials=XXXXXXX logbase="cn=delta-sync" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog mirrormode on
# Overlay configuration should be added after the database configuration # Définition de l'overlay lié à la réplication maitre overlay syncprov
syncprov-checkpoint 100 10
On the second server : ServerID 002 . maxderefdepth 15 readonly FALSE sync_use_subentry FALSE . dbnosync TRUE # ecriture tous les 15 minutes checkpoint 0 15 . syncrepl rid=102 provider=ldap://ldapp01:389 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=ent,dc=fr" attrs="*,+" bindmethod=simple binddn="cn=admin,ou=system,dc=ent,dc=fr" credentials=XXXXXXX logbase="cn=delta-sync" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog mirrormode on
# Overlay configuration should be added after the database configuration # Définition de l'overlay lié à la réplication maitre overlay syncprov
syncprov-checkpoint 100 10
Antonin Meunier
Re,
The same problem of non delete on the synchronised ldap occurs too for an old entry (create 6 month before). The delete on the 1st server is not replicated to the second server.
On the logs file, we see a delay of 2h30 between the creation on the first and the creation on the second server. It's the same for the delete (delay is more than 2h30) between the delete on the Fisrt server and the error of csn too old...
This delay can cause the problem?
How to resolv it on my configuration?
Thanks by advance
-----Message d'origine----- De : Meunier, Antonin Envoyé : lundi 29 septembre 2014 12:00 À : openldap-technical@openldap.org Cc : Meunier, Antonin Objet : MMR - Add and delete entry on on server, CSN too old on the other and the entry is not deleted
Hello,
I'm with openldap-2.4.39. I've 2 openldap server on MMR, the config is down to the mail.
On the 1st server, il made - ADD an entry - Little after (1h) DELETE the same entry
On the second server, I have : - The entry is created by replication - BUT the entry is not delete by the replication with a CSN too old error.
How can i resolv this ?
Thanks by advance
Extract of the logs is : On 1st server (where entry is add and delete) : 2014-09-16T01:59:09.161478+02:00 ldapp01 slapd[19641]: conn=6131651 op=5367 ADD dn="cn=1952991,ou=groupe..." 2014-09-16T02:57:46.499274+02:00 ldapp01 slapd[19641]: conn=6153444 op=24 DEL dn="cn=1952991,ou=groupe_..." ... 2014-09-16T04:44:01.713257+02:00 ldapp01 slapd[19641]: syncprov_search_response: cookie=rid=000,sid=001,csn=20140916024243.636498Z#000000#001#000000;20140830211826.755872Z#000000#002#000000;20131010140905.564563Z#000000#065#000000;20130913220003.060576Z#000000#12b#000000;20131206221310.808393Z#000000#12d#000000 2014-09-16T04:44:01.713299+02:00 ldapp01 slapd[19641]: syncprov_sendresp: cookie=rid=000,sid=001,csn=20140916024342.267736Z#000000#001#000000 2014-09-16T04:44:01.906746+02:00 ldapp01 slapd[19641]: conn=6183327 op=1 UNBIND
On the Second server (where entry persist without delete) : 2014-09-16T04:29:28.462968+02:00 ldapp02 slapd[12536]: syncrepl_message_to_op: rid=102 be_add cn=1952991,ou=groupe... (0) 2014-09-16T04:29:28.462968+02:00 ldapp02 slapd[12536]: syncrepl_message_to_op: rid=102 be_add cn=1952991,ou=groupe... (0) 2014-09-16T04:29:28.462978+02:00 ldapp02 slapd[12536]: slap_queue_csn: queing 0x7f0f505698d0 20140915235909.161585Z#000000#001#000000 2014-09-16T04:29:28.463051+02:00 ldapp02 slapd[12536]: slap_graduate_commit_csn: removing 0x7f0f50568740 20140915235909.161585Z#000000#001#000000 2014-09-16T04:29:28.463076+02:00 ldapp02 slapd[12536]: do_syncrep2: rid=102 cookie=rid=000,sid=001,csn=20140915235909.166279Z#000000#001#000000 2014-09-16T04:29:28.463113+02:00 ldapp02 slapd[12536]: slap_queue_csn: queing 0x7f0f5056e6ee 20140915235909.166279Z#000000#001#000000 2014-09-16T04:29:28.464678+02:00 ldapp02 slapd[12536]: slap_queue_csn: queing 0x7f0f5055f710 20140915235909.166279Z#000000#001#000000 2014-09-16T04:29:28.464860+02:00 ldapp02 slapd[12536]: syncprov_matchops: skipping original sid 001 2014-09-16T04:29:28.464870+02:00 ldapp02 slapd[12536]: slap_graduate_commit_csn: removing 0x7f0f50556380 20140915235909.166279Z#000000#001#000000 2014-09-16T04:29:28.464880+02:00 ldapp02 slapd[12536]: slap_graduate_commit_csn: removing 0x7f0f50563df0 20140915235909.166279Z#000000#001#000000 ... 2014-09-16T04:44:01.653713+02:00 ldapp02 slapd[12536]: do_syncrep2: rid=102 cookie=rid=000,sid=001,csn=20140915235909.166279Z#000000#001#000000 2014-09-16T04:44:01.653740+02:00 ldapp02 slapd[12536]: do_syncrep2: rid=102 CSN too old, ignoring 20140915235909.166279Z#000000#001#000000 (reqStart=20140915235909.000007Z,cn=de lta-sync) .. 2014-09-16T04:44:01.653619+02:00 ldapp02 slapd[12536]: do_syncrep2: rid=102 cookie=rid=000,sid=001,csn=20140915235909.161585Z#000000#001#000000 2014-09-16T04:44:01.653646+02:00 ldapp02 slapd[12536]: do_syncrep2: rid=102 CSN too old, ignoring 20140915235909.161585Z#000000#001#000000 (reqStart=20140915235909.000005Z,cn=de lta-sync)
Configuration is : On the 1st server : . ServerID 001 . maxderefdepth 15 readonly FALSE sync_use_subentry FALSE . dbnosync TRUE # ecriture tous les 15 minutes checkpoint 0 15 . syncrepl rid=201 provider=ldap://ldapp02:389 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=ent,dc=fr" attrs="*,+" bindmethod=simple binddn="cn=admin,ou=system,dc=ent,dc=fr" credentials=XXXXXXX logbase="cn=delta-sync" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog mirrormode on
# Overlay configuration should be added after the database configuration # Définition de l'overlay lié à la réplication maitre overlay syncprov
syncprov-checkpoint 100 10
On the second server : ServerID 002 . maxderefdepth 15 readonly FALSE sync_use_subentry FALSE . dbnosync TRUE # ecriture tous les 15 minutes checkpoint 0 15 . syncrepl rid=102 provider=ldap://ldapp01:389 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=ent,dc=fr" attrs="*,+" bindmethod=simple binddn="cn=admin,ou=system,dc=ent,dc=fr" credentials=XXXXXXX logbase="cn=delta-sync" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog mirrormode on
# Overlay configuration should be added after the database configuration # Définition de l'overlay lié à la réplication maitre overlay syncprov
syncprov-checkpoint 100 10
Antonin Meunier
Hello,
I'm with openldap-2.4.39 on MMR mode with 2 master openldap server. After a crash of the ldap n°1 (segfault), i delete the data on the ldap N°1 (slapd and delta-sync), the ldap N°2 still running. I started the ldap n°1. It made a full sync to have the data of the ldap n°2. But during this full sync, if an entry is modified on the ldap n°2, this entry is not replicated on the server n°1 (error "greater than snapshot"). Even if i edit manually the entry on the ldap n°2, this entry is never created on the ldap n°2. How can i force these entrys to be replicated? How can i resync an ldap server (without interruption) (export ldif and import?, full sync)?
Extracts of the log : Server n°1 (empty at the started and without entry modified on the n°2 at the end of the full sync) : 2014-09-25T14:52:14.220548+02:00 ldap02 slapd[7362]: Entry uid=3313791009,ou=personnes,ou=... CSN 20140925125108.641340Z#000000#0c9#000000 greater than snapshot 20140925123716.109791Z#000000#0c9#000000
Server n°2 (where the modification of the entry is made) : 2014-09-25T14:51:05.321697+02:00 ldap02 slapd[7362]: conn=642704 op=8 MOD dn="uid=3313791009,ou=personnes,ou=..." 2014-09-25T14:51:05.581530+02:00 ldap02 slapd[7362]: conn=642704 op=24 MOD dn="uid=3313791009,ou=personnes,ou=..." 2014-09-25T14:51:08.642118+02:00 ldap02 slapd[7362]: conn=642756 op=22 MOD dn="uid=3313791009,ou=personnes,ou=..."
--On Tuesday, September 30, 2014 8:49 AM +0000 "Meunier, Antonin" antonin.meunier@cgi.com wrote:
Hello,
I'm with openldap-2.4.39 on MMR mode with 2 master openldap server. After a crash of the ldap n°1 (segfault), i delete the data on the ldap N°1 (slapd and delta-sync), the ldap N°2 still running. I started the ldap n°1. It made a full sync to have the data of the ldap n°2. But during this full sync, if an entry is modified on the ldap n°2, this entry is not replicated on the server n°1 (error "greater than snapshot"). Even if i edit manually the entry on the ldap n°2, this entry is never created on the ldap n°2. How can i force these entrys to be replicated? How can i resync an ldap server (without interruption) (export ldif and import?, full sync)?
Are you able to reproduce this with 2.4.40? There have been some fixes to sync replication in it. None obviously jump out as a fix, but it is worth a check.
--Quanah
--
Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org
-
Meunier, Antonin -
Quanah Gibson-Mount