[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: mmr pair stops replicating: "consumer state is newer than provider"

--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>