On Thu, 2017-07-13 at 22:09 +0000, tdarby@xxxxxxxxxxxxxxxxx wrote:
> I have two 389 servers configured for multimaster replication. I noticed these possibly related messages in the errors logs:
Which version of 389-ds-base do you have configured?
>
> server1:
> [12/Jul/2017:07:50:44 -0700] - database index is corrupt; key *zon has a data item with the wrong size (5)
>
> server2:
> [12/Jul/2017:07:55:48 -0700] - idl_new.c BAD 59, err=-30999 DB_BUFFER_SMALL: User memory too small for return value
> [12/Jul/2017:07:55:48 -0700] - database index operation failed BAD 1050, err=-30999 DB_BUFFER_SMALL: User memory too small for
>
> How can I determine what index this is referring to and how do I repair it?
>
Sorry, there is no way to see which index it is easily. It looks like a
substring index, but you likely need to correlate this to an access log
that made a query of "*zon".
Saying thi,s the problem may not be the corruption, the problem may
exist in our internal code. We allocate a buffer of of 8192 bytes to
read the data into:
#define BULK_FETCH_BUFFER_SIZE (8*1024)
...
idl_new_fetch() {
...
char buffer[BULK_FETCH_BUFFER_SIZE];
...
memset(&data, 0, sizeof(data));
data.ulen = sizeof(buffer);
data.size = sizeof(buffer);
data.data = buffer;
data.flags = DB_DBT_USERMEM;
We then pass this buffer to bdb to retrieve the data at key.
...
ret = cursor->c_get(cursor,&key,&data,DB_SET|DB_MULTIPLE);
if (0 != ret) {
if (DB_NOTFOUND != ret) {
if (ret == DB_BUFFER_SMALL) {
slapi_log_err(SLAPI_LOG_ERR, "idl_new_fetch", "Database
index is corrupt; "
"data item for key %s is too large for our
buffer "
"(need=%d actual=%d)\n",
(char *)key.data, data.size, data.ulen);
...
This indicates that you have a very large substr index somewhere in your
db, especially if we have exceeded this size.
I think that it's certainly a bug we can't access an index of this size,
but I would want to do some work to reproduce the problem to be sure of
what was occurring.
If you are able to determine which value is the issue would you be able
to provide the output of
dbscan -n -f /var/lib/dirsrv/slapd-<instance>/db/<backend>/<index>.db
This will show you the "count" of idl's in the db:
/bin/dbscan -n -f objectclass.db
=domain 1
=groupofuniquenames 5
=organizationalunit 3
=top 9
Thanks,
--
Sincerely,
William Brown
Software Engineer
Red Hat, Australia/Brisbane
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
