2:59 a.m.
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
9:04 a.m.
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(a)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
12:49 a.m.
New subject: MMR - Full sync of an empty ldap with a full ldap - modified entry on the full ldap are not replicated on the empty (greater than snapshot)
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=..."
9:53 a.m.
New subject: MMR - Full sync of an empty ldap with a full ldap - modified entry on the full ldap are not replicated on the empty (greater than snapshot)
--On Tuesday, September 30, 2014 8:49 AM +0000 "Meunier, Antonin"
<antonin.meunier(a)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
3347
days inactive
3348
days old
openldap-technical@openldap.org
3 comments
2 participants
participants (2)
-
Meunier, Antonin -
Quanah Gibson-Mount