ITS8100: What to do about a fresh accesslog DB when in delta-sync MMR node

Quanah Gibson-Mount

2015-05-11 20:26:18 UTC

Content preview: --On Wednesday, April 08, 2015 10:50 PM -0700 Quanah Gibson-Mount
<***@zimbra.com> wrote: > 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.
;) [...]

Content analysis details: (-4.3 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium
trust
[162.209.122.184 listed in list.dnswl.org]
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's
domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature

--On Wednesday, April 08, 2015 10:50 PM -0700 Quanah Gibson-Mount

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. ;)

One possibility that came to mind today was essentially treating this
scenario as similar to ldap down, and simply back off along the lines of
the retry etc configuration bits in syncrepl. This would keep the system
from going nuts if another pair doesn't have an accesslog DB mod op yet,
and let it pick up changes once they are available. Thoughts?

--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration