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,