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
On 11/15/21 9:00 AM, 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?
Those searches are using "substring" filters. So you need to index those attributes for "sub"
Example:
ldapmodify -D "cn=directory manager" -W dn: cn=uniquemember,cn=index,cn=userroot,cn=ldbm database,cn=plugins,cn=config changetype: modify add: nsIndexType nsIndexType: sub
Then after doing this or all those attributes, then you need to reindex them:
./db2index.pl -D "cn=directory manager" -w - -n userroot -t member -t uniquemember -t owner -t seealso
HTH,
Mark
Thanks & Regards _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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.fedoraproject.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
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@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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.fedoraproject.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
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@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@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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.fedoraproject....
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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.fedoraproject.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 11/15/21 9:46 AM, Pierre Rogier wrote:
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 ?
It is used for MODRDN's like Thierry stated. The code states that we use the substring filter to find the children memberships of the old DN so they can be properly cleaned up. I'm not sure this can be optimized to /not/ use a substring filter....
Mark
On Mon, Nov 15, 2021 at 3:22 PM Thierry Bordaz tbordaz@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@lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave@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.fedoraproject.org > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
--
389 Directory Server Development Team
389-users mailing list --389-users@lists.fedoraproject.org To unsubscribe send an email to389-users-leave@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.fedoraproject.... Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure
On 11/15/21 3:55 PM, Mark Reynolds wrote:
On 11/15/21 9:46 AM, Pierre Rogier wrote:
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 ?
IIUC it is to handle this testcase
dn: ou=group, dc=example,dc=com member: uid=foo,ou=people,dc=example,dc=com
dn: ou=people,dc=example,dc=com ou: people
dn: uid=foo,ou=people,dc=example,dc=com uid: foo
MODRDN(ou=people,dc=example,dc=com -> ou=new_people,dc=com)
Then this code is to get
dn: ou=group,dc=example,dc=com member: uid=foo,ou=new_people,dc=com
It is used for MODRDN's like Thierry stated. The code states that we use the substring filter to find the children memberships of the old DN so they can be properly cleaned up. I'm not sure this can be optimized to /not/ use a substring filter....
Mark
On Mon, Nov 15, 2021 at 3:22 PM Thierry Bordaz tbordaz@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@lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave@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.fedoraproject.org > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
--
389 Directory Server Development Team
389-users mailing list --389-users@lists.fedoraproject.org To unsubscribe send an email to389-users-leave@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.fedoraproject.... Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure
-- Directory Server Development Team
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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.fedoraproject.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 15.11.21 15:55, Mark Reynolds wrote:
On 11/15/21 9:46 AM, Pierre Rogier wrote:
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 ?
It is used for MODRDN's like Thierry stated. The code states that we use the substring filter to find the children memberships of the old DN so they can be properly cleaned up. I'm not sure this can be optimized to /not/ use a substring filter....
yes, if the MODRDN is applied to an entry with children, like inThierry's example, I don't think the subtree search can be avoided. But when the referential integrity function is applied, it should be known if the renamed entry has children or is a leaf node - and could avoid the substring searches in most cases.
Regards,
Ludwig
Mark
On Mon, Nov 15, 2021 at 3:22 PM Thierry Bordaz tbordaz@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@lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave@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.fedoraproject.org > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
--
389 Directory Server Development Team
389-users mailing list --389-users@lists.fedoraproject.org To unsubscribe send an email to389-users-leave@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.fedoraproject.... Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure
-- Directory Server Development Team
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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.fedoraproject.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 11/15/21 7:39 PM, Ludwig Krispenz wrote:
On 15.11.21 15:55, Mark Reynolds wrote:
On 11/15/21 9:46 AM, Pierre Rogier wrote:
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 ?
It is used for MODRDN's like Thierry stated. The code states that we use the substring filter to find the children memberships of the old DN so they can be properly cleaned up. I'm not sure this can be optimized to /not/ use a substring filter....
yes, if the MODRDN is applied to an entry with children, like inThierry's example, I don't think the subtree search can be avoided. But when the referential integrity function is applied, it should be known if the renamed entry has children or is a leaf node - and could avoid the substring searches in most cases.
Hellooo Ludwig,
Thanks for this nice and simple idea. I opened https://github.com/389ds/389-ds-base/issues/5004.
best regards thierry
Regards,
Ludwig
Mark
On Mon, Nov 15, 2021 at 3:22 PM Thierry Bordaz tbordaz@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@lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave@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.fedoraproject.org > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
--
389 Directory Server Development Team
389-users mailing list --389-users@lists.fedoraproject.org To unsubscribe send an email to389-users-leave@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.fedoraproject.... Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure
-- Directory Server Development Team
389-users mailing list --389-users@lists.fedoraproject.org To unsubscribe send an email to389-users-leave@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.fedoraproject.... Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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.fedoraproject.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
389-users@lists.fedoraproject.org