On Thu, Jun 29, 2017 at 03:47:07PM +0100, Andrew Findlay wrote:
I suspect part of the trouble is that you have two syncrepl clauses using the same search base on the same master. The timestamps are likely to be stored in the same place, causing a clash.
One definite error is that all three clauses are labelled 'rid=123'. They should all have different numbers.
As it happens, Quanah has just replied to a question with a very similar issue. See message below, and also the ITS: http://www.openldap.org/its/index.cgi/Software%20Bugs?id=8100;selectid=8100
... so you should also make at least one change to data on the master node so that the syncrepl process has something to do.
Andrew
On Tue, Jun 27, 2017 at 01:55:34PM -0700, Quanah Gibson-Mount wrote:
Date: Tue, 27 Jun 2017 13:55:34 -0700 From: Quanah Gibson-Mount quanah@symas.com To: btb btb@bitrate.net, openldap-technical@openldap.org Subject: Re: mmr pair stops replicating: "consumer state is newer than provider" Sender: openldap-technical openldap-technical-bounces@openldap.org
--On Tuesday, June 27, 2017 5:35 PM -0400 btb btb@bitrate.net wrote:
On 6/27/17 10:27 AM, Quanah Gibson-Mount wrote:
--On Tuesday, June 27, 2017 10:37 AM -0400 btb btb@bitrate.net wrote:
i'm using 2.4.44 on freebsd, built from ports. i can provide any config details etc - i just didn't want to inundate the post with guesses on detail that might not be relevant.
What is your accesslog purge setting? Do you have long periods of time with no write activity?
there are some extended periods of time with no write activity, yes.
That's one form of a known issue then with using accesslog (ITS#8100). I've made a suggestion on how it could be fixed, and Howard agreed that would be the correct solution. Just need the fix. :)
In the meantime, you can set up a cronjob that does a modify once a day on some object that doesn't really do anything, like if you had:
dn: cn=someobject,dc... objectClass: ... cn: someobject description: blah
you could have a job that does: dn: cn=someobject,dc... changetype: modify replace: description description: blah
So it in effect does nothing, but it keeps an active change in the accesslog alive.
Basically what happens with the accesslog empty is that it'll end up generating its own new contextCSN that differs for that server than the one stored in the rootDB, and will be /newer/ than it as well, which is why you get that message. You can also fix the problem simply by doing a modify on each master, and it'll reset the contextCSNs and things will flow (i.e., no need to do a dump/reload, etc).
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com