Re: syncrepl skipped entryCSN on openldap-2.4.44 on centos 6

[Brendan Kearney <bpk678@gmail.com>]

On 02/18/2017 08:18 PM, Daniel Jung wrote:

Just an option for those that have unreliable (r)syslog upstream at times and ldap as a core infra, it would be nice to not getting blocked on logging io.

On Feb 19, 2017 08:58, "Howard Chu" <hyc@symas.com> wrote:

Daniel Jung wrote:

Hi Quanah,

Speaking of logging, is openldap-3 going to support udp based logging? I saw
while back that there is improved? syslog code that we can compile in the src.
I was thinking of just adding udp into that code and test it out.

I have no plans to add UDP support. Could be done, but what's the benefit?

If you want to add it, feel free to submit a patch.

On Feb 18, 2017 09:57, "Daniel Jung" <mimianddaniel@gmail.com
<mailto:mimianddaniel@gmail.com>> wrote:

    On Feb 18, 2017 05:41, "Quanah Gibson-Mount" <quanah@symas.com
    <mailto:quanah@symas.com>> wrote:
    >
    > --On Friday, February 17, 2017 5:46 PM +0800 Daniel Jung
    <mimianddaniel@gmail.com <mailto:mimianddaniel@gmail.com>> wrote:
    >
    >>
    >> Hi,
    >>
    >>
    >> I see that some entryCSN have not been synced properly with the
    >> provider.
    >> I run multimaster setup and with several slaves and sometimes i see that
    >> some slaves have old entryCSNs and I am syncing them manually with -c
    >> option.
    >
    >
    > Do you mean contextCSNs?
    No. ContextCSN is up to date. But some entries have old entryCSN compared
    to the master.
    >
    >
    >> I haven't been able to track the cause nor see anything in the log to
    >> indicate the problem. However, we have had slapd become non-responsive
    >> due to IO blocking on logging. Could this cause syncrepl to miss updating
    >> the entries?  Has anyone seen this behaviour?
    >
    >
    > If slapd gets locked up, hard to say what the side effects could be.  Do
    you have stats+sync logging enabled on all of the systems?
    I do have stats and sync enabled.
    >
    > --Quanah
    >
    >
    > --
    >
    > Quanah Gibson-Mount
    > Product Architect
    > Symas Corporation
    > Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
    > <http://www.symas.com>
    >

--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

call it convoluted, but i have quite the setup for syslogging reliably with low i/o.  i use fedora, so systemd-journald is the default logging mechanism.  i disable local journald logging and tell journald to forward logs to syslog.  then i use RELP (reliable event log processing), a "plug-in" for rsyslog, to forward syslog messages over TCP to a load balanced VIP of receivers.  RELP uses TCP, and local memory-to-disk buffers for spillover capacity when connectivity fails and messages queue up.  messages that are queued up, and dont FIFO out, are sent once connectivity is restored.

the receivers take in the messages, and then use ommysql to insert logs into a database.  memory tweaking on the database side keeps disk i/o low and out of the critical path, so that i/o does not bottleneck things.  with mariadb and galera, i have fully replicated multimaster databases accepting logs from my fully replicated multimaster ldap instances, among other services.