Re: syncRepl master loses syncrepl entry (ITS#2928)

[jongchoi@OpenLDAP.org]

> I found that after repeated use and lockups of the slaves (which required them

Is this the same one as reported in ITS#2910 ?
Is the refreshAndPersist mode used ?
and the size of the replication content ?

> to be killed, and db_recover run on their systems), that the master eventually
> lost its syncrepl entry (????), making it so that it was impossible for them to

>From the above context, isn't it the slave (consumer) who is supposed to lose its syncrepl
entry ?

> query the master for further updates, and resulting in the following errors in
> the ldap log on the replica:
>
> Jan 21 21:36:19 ldap-dev1.Stanford.EDU slapd[13222]: [ID 100111 local4.debug]
> slapd starting
> Jan 21 21:36:20 ldap-dev1.Stanford.EDU slapd[13222]: [ID 166296 local4.debug]
> null_callback : error code 0x42
> Jan 21 21:36:20 ldap-dev1.Stanford.EDU slapd[13222]: [ID 749340 local4.debug]
> syncrepl_entry : be_search failed (66)
> Jan 21 21:36:23 ldap-dev1.Stanford.EDU slapd[13222]: [ID 166296 local4.debug]
> null_callback : error code 0x42
> Jan 21 21:36:23 ldap-dev1.Stanford.EDU slapd[13222]: [ID 749340 local4.debug]
> syncrepl_entry : be_search failed (66)
> Jan 21 21:36:23 ldap-dev1.Stanford.EDU slapd[13222]: [ID 166296 local4.debug]
> null_callback : error code 0x42
> Jan 21 21:36:23 ldap-dev1.Stanford.EDU slapd[13222]: [ID 749340 local4.debug]
> syncrepl_entry : be_search failed (66)
> Jan 21 21:36:23 ldap-dev1.Stanford.EDU slapd[13222]: [ID 166296 local4.debug]
> null_callback : error code 0x42
> Jan 21 21:36:23 ldap-dev1.Stanford.EDU slapd[13222]: [ID 749340 local4.debug]
> syncrepl_entry : be_search failed (66)

This sequence of error revealed a need to update the present mode processing
routine to make it delete the non-present entries from the leaf entries first.
A direct approach would be to remove the leaf entries first by examining
the hasSubordinates operational attributes. The disadvantage of this approach
is that it is required to repeat the non-present entry deletion process when
all to-be-deleted entries become leaf entries.
Another approach would be to sort the entries in the createTimestamp order.
Because server side sorting is not supported, the syncrepl engine needs to
make si_nonpresentlist be sorted in the createTimestamp order.
I'm more inclined to the latter. Any comments or other possibilities ?

>
> --Quanah