On Mon, Jan 29, 2024 at 10:23:10AM +0100, Marc Franquesa wrote: > Hi > > I have been using replication since long time without any issues (and still > without issues), but on recent versions I got this warning on the logs: > > syncprov_setup_accesslog: couldn't get definition for attribute reqType, is > accesslog configured?
Hi Marc, are you running with syncprov-reloadhint by any chance? It's just a warning that syncprov might consider using the attribute but it's not defined. I've just moved the check to syncprov-nopresent[0] which doesn't really have any uses without an accesslog DB being around. > The answer is no, I never configured accesslog (this why I'm a bit > confused, as I never used/needed on my replication setup). After reviewing > the documentation I understand that for syncrepl I should load and > configure accesslog overlay. > > Although I have some questions/concerns I haven't been able to > found/understand from the documentation and would like someone clarifies: > > * Is there any way to implement replication without accesslog? (currently I > have it but I would like to not get that warning) No need for accesslog if you're doing plain syncrepl. > * If I setup accesslog, do I need to setup a different accesslog DIT for > each target DIT I replicate? Or can a single accesslog be shared with 2 > different target DITs? Yes, for delta-MPR you need separate accesslog per DB. > I mean: I'm currently replicating both cn=config (dynamic configuration) > and the main DIT (so 2 different contexts/DITs/trees) Do I need to use a > different accesslog DIT for each one or can they share the same DIT as > accesslog ? deltasync is not all or nothing, each DB can be set up separately (and AFAIK people don't usually do deltasync for cn=config). > * Does this log DIT needs to be backup up or is simply a log which I could > get rid of in case of recovery? Unless you're using it for auditing purposes, you just have to make sure to either: - backup and restore both DBs from the same exact version - or not restore accesslog (and wipe it on main DB restore) [0]. https://git.openldap.org/openldap/openldap/-/merge_requests/677 Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
