[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: mmr pair stops replicating: "consumer state is newer than provider"
- To: openldap-technical@openldap.org
- Subject: Re: mmr pair stops replicating: "consumer state is newer than provider"
- From: btb <btb@bitrate.net>
- Date: Thu, 29 Jun 2017 12:41:17 -0400
- Content-language: en-US
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bitrate.net; s=default; t=1498754478; bh=Mf9zBVeHtDYvXorZnBXJ52vMKwP7mNWm8UDMCaERwE0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=cWrtnDxoI8sLf+LUUOiqF+Vpg4gGYeFRmlcV+yNfbBIMe7m+pnoBCXhdA2FMtQPSe 2k7J+gsxjNi5qmAWGlEcTCa1dqZXedFRAFx6BrdkZK9iUfuzGDjx1EqZj0ZbtProrI sxuv3M+4b8U6uDH+zCvog1CrupPUTROxYKTLl+wM=
- In-reply-to: <73EF314E2CECAE34C9C098F4@[192.168.1.30]>
- References: <460a87bc-ccb6-9553-bb6a-b57de306058e@bitrate.net> <WM!721ba9b642972ca17483c621787c32b1e0b1f650e884b9d0653d75b7c6a4b403485f248df406b00e352a97047c1e5e1c!@mailstronghold-1.zmailcloud.com> <B3D6DB90F83F55DBF692C0B8@[192.168.1.30]> <ffa99d26-b81a-6409-6e8c-12ee91d5487e@bitrate.net> <WM!250a43491a3881f6c8d454396d5edcdbdff347676182c3cd95de6b3570ee09feafbcccefba03f9d48b03b9bb3f10deb0!@mailstronghold-1.zmailcloud.com> <4DA177A2CB98B18529699F27@[192.168.1.30]> <a59a985e-8c4c-9f58-131a-c51b78b8874f@bitrate.net> <WM!001a7eaf2d319db0d65d5f48486c7e4d9457a2a4db8dbd04f89cdd1d17dc8fdb2a0d9b3ca6d0898ed0828dd9956d7bf6!@mailstronghold-1.zmailcloud.com> <73EF314E2CECAE34C9C098F4@[192.168.1.30]>
- User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:54.0) Gecko/20100101 Thunderbird/54.0
On 6/29/17 11:15 AM, Quanah Gibson-Mount wrote:
--On Thursday, June 29, 2017 2:12 AM -0400 btb <btb@bitrate.net> wrote:
i see, thanks. i tested this, and did a modify on each, but didn't see
replication resume. emulating the syncrepl connection with a manual
search against each master, there do seem to be accesslog entries now, on
both masters:
You may have to restart the consumers (I did when I ran into this).
i did try a restart on both, but they returned to the same state
Also, there are 2 sets of CSNs per master that you need to examine --
The CSNs in your database root (i.e., dc=example,dc=org) and your
accesslog root.
that would be these, right?
dsa1 cn=accesslog:
20161019002438.652359Z#000000#000#000000
20170521175113.974560Z#000000#002#000000
20170530214415.204052Z#000000#001#000000
dsa1 dc=example,dc=org:
20170520031415.276678Z#000000#000#000000
20170530214231.171959Z#000000#002#000000
20170530214415.204052Z#000000#001#000000
dsa2 cn=accesslog:
20170520031415.276678Z#000000#000#000000
20170521175113.974560Z#000000#002#000000
20170628034119.327974Z#000000#001#000000
dsa2 dc=example,dc=org:
20170520031415.276678Z#000000#000#000000
20170619014933.531051Z#000000#002#000000
20170628034119.327974Z#000000#001#000000
why are there three per db, and which is suppose to match which?