By the way despite the recomendation against reducing the timer on cleaning out the tombstones I would do it any way.
My experience with many other database platforms is that if the cleanups of stale entries is taking too long it means you aren't doing them often enough for your environment.
If you do a lot of deletes more often than most other people you need to do cleanups more often than other people no matter what the experts say.
Bulk cleanups are ment to make the process more optimal and allow for role back of changes but they aren't always practical for every implementation.
On 05/16/2012 07:48 PM, Brad Schuetz wrote:
On 05/16/2012 06:24 PM, Rich Megginson wrote:Looks like 617862 is back . . .
On 05/16/2012 06:48 PM, Brad Schuetz wrote:Here's the command with only the username part of the DN redacted and
Is there any way that I can remove the nsTombstone entries from theCan you provide
master server so I can get this under control? I think I found out why
I have so many nsTombstone entries in the first place so I'd like to get
the current ones deleted and see how much delete activity I'll have
moving forward.
I saw this bug report,
<https://bugzilla.redhat.com/show_bug.cgi?id=617862>, that seems to
indicate that I should be able to ldapdelete the nsTombstone entries
using their full dn, however it always says object not found.
1) the exact ldapdelete command line
2) the excerpts from the access and errors log from around the time of
the deletion
the access log for the command, I confirmed that after the delete failed
that the entry was in fact still there by running the ldap search again
for nstombstone entries to be sure that it wasn't just a timing issue.
Also attempted the same command with quotes around the DN to delete.
The error log produced no entries around the time of the command being run.
ldapdelete -x -D 'cn=Directory Manager' -W
nsuniqueid=14403301-1dd211b2-9635fc8a-5f520000,uid=aeria005,ou=Users,ou=System,dc=cust,dc=omnis,dc=com
This was the output from the above command:
ldap_delete: No such object (32)
matched DN:
uid=[redacted],ou=Users,ou=System,dc=cust,dc=omnis,dc=com
access log:
17/May/2012:01:41:35 +0000] conn=947 fd=80 slot=80 SSL connection from
::1 to ::1
[17/May/2012:01:41:35 +0000] conn=947 SSL 256-bit AES
[17/May/2012:01:41:35 +0000] conn=947 op=0 BIND dn="cn=Directory
Manager" method=128 version=3
[17/May/2012:01:41:35 +0000] conn=947 op=0 RESULT err=0 tag=97
nentries=0 etime=0 dn="cn=directory manager"
[17/May/2012:01:41:35 +0000] conn=947 op=1 DEL
dn="nsuniqueid=14403301-1dd211b2-9635fc8a-5f520000,uid=[redacted],ou=Users,ou=System,dc=cust,dc=omnis,dc=com"
[17/May/2012:01:41:35 +0000] conn=947 op=1 RESULT err=32 tag=107
nentries=0 etime=0
[17/May/2012:01:41:35 +0000] conn=947 op=1 RESULT err=32 tag=107
nentries=0 etime=0
[17/May/2012:01:41:35 +0000] conn=947 op=2 UNBIND
[17/May/2012:01:41:35 +0000] conn=947 op=2 fd=80 closed - U1
However I can report that the internal process seems to have finally
cleaned up the bulk of the entries, I had over 20k entries on the master
and it's finally down to less than 100. I temporarily changed the
values for when it should reap the entries to try and get it to clear
them out internally after I fixed the issue that I believe was
responsible for the extraneous deletes.
--
Brad
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users