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" <[email protected]
<mailto:[email protected]>> 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" <[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>> wrote:
On Feb 18, 2017 05:41, "Quanah Gibson-Mount"
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> wrote:
>
> --On Friday, February 17, 2017 5:46 PM +0800 Daniel Jung
<[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>> 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/
<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.
