Mark,
Today at 10:01am, Mark Cairney wrote:
Hi Frank,
...
My present /etc/systemd/journald.conf contains the following- these are the defaults from our config management system and I haven't found a need to adjust them yet (although they do look a bit looser than the RH defaults):
...
For day-to-day operations I'm not noticing any limiting kicking in. During operations that generate a lot of logs e.g. re-syncing a replica, SLAMD benchmarking logs do indeed get lost but this is preferable to the alternative where the logger becomes the bottleneck and slapd is essentially sitting there waiting for logs to be written before continuing.
Thanks! That's similar to one of the configs I had tried (though I did not make the journald log persistent). I'll try again.
RE: bringing up a replica I'd avoid using syncrepl from scratch- I find building the slave from a dump of the master is far quicker and more reliable. I tend to do (as a brief/trivial example):
...
Importing this with slapadd takes me about 5 mins for a 1.5G ldif file using mdb- it took about 15-20 mins when I was using bdb. With any luck the replica will then pick up any changes that have been made to the master since the dump when you start slapd. The usual disclaimer that this is just what's working for me and not a definitive "this is how it should be done"
Yeah, I do the same in production. In my test environment, firing up an empty replica is a good way to generate a lot of traffic that needs to be logged.