[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
ITS8100: What to do about a fresh accesslog DB when in delta-sync MMR node
- To: openldap-devel@openldap.org
- Subject: ITS8100: What to do about a fresh accesslog DB when in delta-sync MMR node
- From: Quanah Gibson-Mount <quanah@zimbra.com>
- Date: Wed, 08 Apr 2015 21:50:17 -0700
- Content-disposition: inline
- Dkim-filter: OpenDKIM Filter v2.9.2 edge01.zimbra.com 804984427E
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zimbra.com; s=C2AA288C-EE47-11E2-9BB0-E820BDD9BDBF; t=1428555023; bh=V/0sf8uWVjB0CLSDsZ1nGxaDV0WSfWcX5lCWK1cAoN8=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=IKoG6iTsCKC9/TYUh8Y03FlU66RvaoUUAeULFcUOuJroKYQnFQJGeHUx2jl+o8xPy sGoSUEu4WrhQw0leaWFEXlppb+82aqEbANIx90WLfxigKW6lASJbJvk6E2Dv9mlv17 elbmTByphu+r5mJSAAbkmQThViXrTa9Ob+O/Tm6Y=
There's a general issue with using delta-sync MMR that needs some
resolution (It's causing some considerable pain for customers): It is
possible to put the entire system into endless fallbacks until a new and/or
reloaded node gets a write operation. The general problem is that when an
existing master queries the new/reloaded master's accesslog DB, zero
entries are returned. This then triggers the fallback. This happens up
util such a time as the new/reloaded master gets a direct write op. I've
worked around it in general by immediately doing a no-op on the primary db
(ldapmodify/replace an attribute value with its own value), but it would be
nice to be able to bring new MMR nodes online or be able to reload MMR
nodes for if they get out of sync, etc, without causing this sync fallback
issue. There is no clear solution at the moment on what to do about zero
results from the accesslog in the delta-sync MMR scenario. Proposals
welcome. ;)
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration