[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Replication issues with delta-syncrepl, MMR and memberOf overlay on 2.4.47
--On Wednesday, June 05, 2019 11:38 AM +0100 Mark Cairney
<Mark.Cairney@ed.ac.uk> wrote:
Hi,
We currently run a multi-master setup where all 4 of our servers
replicate from each other via delta-syncrepl but all our writes are
directed at a selected "master" server.
I've noticed recently that we are suffering sync issues and this
coincides with us upgrading from 2.4.46 with a patch for ITS8843 to
2.4.47.
Hi Mark,
Error 0x14 would be attribute type or value already exists. This would
indicate a fundamental problem of there being discrepencies between your
servers. I.e., your databases are out of sync.
There is a (possibly self-inflicted) point of pain where we have an
exattrs=memberOf in our syncrepl config to work around another
replication issue so this means that any user objects which are
REFRESH'ed end up losing all their group memberships.
You are aware the slapo-memberof(5) man page specifically states it is not
compatible with syncrepl based replication, in particular because of the
way in which the REFRESH phase functions combined with user/group entry
location (creation time) in the database?
I would add that the exattrs line shouldn't be necessary with a proper
configuration. I'm not sure what issue you were trying to avoid with this
setting. The ITS#8444 regression test in the testsuite specifically has a
4-way MMR setup with memberof, and requires no such setting nor does it
exhibit the issues you mention.
I.e., the only way you can ensure slapo-memberof will be "ok" in an
replicated environment (syncrepl or delta-syncrepl) is if you can guarantee
a REFRESH will never occur.
As for the configuration of the server, see below.
Are there any known bugs/ regressions with delta-syncrepl in 2.4.47?
One idea I've had is to go to a true single-master config by setting the
current consumers to be read-only and having a single olcSyncrepl clause
for the master on these 3 servers.
dn: olcOverlay={0}dynlist,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcDynamicList
olcOverlay: {0}dynlist
olcDlAttrSet: {0}groupOfURLs memberURL
dn: olcOverlay={1}memberof,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcMemberOf
olcOverlay: {1}memberof
olcMemberOfDangling: ignore
olcMemberOfRefInt: TRUE
olcMemberOfGroupOC: groupOfNames
olcMemberOfMemberAD: member
olcMemberOfMemberOfAD: memberOf
dn: olcOverlay={2}syncprov,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
objectClass: olcSyncProvConfig
olcOverlay: {2}syncprov
dn: olcOverlay={3}accesslog,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcAccessLogConfig
olcOverlay: {3}accesslog
olcAccessLogDB: cn=accesslog
olcAccessLogOps: writes
olcAccessLogPurge: 02+00:00 00+04:00
olcAccessLogSuccess: TRUE
As I've noted a number of times on the list, overlay instantiation order is
important for operation interception/processing. The syncprov overlay
should be the first instantiated overlay, followed by accesslog, in a
delta-syncrepl setup. In the above, this is clearly not the case.
I would additionally note that the syncprov overlay is missing a sessionlog
setting, where the default is likely much smaller than required for
mitigating ITS#8125.
Hope that helps!
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>