Hi,
I still can't figure out what to think of this:
I have a mirrormode setup. One server has the database, the other starts empty. The data is slowly propagating from server-1 to server-2, but when I monitor the process by counting how many objects are created on server-2 below the root object, it is not strictly increasing. All object below the root has DN: o=...
Is see output like this: # slapcat | grep 'dn: o=' | wc -l 601 # slapcat | grep 'dn: o=' | wc -l 622 # slapcat | grep 'dn: o=' | wc -l 620 # slapcat | grep 'dn: o=' | wc -l 628
Why does server-2 "regret" already replicated objects?
Is this expected behaviour?
/Peter
--On Tuesday, November 03, 2009 8:02 AM +0100 Peter Mogensen apm@mutex.dk wrote:
Hi,
I still can't figure out what to think of this:
I have a mirrormode setup. One server has the database, the other starts empty. The data is slowly propagating from server-1 to server-2, but when I monitor the process by counting how many objects are created on server-2 below the root object, it is not strictly increasing. All object below the root has DN: o=...
Is see output like this: # slapcat | grep 'dn: o=' | wc -l 601 # slapcat | grep 'dn: o=' | wc -l 622 # slapcat | grep 'dn: o=' | wc -l 620 # slapcat | grep 'dn: o=' | wc -l 628
Why does server-2 "regret" already replicated objects?
Is this expected behaviour?
I would suggest doing diffs against what you slapcat so we can have a better idea of what's happening. It's certainly not what I would expect if this is a full refresh on a server that has no entries to start with.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On Tuesday, November 03, 2009 8:02 AM +0100 Peter Mogensen
Is see output like this: # slapcat | grep 'dn: o=' | wc -l 601 # slapcat | grep 'dn: o=' | wc -l 622 # slapcat | grep 'dn: o=' | wc -l 620 # slapcat | grep 'dn: o=' | wc -l 628
Why does server-2 "regret" already replicated objects?
Is this expected behaviour?
btw... I'm running 2.4.17
It seems to be a slapcat problem. I purged the database on both servers and loaded it from new on server-1. Then I started slapd on both servers and ran:
for ((I=1;I<=20;I++)); do slapcat > out-$I; done Then: for ((I=1;I<=20;I++)); do wc -l out-$I; done
Giving: 4755 out-1 4755 out-2 4755 out-3 4755 out-4 4491 out-5 4536 out-6 4847 out-7 4831 out-8 4885 out-9 4885 out-10 0 out-11 5252 out-12 5252 out-13 5252 out-14 5252 out-15 5601 out-16 5628 out-17 5601 out-18 5626 out-19 5920 out-20
run 11 seemed to fail silently. Notice that run 5 is smaller than run 4.
The problem seem to be entries in the LDIF like this:
dn: objectClass: top objectClass: NamedObject objectClass: simpleSecurityObject uid: rieke userPassword:: e1NBU0x..... structuralObjectClass: NamedObject entryUUID: e46b680e-e5f5-102b-93c9-79162adc1d46 creatorsName: dc=admin,dc=example,dc=com createTimestamp: 20070823185333Z entryCSN: 20070823185333.000000Z#000002#000#000000 modifiersName: dc=admin,dc=example,dc=com modifyTimestamp: 20070823185333Z
With an empty "dn:". There's lots of them in the output.
Running a batch of 20 slapcats without slapd running gives no errors.
/Peter
--On Wednesday, November 04, 2009 2:51 PM +0100 Peter Mogensen apm@mutex.dk wrote:
Peter Mogensen wrote:
btw... I'm running 2.4.17
Just tried 2.4.19 Same result.
Ok. Can you please file an ITS with the full details at http://www.openldap.org/its/?
Thanks!
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On Wednesday, November 04, 2009 2:51 PM +0100 Peter Mogensen apm@mutex.dk wrote:
Peter Mogensen wrote:
btw... I'm running 2.4.17
Just tried 2.4.19 Same result.
I've tried with libdb4.8 instead of libdb4.6 I see the same kind of entries with no DN in the slapcat output.
Ok. Can you please file an ITS with the full details at http://www.openldap.org/its/?
Will try.
/Peter
Quanah Gibson-Mount wrote:
--On Wednesday, November 04, 2009 2:51 PM +0100 Peter Mogensen apm@mutex.dk wrote:
Peter Mogensen wrote:
btw... I'm running 2.4.17
Just tried 2.4.19 Same result.
Ok. Can you please file an ITS with the full details at http://www.openldap.org/its/?
I've filed ITS #6365 with details about the config.
/Peter
--On Wednesday, November 04, 2009 9:49 AM +0100 Peter Mogensen apm@mutex.dk wrote:
btw... I'm running 2.4.17
It seems to be a slapcat problem. I purged the database on both servers and loaded it from new on server-1. Then I started slapd on both servers and ran:
Running a batch of 20 slapcats without slapd running gives no errors.
Interesting... I'd be curious to know if you can repeat this with current RE24 CVS head. Make sure you get the RE24 branch. :)
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
On 03/11/2009 08:02, Peter Mogensen wrote:
Hi,
I still can't figure out what to think of this:
I have a mirrormode setup. One server has the database, the other starts empty. The data is slowly propagating from server-1 to server-2, but when I monitor the process by counting how many objects are created on server-2 below the root object, it is not strictly increasing. All object below the root has DN: o=...
Is see output like this: # slapcat | grep 'dn: o=' | wc -l 601 # slapcat | grep 'dn: o=' | wc -l 622 # slapcat | grep 'dn: o=' | wc -l 620 # slapcat | grep 'dn: o=' | wc -l 628
Why does server-2 "regret" already replicated objects?
Is this expected behaviour?
Most probably not, but it really depends on your setup, the version you're using, etc.
Some things to look into:
- Make sure you're using the latest version. You mentioned mirrormode, so I'm assuming you're on the 2.4 branch. Many syncrepl related bugs have been fixed in the latest versions - 2.4.19 is considered stable, so if you're not using, I recommend you upgrade.
- Set your loglevel to include "sync" and study the logs on both servers. The output may be enlightening as to the origin of the problem.
If this doesn't solve it, please post back here with the version number you're using, your configuration (from both servers) and some logs.
Hope this helps, Jonathan
openldap-software@openldap.org
-
Jonathan Clarke -
Peter Mogensen -
Quanah Gibson-Mount