I feel a bit weird that we try to perform substring searches in the
referential integrity plugin.
I would rather expect equality searches.
Does anyone know why the * are needed ?
On Mon, Nov 15, 2021 at 3:22 PM Thierry Bordaz <tbordaz(a)redhat.com> wrote:
Hi,
The referential integrity plugins uses internal searches to retrieve
which entries referred to the target entry. The plugin uses equality
searches, that are indexed, but for MODRDN it uses substring filter. As
membership attributes (member, uniquemember,...) are not indexed in
substring, each MODRDN triggers 4 (4 membership attributes) unindexed
searches. referint being a betxn plugin, unindexed search are prone to
create db retries and could be related to replication failure.
I would recommand that you try adding substring index to the member,
uniquemember, owner and seealso.
regards
thierry
On 11/15/21 3:00 PM, Ciber dgtnt wrote:
> Hi, I have a problem in 389-ds version 1.3.10.2-10 intalled on Centos7 ,
we have a multimaster enviroment with consumers and suppliers, we have
referential integrity plugin to control the group members. In the master
node where we have the referential integrity pluggin enabled, ocasionally
we get this message in the error log :
>
> NOTICE - ldbm_back_search - Internal unindexed search: source
(cn=referential integrity postoperation,cn=plugins,cn=config) search
base="c=es" scope=2 filter="(member=*uid=dmarmedr,ou=Baja de
cuentas,c=es)"
conn=0 op=0
> NOTICE - ldbm_back_search - Internal unindexed search: source
(cn=referential integrity postoperation,cn=plugins,cn=config) search
base="c=es" scope=2 filter="(uniquemember=*uid=dmarmedr,ou=Baja de
cuentas,c=es)" conn=0 op=0
> NOTICE - ldbm_back_search - Internal unindexed search: source
(cn=referential integrity postoperation,cn=plugins,cn=config) search
base="c=es" scope=2 filter="(owner=*uid=dmarmedr,ou=Baja de
cuentas,c=es)"
conn=0 op=0
> NOTICE - ldbm_back_search - Internal unindexed search: source
(cn=referential integrity postoperation,cn=plugins,cn=config) search
base="c=es" scope=2 filter="(seeAlso=*uid=dmarmedr,ou=Baja de
cuentas,c=es)" conn=0 op=0
>
> And when it happends the slapd proccess takes up to 100% CPU usage and
we see the message you can see bellow, because this master node begins to
avoid replication sessions from other master nodes:
>
> ERR - NSMMReplicationPlugin - process_postop - Failed to apply update
(615f51ea000000230000) error (51). Aborting replication session(conn=1145
op=4)
>
> All those internal unindexed searchs have filters with the attributes
configured in the referential integrity plugin, member=*, uniquemember=*,
owner=* and seealso=*. Those attributes has equality and presence indexes,
we don't understand why the log says "internal unindexed search".
>
> Can anyone help me with this problem?, maby is it necessary other type
of index?
>
> Thanks & Regards
> _______________________________________________
> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
> Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure