Hello,
I would like to ask you for your guidance regarding the following.
We have an openldap (v2.4.56) master server syncing with three other openldap slaves.
The master seems being unable to complete successfully syncing a particular entry and it keeps trying for ever. Logs follow.
I have realized this only now, but it seems that this is happening for long. (It is recorded in all the logs I have available.)
What is the suggested way to resolve this situation?
=======================================================================================================
... Jan 16 14:48:09 ldap.noa.gr slapd[1655]: conn=1048 op=1 syncprov_search_response: Entry cn=thermo,ou=Aliases,dc=noa,dc=gr CSN 20200910151806.461875Z#000000#000#000000 older or equal to ctx 20200910151806.461875Z#000000#000#000000 Jan 16 14:48:09 ldap.noa.gr slapd[1655]: conn=1048 op=1 syncprov_search_response: cookie=rid=601,csn=20210116055411.875566Z#000000#000#000000 Jan 16 14:48:09 ldap.noa.gr slapd[1655]: conn=1048 op=1 syncprov_sendinfo: refreshPresent cookie=rid=601,csn=20210116055411.875566Z#000000#000#000000 Jan 16 14:48:09 ldap.noa.gr slapd[1655]: conn=1048 op=1 syncprov_search_response: detaching op Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1 syncprov_op_search: got a persistent search with a cookie=rid=601,csn=20200910151806.461875Z#000000#000#000000 Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1 syncprov_findbase: searching Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1 syncprov_op_search: registered persistent search Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1 syncprov_findcsn: mode=FIND_CSN csn=20200910151806.461875Z#000000#000#000000 Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1 syncprov_findcsn: csn==20200910151806.461875Z#000000#000#000000 found Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1 syncprov_findcsn: mode=FIND_PRESENT csn= Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1 syncprov_sendinfo: present syncIdSet cookie= Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1 syncprov_sendinfo: present syncIdSet cookie= Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1 syncprov_sendinfo: present syncIdSet cookie= Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1 syncprov_sendinfo: present syncIdSet cookie= Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1 syncprov_sendinfo: present syncIdSet cookie= Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1 syncprov_sendinfo: present syncIdSet cookie= Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1 syncprov_sendinfo: present syncIdSet cookie= Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1 syncprov_sendinfo: present syncIdSet cookie= Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1 syncprov_sendinfo: present syncIdSet cookie= Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1 syncprov_sendinfo: present syncIdSet cookie= Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1 syncprov_sendinfo: present syncIdSet cookie= Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1 syncprov_sendinfo: present syncIdSet cookie= Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1 syncprov_search_response: Entry cn=thermo,ou=Aliases,dc=noa,dc=gr CSN 20200910151806.461875Z#000000#000#000000 older or equal to ctx 20200910151806.461875Z#000000#000#000000 Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1 syncprov_search_response: cookie=rid=601,csn=20210116055411.875566Z#000000#000#000000 Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1 syncprov_sendinfo: refreshPresent cookie=rid=601,csn=20210116055411.875566Z#000000#000#000000 Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1 syncprov_search_response: detaching op =========================================================================================================
Thank you in advance for your advice!
Cheers, Nick
--On Saturday, January 16, 2021 3:17 PM +0200 Nick Milas nick@eurobjects.com wrote:
Hello,
I would like to ask you for your guidance regarding the following.
Hi Nick,
Nothing in the log snippet provided shows an issue. What leads you to believe an issue has been encountered?
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On 18/1/2021 6:27 μ.μ., Quanah Gibson-Mount wrote:
Nothing in the log snippet provided shows an issue. What leads you to believe an issue has been encountered?
Hi Quanah,
Thanks for the reply,
I can't tell whether it was an issue or not (for example, I could call it a phenomenon), but I found it strange to have this repeating for weeks every three minutes and always on that single entry (among thousands).
I am trying to figure out what does the log snippet mean. I would guess it means that the particular entry at the master DIT is found to be older than the one at the slave?
If so, I wonder how this may have happened! Maybe due to a DIT change that took place at some point in time when the master clock was a bit slower than the slave? (Although both are running ntp service.)
And - in any case - what would be the recommended way to stop this from occurring constantly?
My poor man's action would be to do some modification on the entry (at the master). It might not be an elegant, or even suggested solution, but it would force a resync of the entry at the slave, updating times. In the end I tried this and and I have since stopped seeing this message showing in the log.
Thanks! Nick
On Sat, Jan 23, 2021 at 12:57:37AM +0200, Nick Milas wrote:
On 18/1/2021 6:27 μ.μ., Quanah Gibson-Mount wrote:
Nothing in the log snippet provided shows an issue. What leads you to believe an issue has been encountered?
Hi Quanah,
Thanks for the reply,
I can't tell whether it was an issue or not (for example, I could call it a phenomenon), but I found it strange to have this repeating for weeks every three minutes and always on that single entry (among thousands).
I am trying to figure out what does the log snippet mean. I would guess it means that the particular entry at the master DIT is found to be older than the one at the slave?
Something writes to your consumer, if you have a MMR environment, you want to assign different serverids. Otherwise you want to figure out how the change happened and either fix the offending service or set up chaining on consumers.
If so, I wonder how this may have happened! Maybe due to a DIT change that took place at some point in time when the master clock was a bit slower than the slave? (Although both are running ntp service.)
And - in any case - what would be the recommended way to stop this from occurring constantly?
Regards,
--On Monday, January 25, 2021 11:46 AM +0100 Ondřej Kuzník ondra@mistotebe.net wrote:
Something writes to your consumer, if you have a MMR environment, you want to assign different serverids. Otherwise you want to figure out how the change happened and either fix the offending service or set up chaining on consumers.
Also note that if this is an MMR environment, serverID values must be > 0 and unique across the MMR environment (The log shows a "0" serverID in use).
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
openldap-technical@openldap.org
-
Nick Milas -
Ondřej Kuzník -
Quanah Gibson-Mount