Re: [Q] can I replicate several branches to the same slave from one master?

[Andrew Findlay <andrew.findlay@skills-1st.co.uk>]

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


-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------